Message ID | 20230328061638.203420-5-yosryahmed@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2004558vqo; Mon, 27 Mar 2023 23:22:08 -0700 (PDT) X-Google-Smtp-Source: AKy350YaK+kN2+yyF7evJzcOhpjtaSNp3POUBIy8ikI/lFNCiae3bxur4t9Xj4RybTCnZ+aK0027 X-Received: by 2002:aa7:dbcb:0:b0:501:fd71:7e18 with SMTP id v11-20020aa7dbcb000000b00501fd717e18mr15163123edt.2.1679984528121; Mon, 27 Mar 2023 23:22:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679984528; cv=none; d=google.com; s=arc-20160816; b=KI8I5s58zlWQKO+B39IXFzINgC2mHXBrSnLrtdU31bArF8U526zZGEqg94ziAZI0Uw eHA0tlHChScqhvIAA+1MufI+TkXElQ0d5UiJn4MLgg/maKOTIm4Xyk40OynHNOuJzVGh MLob0z7cfnhBaQyp9pjrWIALdjL57TDuRMNgKI1Z4RQ+hY0tpFDyTP7isw70vnJSzPjM xsoZQTZulJdabacMgowm77FecGCMfZQd8iVzk2amYkEXTchk6ftNsexHVHXbWurbizZD HFiBBtuAOZYeOAHtG29xQ4g+EECfTZg8evlcZmtD/3Vf442b3HkQtoUeAGrYo27rXD3V 5tcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=+vNiceMoZ2PdzrNG/xVeRzEo7O+ovCZNHcQMp7VClk4=; b=hZeFVm1TlFsRnVdJPuo8oeZU01IWal58g9MzhzTxf8NUmsZIsptjTXb/GD4izVXj82 umRPR35+T9WN0pFQODEwMMh4y/Lk+eZM8RmoRacwIydihwq8DKQWxxZhi2+23ucSz+jy mvEfAlPOuUrqNK09B9mM1hNwN3Z6UZMTe1yHGMjeOucpJ3eLApTsEhbCV07HJi0XPWeZ xo96LRLAtJAOVZ+L4Ymrlen7sWBIdqO0Zn8gOovzsrRziWaQKJIUwxIsy0zy1YhHQD4r l+J16qEDveDQR7AnFKNR/4Q+SYoELE0A8gSetQbgKEC7bRmCsRaTmFphRmNvBNXlCkRD bf0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=FtVms547; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z5-20020aa7c645000000b004fc19199fd6si26956509edr.143.2023.03.27.23.21.44; Mon, 27 Mar 2023 23:22:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=FtVms547; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232625AbjC1GRe (ORCPT <rfc822;kartikey406@gmail.com> + 99 others); Tue, 28 Mar 2023 02:17:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232502AbjC1GRF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 28 Mar 2023 02:17:05 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0CC835B6 for <linux-kernel@vger.kernel.org>; Mon, 27 Mar 2023 23:16:49 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id q15-20020a63d60f000000b00502e1c551aaso3002136pgg.21 for <linux-kernel@vger.kernel.org>; Mon, 27 Mar 2023 23:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1679984209; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=+vNiceMoZ2PdzrNG/xVeRzEo7O+ovCZNHcQMp7VClk4=; b=FtVms547YGVdf9XAqjguoo0WST2Bomcq4pMeCW3qlg0ksZV5swPoVz0GmrxFu8vfrh HBzgJptVGGKy7geKpBPvC2PsWo0HmjT2F27i9dbdVA6zCF4EYemeZRNrh89DbSPqLObX h82tbSvZ/WCeLjLtii1Meb+k3BLVneGl+TdsHqmfTXT/vAFZIC+/S3Aw9k3ElSrpUy7X 9xgxQRUTlE19S9rQfATi59HRnf65TEpEpviTmJbLID2U9/qvSayVfcGFQGEl03zvUEu5 uDhGnK3XWBy1kJngfOB04Odcd1UeEO5WA33WjKyVDhleLQy8k50zMQSY0RXklX82o1Jn CmFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679984209; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+vNiceMoZ2PdzrNG/xVeRzEo7O+ovCZNHcQMp7VClk4=; b=kK8uZbg+oTUmTeBmvVzUVdy6zltfhI3DEFToy5S6M/JHn5FIpxHBwFt1upFEvHfsIT jshcRb5WjddkuxwlmFt8nKatoq1GqrBgxzeQm7k9seG+Il1wjvNL9OPNrHiy1ecmOu37 eNgK8XHO+cDCHwyY7K8sK4ST6eo5JsKGviOe7ygz3oPAdiO7xSimxXjH/O7iAt9Ldcaq 7VCtGNrSMjGsTsooUcN2OC96pDb6VSjWOBNNvAcCxdLS5JURdcLTE4vooYkLhYLBNdSL UpFGvu7JRQhNv2KcQcvnV5DZSeeqCJvwrKsj0sBzEpNKXdb0tUbhK9g26Vrgg5npWZsq Tkiw== X-Gm-Message-State: AAQBX9e8SZ8OHEX4bVAYpG/M7glCdUkbh0YI/c9MfUYyQs5L+AWkvQeQ lZp11N31zOqDrCMdqfZKnoirl8GzxYYQ/JaP X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a05:6a00:1a46:b0:625:c7de:48c1 with SMTP id h6-20020a056a001a4600b00625c7de48c1mr7269994pfv.4.1679984209151; Mon, 27 Mar 2023 23:16:49 -0700 (PDT) Date: Tue, 28 Mar 2023 06:16:33 +0000 In-Reply-To: <20230328061638.203420-1-yosryahmed@google.com> Mime-Version: 1.0 References: <20230328061638.203420-1-yosryahmed@google.com> X-Mailer: git-send-email 2.40.0.348.gf938b09366-goog Message-ID: <20230328061638.203420-5-yosryahmed@google.com> Subject: [PATCH v1 4/9] cgroup: rstat: add WARN_ON_ONCE() if flushing outside task context From: Yosry Ahmed <yosryahmed@google.com> To: Tejun Heo <tj@kernel.org>, Josef Bacik <josef@toxicpanda.com>, Jens Axboe <axboe@kernel.dk>, Zefan Li <lizefan.x@bytedance.com>, Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@kernel.org>, Roman Gushchin <roman.gushchin@linux.dev>, Shakeel Butt <shakeelb@google.com>, Muchun Song <muchun.song@linux.dev>, Andrew Morton <akpm@linux-foundation.org>, " =?utf-8?q?Michal_Koutn=C3=BD?= " <mkoutny@suse.com> Cc: Vasily Averin <vasily.averin@linux.dev>, cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org, Yosry Ahmed <yosryahmed@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761591456371677306?= X-GMAIL-MSGID: =?utf-8?q?1761591456371677306?= |
Series |
memcg: make rstat flushing irq and sleep friendly
|
|
Commit Message
Yosry Ahmed
March 28, 2023, 6:16 a.m. UTC
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 <yosryahmed@google.com>
---
kernel/cgroup/rstat.c | 2 ++
1 file changed, 2 insertions(+)
Comments
On Mon, Mar 27, 2023 at 11:16 PM Yosry Ahmed <yosryahmed@google.com> 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 <yosryahmed@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com>
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 <yosryahmed@google.com> > --- > 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?
On Tue, Mar 28, 2023 at 10:49 AM Johannes Weiner <hannes@cmpxchg.org> 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 <yosryahmed@google.com> > > --- > > 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?
On Tue, Mar 28, 2023 at 11:59 AM Yosry Ahmed <yosryahmed@google.com> wrote: > > On Tue, Mar 28, 2023 at 10:49 AM Johannes Weiner <hannes@cmpxchg.org> 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 <yosryahmed@google.com> > > > --- > > > 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? I added more context in the commit log in the v2 respin [1]. Let me know if you want me to change something else, rephrase the comment, or drop the patch entirely. [1]https://lore.kernel.org/linux-mm/20230328221644.803272-5-yosryahmed@google.com/
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); for_each_possible_cpu(cpu) {