From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A534AC83F11 for ; Mon, 28 Aug 2023 18:36:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D292428001D; Mon, 28 Aug 2023 14:36:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD9D78E0029; Mon, 28 Aug 2023 14:36:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA10928001D; Mon, 28 Aug 2023 14:36:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id AB9A28E0029 for ; Mon, 28 Aug 2023 14:36:21 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 87A6512034E for ; Mon, 28 Aug 2023 18:36:21 +0000 (UTC) X-FDA: 81174368562.05.EB006AF Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf09.hostedemail.com (Postfix) with ESMTP id BAD0014002B for ; Mon, 28 Aug 2023 18:36:19 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=EcIUqfkg; spf=pass (imf09.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693247779; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ky9ruWT4vMi1n23k32PoOKd6l441oU0lu6dvfmODcBE=; b=4iRLHsI0kk88GksVWjWTarjN9fJuAPvbEiiJGqX3k+JXFwcqkltiAgtsNEcxa1xuVF3Ho2 kIIS6a7YWTVCY246zFeWVTL2l4/GrDTWqB8whQ8si7Y8H/vBY2BtU1FX6bzwcLBMzwSu0m CvWlI+sZQwrfT/5XOw3rtlNM7ZbmmqA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693247779; a=rsa-sha256; cv=none; b=rY7z0a1lvDSI+G8HfzkaazmBK1lrfY2Yevl/IlIAfOlaCpCaAF77bsywOSnyiwCC+emCiT ruoE2BS0WeNuDPMozgkx0/xHgGayBqpgYEX0KehUFkeozxjWkutB2vy4B8cR99/I87v9Fb jsfKtLhIN+Nw1Q0xyGUaAOXMp6Z3ltg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=EcIUqfkg; spf=pass (imf09.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-99bf1f632b8so475762766b.1 for ; Mon, 28 Aug 2023 11:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693247778; x=1693852578; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ky9ruWT4vMi1n23k32PoOKd6l441oU0lu6dvfmODcBE=; b=EcIUqfkgmCxoArH+hvfanA9vD9wZJyYnIYgZ6iL2g3vZPGwgFPCQCOAgIcl8o9FleE Oz4x81gdB9NDZBw7x9QXZh64JZQa3MHyRutba8p2xFGAp7vpvy40xtiavYfdEh/Xu/9Y YrxQuvbFVJ8FheigRKtd6haVQyRbZuEn4j4jQDwc0UohDDlpo6OkPgsIhoLMeLtv1Ack X7GQrz+nuTXPiBZ+7KOvrlB2Oby3wWne7ppYNsM3H1J11qRE3dSbC8MrF4kYA6f7iFZX 2FUH8fA8AmzSYyW1QZccq0we7ZFJCAvf9NJgtUmttoPnyskfuN74ZUuucdoHKNXnjh4M c28g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693247778; x=1693852578; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ky9ruWT4vMi1n23k32PoOKd6l441oU0lu6dvfmODcBE=; b=JtlZtB6PSlzb+K5IoTfUjoChVy/Af6W0Q5AY3KqSDTD3m7GDkq9Z7VOtvA0wxALAOh RrgWWPp24d/2ZQgMX0dg2iUr68aMIiZPZoqETwwFvAF2saRWvzYRwYE/enornbHwb7xA BpiJT9VU46GiouToDjLN7gVXUy6lnqshPQWm4UH4FoE0KBjoQdk8epXAO23NTPQdNJME +twrji6UxQ4nMA5LYO6W068fHZnW8E1gYlFwyWoLXY6xBiHmh6yZuwf/u/nTSNhjimah 5hOh10OeoIB0BGXShQx8AHaqX0XqPPyhuyiEqjMEq6R0xhA3Fv2J2uS8uUHkJZ/cKqMm iprQ== X-Gm-Message-State: AOJu0Yy34XTUf0sheGzAstOAkDGgTwZDGyfpFVW+tmH6BmRh8D3qZVum +CSIV/eie9j6eivhMIde2nWeE1g/j2thf3q8FoRkNg== X-Google-Smtp-Source: AGHT+IGoX9r8qV2+PRF2exaC/8e7oKCwn+UPVDoYH35VTmhKB1fHbsyxlxeaty+mSX20B9Q+nZZK5C5LVHJZbEZEgcc= X-Received: by 2002:a17:906:74c7:b0:9a1:d2ef:3e3c with SMTP id z7-20020a17090674c700b009a1d2ef3e3cmr12047640ejl.44.1693247778067; Mon, 28 Aug 2023 11:36:18 -0700 (PDT) MIME-Version: 1.0 References: <20230821205458.1764662-4-yosryahmed@google.com> <599b167c-deaf-4b92-aa8b-5767b8608483@redhat.com> <307cbcf6-dca2-0b5d-93e8-11368a931d2f@redhat.com> <820843a5-d7a5-91a9-b861-99e7132ddb98@redhat.com> In-Reply-To: <820843a5-d7a5-91a9-b861-99e7132ddb98@redhat.com> From: Yosry Ahmed Date: Mon, 28 Aug 2023 11:35:41 -0700 Message-ID: Subject: Re: [PATCH 3/3] mm: memcg: use non-unified stats flushing for userspace reads To: Waiman Long Cc: Shakeel Butt , Michal Hocko , Andrew Morton , Johannes Weiner , Roman Gushchin , Muchun Song , Ivan Babrou , Tejun Heo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: aauwy4nqi8px71urauwaijyyuy8ac6qb X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: BAD0014002B X-Rspam-User: X-HE-Tag: 1693247779-408353 X-HE-Meta: U2FsdGVkX1/jPfMy98VvpOhx48+rfRrQH8KliTa8sCuVQizhHhNY+sb7RcTGbFxqj/QDJ+7N3tX1DjFAmm2HekfMAkA4AVJDjpNO+uPIN6u6jRVgLJtrc/OB30AWAimw183Bq2tqmAaCjnaUSMCErgj58z4flsyxqg4uQDAKtCVYZL6+kpC2OWoO9cNOQY9qv/5v36P2w42PfkaF7RVdsX2hNd/eM65B2v070ln8cwItBF38uaSGW9OB2/LbrQcTOQOZ9uXmgKG0+00aTCA7PAeMWfXTOfFC9NKXeSgLkRuceEGnWUXmRykRCQW9YGSzRHfLTCEnk3v4bupq/RVmvvUgjKDdKGG3gBfMpQhDT/3Gnd1HjyGLqry766ySwRgllqHDwGU3vft4FcYLBfqIh3tLnFdbIwlhIeOrE875+g+Zcj+++buitm648etMtID/wSPYdeJyxoNEYhmv5CqbtI63hrpYkeqIzngrHXaVGky7DgivHsryiiaJZOriQ6PIKZk9JcQi5v6ePTs5bL7Jab91X0SPZzYzMnXIZC6tcbcXoPhDASZ4Qm2MbxxcmrNMs99FhMQS1FSImwEXPZBsGHnJ3MKAH8U6N8W2rkLoXIdB8HgRYM8RDlDJHb2krRUpdHTuPvGEL1i/XE0am4YK5sQr8Zw1cNAIrRPEbKaAAoKwXUETRBh2LmRqfL3gA0Z3kc6VKeSjzCRM0w6Mi0tNblTobEJOfJPYHWnJyesbXHBBDCAK6FeG9IN97Z4z/3CeC1Rk4yd2XTkUiOv5zeDhEtj4DuJjIgVUxbyD6GSxwfScyhyijyrW8UvO7qZnTmlpwF6Mzi90iZiumEsgOP/GE2MSJFtyQxF3L0K+F41xQcXbQZQOMkk+zAINkGW3uctbixoRboRZXHcv9lPqAI2aq65HzozV9sxG0sTOpbswoEHj8V5D2KeYZzNkh2zfPnxCtb/INy+mmcEMPc4fMTM ucqtJsTf ZHQF4dyb6cDKprztrHzZ++BJIoXFSYcfZI7evHUM0pEO7sULjV0jvtIS5WDhoHjygzoHGGjx0x8gZB4ir0eRZhW60zxz8227wAGrEIXtuwrMNrb+XNuundlmLsB5+rmDTUe0F6ORIC+TfOmC4kFY5HuCJZmujGyd44XB0waMDP6uR8NRps0aNdJooDUpkb76AhK/57dcAcyqahi4vVkVeB1dgGksbAKWoEesGbBCMVxtgFVenb2B9uKmmWw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Aug 28, 2023 at 10:43=E2=80=AFAM Waiman Long w= rote: > > > On 8/28/23 13:35, Waiman Long wrote: > > On 8/28/23 13:28, Yosry Ahmed wrote: > >> On Mon, Aug 28, 2023 at 10:27=E2=80=AFAM Waiman Long wrote: > >>> > >>> On 8/28/23 13:07, Yosry Ahmed wrote: > >>>>> Here I agree with you. Let's go with the approach which is easy to > >>>>> undo for now. Though I prefer the new explicit interface for > >>>>> flushing, > >>>>> that step would be very hard to undo. Let's reevaluate if the > >>>>> proposed > >>>>> approach shows negative impact on production traffic and I think > >>>>> Cloudflare folks can give us the results soon. > >>>> Do you prefer we also switch to using a mutex (with preemption > >>>> disabled) to avoid the scenario Michal described where flushers give > >>>> up the lock and sleep resulting in an unbounded wait time in the wor= st > >>>> case? > >>> Locking with mutex with preemption disabled is an oxymoron. Use > >>> spinlock > >>> if you want to have preemption disabled. The purpose of usiing mutex = is > >>> to allow the lock owner to sleep, but you can't sleep with preemption > >>> disabled. You need to enable preemption first. You can disable > >>> preemption for a short time in a non-sleeping section of the lock > >>> critical section, but I would not recommend disabling preemption for > >>> the > >>> whole critical section. > >> I thought using a mutex with preemption disabled would at least allow > >> waiters to sleep rather than spin, is this not correct (or doesn't > >> matter) ? > > > > Because of optimistic spinning, a mutex lock waiter will only sleep if > > the lock holder sleep or when its time slice run out. So the waiters > > are likely to spin for quite a while before they go to sleep. I see. Thanks for the explanation. > > Perhaps you can add a mutex at the read side so that only 1 reader can > contend with the global rstat spinlock at any time if this is a concern. I guess we can keep it simple for now and add that later if needed. For unified flushers we already can only have one. If we see a problem from the stat reading side we can add a mutex there. Thanks!