Message ID | 20230328221644.803272-9-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 b10csp5955vqo; Tue, 28 Mar 2023 15:20:45 -0700 (PDT) X-Google-Smtp-Source: AKy350Y0agRZmm6DD6eWqn0yiJkJWPL6/YyJ6r2JUflvgAanJp24udcSLlQhCKs6Vkx2kFvwvoN0 X-Received: by 2002:a17:902:d40a:b0:1a0:57dd:b340 with SMTP id b10-20020a170902d40a00b001a057ddb340mr12028249ple.64.1680042045376; Tue, 28 Mar 2023 15:20:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680042045; cv=none; d=google.com; s=arc-20160816; b=CwKmGCzrnanCC+6Vc/EOvXvky37k/W6DOfmMGFgwGeIpLj2ExJKMugregsK+tiufLd 7zGaNCSJNzVSY6LJNmk6HK4n+/1fK3RCsH4qvhSxBd8d/gf2Fpz8Feo9c5bUvwJMm+He d2patsEati7K2PsXAlplJG/gXqJ26YKlUXBfsazK6gcMKiTojzuyymLBpWZAtExSOIDq /8V5XEoNvgygZ+emoBr/zFtsaVkVPfZNvZAwUAeGk48ytnPOzpM1mt7Gn+MS1S9DWlpl 12QWhC+IKbjpQpwz14JsFFluE31N00bLD1eQnBLCOvmkYoWR8Y9vfQMEY3Uub3mz71yG qlPQ== 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=AvW0vRtvUGz6RfpHjuJf5DcrLtUCw4uDLtzj7kPXkaI=; b=tKTTN15pDQOcbUBdJYsWgN65xaCfTCyBythyOUG3HNMM2km30C3B8FRPwFEj4vsv47 h0EgqoR/rAC2cjLMko8mCmJyznHeYc/y0nZNk3uIHyMCvWty6GJj0zq17XWp6+z+40e8 ZP8StPwMBQWG++lc8+ucpIlgz1uIM0tPBe1UouQl0zo8oS5hn6hGT8TCPjwhQHuUf/R0 B84I1q3C1EuSRGo+GFrscFWeGay1VwP+O1wzohSD+DkvzkdV7yqLZVK00Xf0VOAhRN5/ dsKgTQRbzblyF1e8JRgEKwGD+XdDUEzs6njIPPKrYnYdH3UsdC4Lv52ATiqIIwSHU2Ug UJfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=s2Rhy6bh; 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 h11-20020a65480b000000b00513576ea7casi5028434pgs.795.2023.03.28.15.20.32; Tue, 28 Mar 2023 15:20:45 -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=s2Rhy6bh; 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 S230146AbjC1WRy (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Tue, 28 Mar 2023 18:17:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230137AbjC1WRR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 28 Mar 2023 18:17:17 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1F7835AE for <linux-kernel@vger.kernel.org>; Tue, 28 Mar 2023 15:17:06 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id j11-20020a25230b000000b00b6871c296bdso13319108ybj.5 for <linux-kernel@vger.kernel.org>; Tue, 28 Mar 2023 15:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680041825; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=AvW0vRtvUGz6RfpHjuJf5DcrLtUCw4uDLtzj7kPXkaI=; b=s2Rhy6bhmsxOtwUgNmtWPZ1OIy2px3+ZgcKdui8SYbOasl9GBmkC/HgOP+eca1phsP jP5oqLAVmD71L+yTcF9Qf7RNoZtsSSFPX0S6Mq6S5HfUed3nW8TUcaJtaUm/tsI8O9Am d5OJg/swbll5+1GgM/EDnx0GyYjs89Yzqk1B1Gc+8UCS388fxVzDgMBm93/UJRyrTJYr f1CeTGEfaowg6ARY0FoahfZMcN2kOGoi1UzCuTmmzShA86ZvRPo5Rcmo6znhWB9xOjYc VRAX/Gquhhjvyizfw+QszvCjk77JT0+yZFVam4Xqz3PGsmr5F2QrldBe6NoQ8SARTtvR pWDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680041825; 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=AvW0vRtvUGz6RfpHjuJf5DcrLtUCw4uDLtzj7kPXkaI=; b=YsTlMVe+OTSxIQ2CgnJ8LiK6MUrKdQHMa/KLQh7VgDpZKpPnmocQM158yahwWEfvvU r4LpZC/q+bpshCs5jX9Ec0WA+b7BJBGUqyEIKpOF4rMlkLDChdd4/OyTpfx9ntJNaGTz aFv10pSrGwIo+9IKWQOZavxDbpHCxqSeZt1Utgz0zqZC7IwUDl7ga/KgNbXWAJZI5Hrc SIM+KZ3NzgGJIcdL0mqAWuS6RpLDP5vi7wsHtk+io5beW1uVMBttxdOlWeMcGV7spBnF mMWy1td/1c7ecLm/iOTWqnXF7XHgL0uHdUVdrTpmk+o4jxMM7C/Nk9U18pwzM7hJrwpH 5ITg== X-Gm-Message-State: AAQBX9cizHBFrRl5MI5rVZP3gUf1vp6sRgR3bqtd5GcXwvkA3UzgJPQH tRhBf1j4PMcUSago245ZrybQ+wJTLCJPHD/L X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a05:6902:722:b0:a09:314f:a3ef with SMTP id l2-20020a056902072200b00a09314fa3efmr10887537ybt.12.1680041825151; Tue, 28 Mar 2023 15:17:05 -0700 (PDT) Date: Tue, 28 Mar 2023 22:16:43 +0000 In-Reply-To: <20230328221644.803272-1-yosryahmed@google.com> Mime-Version: 1.0 References: <20230328221644.803272-1-yosryahmed@google.com> X-Mailer: git-send-email 2.40.0.348.gf938b09366-goog Message-ID: <20230328221644.803272-9-yosryahmed@google.com> Subject: [PATCH v2 8/9] vmscan: memcg: sleep when flushing stats during reclaim 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?1761651767695249435?= X-GMAIL-MSGID: =?utf-8?q?1761651767695249435?= |
Series |
memcg: make rstat flushing irq and sleep
|
|
Commit Message
Yosry Ahmed
March 28, 2023, 10:16 p.m. UTC
Memory reclaim is a sleepable context. Allow sleeping when flushing memcg stats to avoid unnecessarily performing a lot of work without sleeping. This can slow down reclaim code if flushing stats is taking too long, but there is already multiple cond_resched()'s in reclaim code. Signed-off-by: Yosry Ahmed <yosryahmed@google.com> Acked-by: Shakeel Butt <shakeelb@google.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue 28-03-23 22:16:43, Yosry Ahmed wrote: > Memory reclaim is a sleepable context. Allow sleeping when flushing > memcg stats to avoid unnecessarily performing a lot of work without > sleeping. This can slow down reclaim code if flushing stats is taking > too long, but there is already multiple cond_resched()'s in reclaim > code. Why is this preferred? Memory reclaim is surely a slow path but what is the advantage of calling mem_cgroup_flush_stats here? > Signed-off-by: Yosry Ahmed <yosryahmed@google.com> > Acked-by: Shakeel Butt <shakeelb@google.com> > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > --- > mm/vmscan.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index a9511ccb936f..9c1c5e8b24b8 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2845,7 +2845,7 @@ static void prepare_scan_count(pg_data_t *pgdat, struct scan_control *sc) > * Flush the memory cgroup stats, so that we read accurate per-memcg > * lruvec stats for heuristics. > */ > - mem_cgroup_flush_stats_atomic(); > + mem_cgroup_flush_stats(); > > /* > * Determine the scan balance between anon and file LRUs. > -- > 2.40.0.348.gf938b09366-goog
On Thu, Mar 30, 2023 at 12:40 AM Michal Hocko <mhocko@suse.com> wrote: > > On Tue 28-03-23 22:16:43, Yosry Ahmed wrote: > > Memory reclaim is a sleepable context. Allow sleeping when flushing > > memcg stats to avoid unnecessarily performing a lot of work without > > sleeping. This can slow down reclaim code if flushing stats is taking > > too long, but there is already multiple cond_resched()'s in reclaim > > code. > > Why is this preferred? Memory reclaim is surely a slow path but what is > the advantage of calling mem_cgroup_flush_stats here? The purpose of this series is to limit calls to atomic flushing as much as possible, as flushing can become really expensive on systems with high cpu counts and a lot of cgroups, and performing such an expensive operation atomically causes problems -- so we'd rather avoid doing it atomically where possible. > > > Signed-off-by: Yosry Ahmed <yosryahmed@google.com> > > Acked-by: Shakeel Butt <shakeelb@google.com> > > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > > --- > > mm/vmscan.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index a9511ccb936f..9c1c5e8b24b8 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -2845,7 +2845,7 @@ static void prepare_scan_count(pg_data_t *pgdat, struct scan_control *sc) > > * Flush the memory cgroup stats, so that we read accurate per-memcg > > * lruvec stats for heuristics. > > */ > > - mem_cgroup_flush_stats_atomic(); > > + mem_cgroup_flush_stats(); > > > > /* > > * Determine the scan balance between anon and file LRUs. > > -- > > 2.40.0.348.gf938b09366-goog > > -- > Michal Hocko > SUSE Labs
On Thu 30-03-23 00:44:10, Yosry Ahmed wrote: > On Thu, Mar 30, 2023 at 12:40 AM Michal Hocko <mhocko@suse.com> wrote: > > > > On Tue 28-03-23 22:16:43, Yosry Ahmed wrote: > > > Memory reclaim is a sleepable context. Allow sleeping when flushing > > > memcg stats to avoid unnecessarily performing a lot of work without > > > sleeping. This can slow down reclaim code if flushing stats is taking > > > too long, but there is already multiple cond_resched()'s in reclaim > > > code. > > > > Why is this preferred? Memory reclaim is surely a slow path but what is > > the advantage of calling mem_cgroup_flush_stats here? > > The purpose of this series is to limit calls to atomic flushing as > much as possible, as flushing can become really expensive on systems > with high cpu counts and a lot of cgroups, and performing such an > expensive operation atomically causes problems -- so we'd rather avoid > doing it atomically where possible. Please add that to the changelog. While the intention might be obvious now (although cover is not explicit about it either) it can cause some head scratching in the future when somebody looks at this commit without a broader context (e.g. previous ML discussions). with that Acked-by: Michal Hocko <mhocko@suse.com> Thanks > > > Signed-off-by: Yosry Ahmed <yosryahmed@google.com> > > > Acked-by: Shakeel Butt <shakeelb@google.com> > > > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > > > --- > > > mm/vmscan.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > index a9511ccb936f..9c1c5e8b24b8 100644 > > > --- a/mm/vmscan.c > > > +++ b/mm/vmscan.c > > > @@ -2845,7 +2845,7 @@ static void prepare_scan_count(pg_data_t *pgdat, struct scan_control *sc) > > > * Flush the memory cgroup stats, so that we read accurate per-memcg > > > * lruvec stats for heuristics. > > > */ > > > - mem_cgroup_flush_stats_atomic(); > > > + mem_cgroup_flush_stats(); > > > > > > /* > > > * Determine the scan balance between anon and file LRUs. > > > -- > > > 2.40.0.348.gf938b09366-goog > > > > -- > > Michal Hocko > > SUSE Labs
On Thu, Mar 30, 2023 at 12:52 AM Michal Hocko <mhocko@suse.com> wrote: > > On Thu 30-03-23 00:44:10, Yosry Ahmed wrote: > > On Thu, Mar 30, 2023 at 12:40 AM Michal Hocko <mhocko@suse.com> wrote: > > > > > > On Tue 28-03-23 22:16:43, Yosry Ahmed wrote: > > > > Memory reclaim is a sleepable context. Allow sleeping when flushing > > > > memcg stats to avoid unnecessarily performing a lot of work without > > > > sleeping. This can slow down reclaim code if flushing stats is taking > > > > too long, but there is already multiple cond_resched()'s in reclaim > > > > code. > > > > > > Why is this preferred? Memory reclaim is surely a slow path but what is > > > the advantage of calling mem_cgroup_flush_stats here? > > > > The purpose of this series is to limit calls to atomic flushing as > > much as possible, as flushing can become really expensive on systems > > with high cpu counts and a lot of cgroups, and performing such an > > expensive operation atomically causes problems -- so we'd rather avoid > > doing it atomically where possible. > > Please add that to the changelog. While the intention might be obvious > now (although cover is not explicit about it either) it can cause some > head scratching in the future when somebody looks at this commit without > a broader context (e.g. previous ML discussions). > > with that > Acked-by: Michal Hocko <mhocko@suse.com> Thanks, will do for the respin. > Thanks > > > > > Signed-off-by: Yosry Ahmed <yosryahmed@google.com> > > > > Acked-by: Shakeel Butt <shakeelb@google.com> > > > > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > > > > --- > > > > mm/vmscan.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > > index a9511ccb936f..9c1c5e8b24b8 100644 > > > > --- a/mm/vmscan.c > > > > +++ b/mm/vmscan.c > > > > @@ -2845,7 +2845,7 @@ static void prepare_scan_count(pg_data_t *pgdat, struct scan_control *sc) > > > > * Flush the memory cgroup stats, so that we read accurate per-memcg > > > > * lruvec stats for heuristics. > > > > */ > > > > - mem_cgroup_flush_stats_atomic(); > > > > + mem_cgroup_flush_stats(); > > > > > > > > /* > > > > * Determine the scan balance between anon and file LRUs. > > > > -- > > > > 2.40.0.348.gf938b09366-goog > > > > > > -- > > > Michal Hocko > > > SUSE Labs > > -- > Michal Hocko > SUSE Labs
diff --git a/mm/vmscan.c b/mm/vmscan.c index a9511ccb936f..9c1c5e8b24b8 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2845,7 +2845,7 @@ static void prepare_scan_count(pg_data_t *pgdat, struct scan_control *sc) * Flush the memory cgroup stats, so that we read accurate per-memcg * lruvec stats for heuristics. */ - mem_cgroup_flush_stats_atomic(); + mem_cgroup_flush_stats(); /* * Determine the scan balance between anon and file LRUs.