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 B53A2C76196 for ; Tue, 28 Mar 2023 19:00:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08ECB6B0071; Tue, 28 Mar 2023 15:00:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 017176B0072; Tue, 28 Mar 2023 15:00:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD2806B0074; Tue, 28 Mar 2023 15:00:39 -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 CA06D6B0071 for ; Tue, 28 Mar 2023 15:00:39 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 880F9A04B0 for ; Tue, 28 Mar 2023 19:00:39 +0000 (UTC) X-FDA: 80619223398.07.ED157B2 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf05.hostedemail.com (Postfix) with ESMTP id 6B084100013 for ; Tue, 28 Mar 2023 19:00:37 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hGNPwQWT; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680030037; 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=VaFE8MJ/rJnWu49G6qaf7Zeu9SjJjHyr+HaKIIGZlo8=; b=56/H1TmW+2Q0TCXtK9rYUghcbL4cXR+U9KXz7cFuSz75dNmhd6/KQ5q3npCdVzdx4I8Rgw rZMSAHFzWcPFJS/4B3FI1lJCJxsGi+3dgwDFGE0fjWjr7JZdr1pmjTsmPNOPuj8l+rdWBW gyo2mfJJfUo8eKVtFy1b2OCxIxTI75E= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hGNPwQWT; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680030037; a=rsa-sha256; cv=none; b=5taG+QjQcd01vBsLkp+1L2wcacQtk+l8JW8wLWrzPfLtw154CzO7Y/qj10qpevEenhvsi+ fx+kpoA7qS0l7H+d9Au032kqybalcPA4woyvheItJwWj9NckiZ3vBdIYwQ1X1eSa8S3ewp Re4rg1XXVffF/4K9JwnFLPvDh3kUKn4= Received: by mail-ed1-f43.google.com with SMTP id w9so53856516edc.3 for ; Tue, 28 Mar 2023 12:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680030036; 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=VaFE8MJ/rJnWu49G6qaf7Zeu9SjJjHyr+HaKIIGZlo8=; b=hGNPwQWTEYe3CZmGYHi60X2aSfRWtVK8WiJ7nu3mjdJk4YmjuiqYe9pQ+CDJlPYyxd /pi9trbtJtSOm7MifwcGnSBImrwX+6Z42snV0nbBlJ7UXJ/eKh48Yn/EV7NYVDSmmbPt Rb0l9k4E3FCIRsq0+yQqNxV2ey483qI2f6DnbBWaNsDKB3buuC+B9cupFif5N8kLGalN EqIH5K8IIPJWWoiCFHfQlnBM7LhKzgagHTbCa9LC7C/ObuzCHw9amKjqLxPdo/JKx3RO c+XsEE64L2GpM8WO4QZD+clco6JbOEINCGSlyDLrWKVTxZp91kvGAVcL2J04SbpNs5mz w6JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680030036; 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=VaFE8MJ/rJnWu49G6qaf7Zeu9SjJjHyr+HaKIIGZlo8=; b=WWoXkJr+Yl7i5UUmVnKUJVv4ctNlorgK0IrhA1mJ0mx/pL8dNsnGD5VVFbs/5030wb wSFNSMt+6yg7VDiru+K2dkpw0V2b/GZMe4Jd2vszN5ZySvZ4y7itidWoCDWvIzwWlozl 8Y+MdQ89anoDvY5/J9ecdmH5Bo42WM4sXxJlGfWs5wBeRPRGqC6nQfcW5QryRbn3+KTU GCtf2IC8xK38a+F3QIfzbTYPm3HUAMaA5vFcHnF9s2g8QsmOt3NF9bOWUPwC3IuRyaGf Ix/pWxhUPONjAJVZeX2j68+FuD96ENP7pF1gfe30f18Uc9JXEhF4sC25iF1Ae+EtVnB8 oCEQ== X-Gm-Message-State: AAQBX9dUkV+zzAOSvuzimkJeRno2jp8n7t+dVKeIzkMCxyYFmlhJfUUK sWY4qWTUtX1NTJtAiea8rMfb/QquiP5YmPEGti+xJA== X-Google-Smtp-Source: AKy350Yhk/i0+JPviKO6ga1I/DH2EtAh9hdlzqBienFUiCmmezrhPlteMpnkr+v35C7I9/6s8VzBjh8YFxr470tp00Q= X-Received: by 2002:a50:d756:0:b0:4fc:e5c:902 with SMTP id i22-20020a50d756000000b004fc0e5c0902mr8274473edj.8.1680030035893; Tue, 28 Mar 2023 12:00:35 -0700 (PDT) MIME-Version: 1.0 References: <20230328061638.203420-1-yosryahmed@google.com> <20230328061638.203420-5-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 28 Mar 2023 11:59:59 -0700 Message-ID: Subject: Re: [PATCH v1 4/9] cgroup: rstat: add WARN_ON_ONCE() if flushing outside task context To: Johannes Weiner Cc: Tejun Heo , Josef Bacik , Jens Axboe , Zefan Li , Michal Hocko , Roman Gushchin , Shakeel Butt , 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: rspam02 X-Rspamd-Queue-Id: 6B084100013 X-Stat-Signature: zwim491hz9d1hsahnh86f9ma5934i1k3 X-HE-Tag: 1680030037-154726 X-HE-Meta: U2FsdGVkX1/O6+6xkZyGcS5aNECSeypRMG3f51TElH9NL3K6PzTxEwfGI0uzVUy5M2I099MMFyPJSoI7kvFHLbSm+f1DxtdDVh39Fc/yQw03F0DdBlK8OwtAeXZxRkrJHfbgvQKpufogC1uI9NGNqyyUkLuNhYEVHe8MXopBeQzjQ2oMQyoavSthf9ntm9wqLs8MxEweYO55ljjb1uxDVHjlFO9ozXAxKtP2rwaQOkzog4OQ5q0na+O+KKvoc8xvXNmDpQfUI+ffTIUM/s0faz3ulA/d/9Xp6y4NdolOiLAFrIvE0tUVcyKHMaIQJzTLzNl51AE9spcLgtGJ1Cf3VkWZtrtFXE7nxrLZRK1/dTBH5vmP1B1KUbLb26Fo8x1Xjwc8h9JjKD4UxtwbAiLhiOStppsbSAEoV0Zleju90yJ0WXYI58ukLIJaLcwTxwHQvPV0iDTxu9TWpkxY6ijQ2ti9t25EI65OkPFgXTSkocwBW9sqClb3C+GStEjAUHwyf/3igk0kEKXpSYnNvk6okOxIb8Bn5cLqZqFAEjPzzb1w4NcJEX4NjASTpZ/0EOkQUEgO8ex+sXSfO2z8sW3xhTJuC5IkaKtzhJOYgBjbLG3EX8Erx1X8iMh8kUTuf0gkhydLccXxLrLgPuqRgr9y6kaGWoeFTVod0FmS88cbJZI2tcy2n3weqD+SsRGVPiEny4jxTdK5sKk3u689EF2TmggzEwy1K8lPR+vpovQvt7TgcHZsFvGnilZxGDddbaRTwY1vzIcaet+vporfECuPotlBMvKAXP1dzDD4ZtX2j+BkWzoD2w17R4y7zudvKt81qSIIQmLUwH/Do+gtf5PlbJdbOmEt5JCdk8lwiKbGnrUg65bHsKqZmyPqL+NFeGuli7TUG+o8DQSmqjZNvRvZifJ67RepDXztQw6udPp+L/QIhAhiDWRnX/XmKqx5ymffjRq8efQmke8zTVGcspl 00vWgwyF /xhNKXoRwB9COiW1hO9RpikwzCgKsdlfSpiFer88d7DTLf+pw5ZMcUQ5CKybwDBj4u7LTL+sT1lDCUWrFi3i6+Y+M8s0AaRbEIrJ/PR83EGNp0ZLRjKWMp9zrNK5HBe4dDR+/+jeee5H+U82IJ5ZRYkrsMImFgLaIAndRPW9QAttgspFmbAP4w6KSFStX4P/Rh57giNl8AzPYir52qmJK0YTSTqhN+ErnXk/fi1Wnm19qAthoSqgvVvMJ9jv1BC/ZrCZICCcRZpxUydCbmDiKy3aN9w1T/8VVnBi+vlWybGTo5JkLZ25ZxBMD31DdT0fD9teScZ7WgJzLI+0EovhpKe+MKNplFBk6nxVxDCKZbu2wpexEjHPah9bDlg== 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 Tue, Mar 28, 2023 at 10:49=E2=80=AFAM Johannes Weiner wrote: > > On Tue, Mar 28, 2023 at 06:16:33AM +0000, Yosry Ahmed wrote: > > rstat flushing is too expensive to perform in irq context. > > The previous patch removed the only context that may invoke an rstat > > flush from irq context, add a WARN_ON_ONCE() to detect future > > violations, or those that we are not aware of. > > > > Signed-off-by: Yosry Ahmed > > --- > > kernel/cgroup/rstat.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c > > index d3252b0416b6..c2571939139f 100644 > > --- a/kernel/cgroup/rstat.c > > +++ b/kernel/cgroup/rstat.c > > @@ -176,6 +176,8 @@ static void cgroup_rstat_flush_locked(struct cgroup= *cgrp, bool may_sleep) > > { > > int cpu; > > > > + /* rstat flushing is too expensive for irq context */ > > + WARN_ON_ONCE(!in_task()); > > lockdep_assert_held(&cgroup_rstat_lock); > > This seems a bit arbitrary. Why is an irq caller forbidden, but an > irq-disabled, non-preemptible section caller is allowed? The latency > impact on the system would be the same, right? Thanks for taking a look. So in the first patch series the initial purpose was to make sure cgroup_rstat_lock was never acquired in an irq context, so that we can stop disabling irqs while holding it. Tejun disagreed with this approach though. We currently have one caller that calls flushing with irqs disabled (mem_cgroup_usage()) -- so we cannot forbid such callers (yet), but I thought we can at least forbid callers from irq context now (or catch those that we are not aware of), and then maybe forbid irqs_disabled() contexts as well we can get rid of that callsite. WDYT?