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 B6ADAC761AF for ; Thu, 30 Mar 2023 08:07:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29088900002; Thu, 30 Mar 2023 04:07:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2413C6B0078; Thu, 30 Mar 2023 04:07:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10AF3900002; Thu, 30 Mar 2023 04:07:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F11986B0075 for ; Thu, 30 Mar 2023 04:07:06 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7F5C31A08AD for ; Thu, 30 Mar 2023 08:07:06 +0000 (UTC) X-FDA: 80624834052.18.963D987 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf24.hostedemail.com (Postfix) with ESMTP id AC6E9180004 for ; Thu, 30 Mar 2023 08:07:04 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Dsrmlf6S; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.54 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=1680163624; 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=I9/OZbBvN+GYY+k6VNhkbPsCuwIDJGgvOD15HQAmaC4=; b=NIStdZnfargzbJAE0JZkTLJ1lVWQHqJ6cltVOesZJuOCSUA8FXgbCkXA5LjfyYc5setfIT Be6mnpfTTLJwvuaasloK8B5h6mQwzpFgMmdJchsGvPrTJxtL9ToIKu4rlcKZvv/mXfW394 Nfnvc8togfamKYx6mAXHUGv02zM/ztg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Dsrmlf6S; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680163624; a=rsa-sha256; cv=none; b=TWyMy8MAVRsJwkUDeN1NGRnx26Qscm5vIM1UTq88dG48huB0BCTagjAgsQRogbsEpjjsSC pZGcFY7cDzGDeHcmZQKFg9vnWWfAawbQ2fDucvwpXNgxu86Yg+xPBUMdjYbk/oVvDo90Bf DuX+FQOcjy+gpA6Q3EQSeFRwM3uz/30= Received: by mail-ed1-f54.google.com with SMTP id ew6so73134413edb.7 for ; Thu, 30 Mar 2023 01:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680163623; 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=I9/OZbBvN+GYY+k6VNhkbPsCuwIDJGgvOD15HQAmaC4=; b=Dsrmlf6SQ7dieSEewhGmRqcjAnISmY3AXD9YHFTWUr8d+rNOpPZJaTLj6dySdAJBmS 2QtMKaqtURSXtYTkG0ZC4UmNj6SQdXGiCRKn4ol9GUN33Z9cvEGcATJXOWKZqMvTfIwf QhPCIRe1EuHaGXZkRDNRZSBsvvOSCKbdsMoAnDpHTvNBHEdWh2VFjjbS2q3CAxFG3btu 9+MI5lzCPRk1D1xVAU7NB+C21NNfqBlxd2VKiRIhMGqXWDHEF52eu7YEHYU0MDOcj+bg 5qY4+RVkbmlN5SerigkhW3HND52Iysgu6N4mDyqx0XKW8vxxRsMx5p6SzsEYAB9yGwzi J4rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680163623; 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=I9/OZbBvN+GYY+k6VNhkbPsCuwIDJGgvOD15HQAmaC4=; b=04iA71HgLwsxfmEP2bWi8EsUCH17MnHkRX3LatzUEDqC7wlH3IfZ5dXlZe2H0ZtJgU Vx1n70CzOJg0sbd67BPeP81zfjGq8wrU7EMN7rkGzgpnj1QQBHVZI1YvT2Wy2KN9nThA O5+VEWjnK5icjqg1XuqqADg7hfMXi4WwuS6SsVMlqg4icjT/L0kr9LDI/ozlU363nJZx Z+CIy+UuzJfAqCKpOJpUsZuwgh7GunPLJI4+IOwaCPtmDkBr7TBkCrx7s0h/IJ/gNUsv E6+6tXFOEfS1NW5YnVWWe133HWg8jxr9q6g1FH16yIcPjNq6buYaLHjbZeRAcXlb14X+ Vl2g== X-Gm-Message-State: AAQBX9fGI//pjXQBAWActGNeONQ741RDKsYto6sWfGNSHOFdfyrPgw6G HURCFw7LELZDh/x5aATl2HM0EqzeN5R1TiHnPYB3gw== X-Google-Smtp-Source: AKy350bAfMXdd5ybBW9MntO/LYBeu0+13bGoVOKRQbfwOov/1/I9J3qNCI1MgUJs6HRYlq94hLg/UkBhLlt4JxBxOF0= X-Received: by 2002:a17:907:6a95:b0:947:72cd:9325 with SMTP id ri21-20020a1709076a9500b0094772cd9325mr229031ejc.15.1680163623142; Thu, 30 Mar 2023 01:07:03 -0700 (PDT) MIME-Version: 1.0 References: <20230328221644.803272-1-yosryahmed@google.com> <20230328221644.803272-5-yosryahmed@google.com> <20230329192059.2nlme5ubshzdbpg6@google.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 30 Mar 2023 01:06:26 -0700 Message-ID: Subject: Re: [PATCH v2 4/9] cgroup: rstat: add WARN_ON_ONCE() if flushing outside task context To: Michal Hocko Cc: Johannes Weiner , Shakeel Butt , Tejun Heo , Josef Bacik , Jens Axboe , Zefan Li , Roman Gushchin , Muchun Song , Andrew Morton , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Vasily Averin , cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AC6E9180004 X-Stat-Signature: u1fihu1i13afjimxmbwiu33hgcwgjnrf X-HE-Tag: 1680163624-294835 X-HE-Meta: U2FsdGVkX18GD8FAipKaTaTZLjNb4hAlLg6V58awaiElm4fNjKquiQW/JMa1+9GFGeL5DvUIBFoKhnieDqsqFGEgHfff6szCy4U5OfS0FDidFD3qPOQVi22/K49YmCq6g1g7lMXtHzQ4nlkiGSKeHgl7xzLAW1N1fl4VID2+htjVsKt17Pw4x+JqMRkYCUIBJSimfWZi7rTYHY129AIFgwTRqIJ55T6WgKkS/+YKCoO4/Q14/lPq9L035y3/EW/VHwr5eh/qpiCo3FdoVKCd2kcCqL8zbztYWZMqiy+0L83jHUoDDXr1nvj0w02DInddUjlrkUX+7UfUpIZ7JWnHSQLw6wcEmbeg88890YeEsXsQsvJpXe6gMHK3Ek+XdZoQ0ZYRXaBEhN2vh3D0+JPk+gUfS01aZg0UfgSTtM6Ip7M8kTo247LibwBPPebHKM8cXarbqphAaeqRZ8cP8fgl8HkqvCMXHbeABWtAZEIzDqCIE3rIi0bU8vRQyhC3qbVlwdNd7Cq9p3MQGwxO/OqZN2qQrhrpaCATeKoOXGY1S3HED1wPzXGvAKSCt7Zw+jiRm3fJJwIDu4cKJks1muZmtgHm1834htWIwvNRAXS6ePPiccghkDfbzJwax/oDVlpzxEYFI5A+Zwuw9Zcf+96mdoyk6AopMPeu+Jv/Goc6CIAX2zrCw0hhGiLLwYNCuELxXpau2menYAS7A3tMjFTBmGs02YsIbvrRJvofMmsW6R4VZdC0Px0JTnZ3WRuocg2FzFUMZ9f1Y56npjXX3AQ/7O/VIH6Pe6fSGsmCPnTDfLXwUw6QaCTGfc76zc30PEFUiXndnE2wPnrZBtJ9tfSpo5XjINPkQd4MwERH5+JRt9Ga1mZ3xpuIHQtYWGJUnMYHPXWd8rjOFB/17g/Zj+3PxhsRxLcfWxRt6bDzoGMiGg0i0v2R529SbWqesWzU2cCQ/FeIk1Rf7GBG2jFQ0t+ guCEp/z3 hnMknue9IQ1trQ3YBqjTsaURHzGSR1gl+OnaIKNBZopO4yOVqYOAKN14lEYqiqzAsgYL3iDo5l3ODmAmPmqadu9BkP27WHvAuzHOC5cOCu6kmN08nU2ogOhhAAqpnlHTQ1/mVxPT94tTZtxVGapcP68jo2wsM5V6tTJ1KmtPcPXI20Bi6/2tLXth79b7QY/sElApybQGj5dpIeupqSMAAfidYqN766iXWB8lXZz9M4lFWjBA5HLWBdNgkgqAV2gTYEHfy2OAgjkITKOu8QzzOg49LgqnS6HV//rMxIAZDvzrkGC7Sfr8jvfUrjIABAl5MtaOiqaY+hEH7DgeVPlbNBOQ3muqyspzx2KbrwGD51xJ9z7M0aHrEL0XK9JzEGFuktBvFLinnq0FgGtTOAZn1gJXuMNGJp1viqtTwzOpHMOg6xZ+sa3qufGWNcA== 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 Thu, Mar 30, 2023 at 12:49=E2=80=AFAM Michal Hocko wro= te: > > On Thu 30-03-23 00:13:16, Yosry Ahmed wrote: > > On Thu, Mar 30, 2023 at 12:06=E2=80=AFAM Michal Hocko = wrote: > [...] > > > So the real question is. Do we really care so deeply? After all someb= ody > > > might be calling this from within a spin lock or irq disabled section > > > resulting in a similar situation without noticing. > > > > There are discussions in [1] about making atomic rstat flush not > > disable irqs throughout the process, so in that case it would only > > result in a similar situation if the caller has irq disabled. The only > > caller that might have irq disabled is the same caller that might be > > in irq context before this series: mem_cgroup_usage(). > > > > On that note, and while I have your attention, I was wondering if we > > can eliminate the flush call completely from mem_cgroup_usage(), and > > read the global stats counters for root memcg instead of the root > > counters. There might be subtle differences, but the root memcg usage > > isn't super accurate now anyway (e.g. it doesn't include kernel > > memory). > > root memcg stats are imprecise indeed and I have to admit I do not > really know why we are adding more work for that case. I have tried to > dig into git history for that yesterday but couldn't find a satisfying > answer. It goes all the way down to 2d146aa3aa842 which has done the > switch to rstat. Maybe Johannes remembers. I think it goes back even before that. Even before rstat, we used to get the root usage by iterating over the hierarchy. Maybe we didn't have the global counters at some point or they weren't in line with the root memcg (e.g. use_hierarchy =3D 0). It would be great if we can just use the global counters here. Hopefully Johannes can confirm or deny this. > > Anyway, back to this particular patch. I still do not see strong reasons > to be verbose about !in_task case so I would just drop this patch. I will drop this patch in the next iteration. If I implement a patch that makes rstat flushing not disable irqs all throughout (like [1]), whether part of this series or not, and we remove flushing from mem_cgroup_usage(), then at this point: - No existing flushers will be disabling irqs. - rstat flushing itself will not be disabling irqs throughout the entire fl= ush. If we achieve that, do you think it makes sense to add WARN_ON_ONCE(irqs_disabled()) instead to prevent future users from flushing while disabling irqs or in irq context? All I am trying to achieve here is make sure we don't regress. I don't want to minimize the current atomic flushers now only to have them increase later. [1] https://lore.kernel.org/lkml/CAJD7tkZrp=3D4zWvjE9_010TAG1T_crCbf9P64UzJ= ABspgcrGPKg@mail.gmail.com/ > -- > Michal Hocko > SUSE Labs