From nobody Sun Feb 8 05:30:15 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9AB3C83F14 for ; Mon, 28 Aug 2023 23:34:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234385AbjH1Xd4 (ORCPT ); Mon, 28 Aug 2023 19:33:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234353AbjH1Xd1 (ORCPT ); Mon, 28 Aug 2023 19:33:27 -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 B04B5129 for ; Mon, 28 Aug 2023 16:33:24 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id 41be03b00d2f7-55afcc54d55so4719599a12.0 for ; Mon, 28 Aug 2023 16:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693265604; x=1693870404; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=9qA6GTuqMP/rKfRIqhAnRSpZvROd0PfSA6OAmdp3iwc=; b=Y50mBPgL4ZnkSNZPluDfxqKm78sl1PPL8DiBaO19bDXgbRQJe1evxnOtKTQpEKaJt9 q6TFZ3ydpr0Iw287D1OlWUwjUcpdUuXymoPCstZstIPkQOj45oKQlFtnKtjN/mbLEvhM o9GCuUO1ZEUXUUx28qzHrrmiTuYE2TYf6adAH5P9xxUWLusmQEIv/Oe70pHaiYbwOVfm oMqTZe5koJnHF0raIu3Xd3TXHK4UNZwUPvI/t+PGnq6Qn7V4/toAyK3UAB+IEgfCPW4e xQTid6or7KJCLcX0Z+QlSvZSxNkrkenRrCxd7dBhnnRCQKzILS7s/2q/I8bBvCq1Ofti cLVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693265604; x=1693870404; 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=9qA6GTuqMP/rKfRIqhAnRSpZvROd0PfSA6OAmdp3iwc=; b=MYZFVWKAIulVtIhNxO+b3TwPu6v4HQaD/zEwOgeHRGkZ6zZwCjgue9W42J2LIPAw+M aqblJqE0jPdNWdF0px7CrNGMH4lwrssbTSC5NdbQMwdfWIfag754B2aFyTiUtyS2IS07 3S+Z30hOubp3Tj7ETiHIvfNuj9CFYthiYQq4UCFA8O3IahwCVxoNBf8LNMwIJMYgkGvR 9gHi4B4rTafDNkP9qoyKvXvyVBspVvAeXZiyQGHW7q/0sQJWHZhHqiEaKsS/hI1JSje4 UfbCn28LMmA6AfSRd87v/rXhg1wZ2PRTOolt9CUmAF1z1X1DhG4TtfDi3gQ7fuJM4Jmm tAKA== X-Gm-Message-State: AOJu0Yxu1if+2qPgQirw3sGSz9HG2guxNNFtKWa+vvI/Ca4ipHktcRSv LPo1bHDvbAV5CSuTBnhQaJt3+dGCTnm7aoj3 X-Google-Smtp-Source: AGHT+IFAK9Y6dgVDrmbxac+NiYlaeGIY5ZOe1MFU0Kqd9mAZdB6yEnhkHBiWrdmzYBIlnQNCLJdURVSriZmVyWHy X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a17:90a:408a:b0:26d:5ce:b77f with SMTP id l10-20020a17090a408a00b0026d05ceb77fmr272628pjg.1.1693265604159; Mon, 28 Aug 2023 16:33:24 -0700 (PDT) Date: Mon, 28 Aug 2023 23:33:15 +0000 In-Reply-To: <20230828233319.340712-1-yosryahmed@google.com> Mime-Version: 1.0 References: <20230828233319.340712-1-yosryahmed@google.com> X-Mailer: git-send-email 2.42.0.rc2.253.gd59a3bf2b4-goog Message-ID: <20230828233319.340712-2-yosryahmed@google.com> Subject: [PATCH v2 1/4] mm: memcg: properly name and document unified stats flushing From: Yosry Ahmed To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Ivan Babrou , Tejun Heo , "=?UTF-8?q?Michal=20Koutn=C3=BD?=" , Waiman Long , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Yosry Ahmed Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Most contexts that flush memcg stats use "unified" flushing, where basically all flushers attempt to flush the entire hierarchy, but only one flusher is allowed at a time, others skip flushing. This is needed because we need to flush the stats from paths such as reclaim or refaults, which may have high concurrency, especially on large systems. Serializing such performance-sensitive paths can introduce regressions, hence, unified flushing offers a tradeoff between stats staleness and the performance impact of flushing stats. Document this properly and explicitly by renaming the common flushing helper from do_flush_stats() to do_unified_stats_flush(), and adding documentation to describe unified flushing. Additionally, rename flushing APIs to add "try" in the name, which implies that flushing will not always happen. Also add proper documentation. No functional change intended. Signed-off-by: Yosry Ahmed --- include/linux/memcontrol.h | 8 +++--- mm/memcontrol.c | 53 ++++++++++++++++++++++++++------------ mm/vmscan.c | 2 +- mm/workingset.c | 4 +-- 4 files changed, 43 insertions(+), 24 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 11810a2cfd2d..d517b0cc5221 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -1034,8 +1034,8 @@ static inline unsigned long lruvec_page_state_local(s= truct lruvec *lruvec, return x; } =20 -void mem_cgroup_flush_stats(void); -void mem_cgroup_flush_stats_ratelimited(void); +void mem_cgroup_try_flush_stats(void); +void mem_cgroup_try_flush_stats_ratelimited(void); =20 void __mod_memcg_lruvec_state(struct lruvec *lruvec, enum node_stat_item i= dx, int val); @@ -1519,11 +1519,11 @@ static inline unsigned long lruvec_page_state_local= (struct lruvec *lruvec, return node_page_state(lruvec_pgdat(lruvec), idx); } =20 -static inline void mem_cgroup_flush_stats(void) +static inline void mem_cgroup_try_flush_stats(void) { } =20 -static inline void mem_cgroup_flush_stats_ratelimited(void) +static inline void mem_cgroup_try_flush_stats_ratelimited(void) { } =20 diff --git a/mm/memcontrol.c b/mm/memcontrol.c index cf57fe9318d5..c6150ea54d48 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -630,7 +630,7 @@ static inline void memcg_rstat_updated(struct mem_cgrou= p *memcg, int val) /* * If stats_flush_threshold exceeds the threshold * (>num_online_cpus()), cgroup stats update will be triggered - * in __mem_cgroup_flush_stats(). Increasing this var further + * in mem_cgroup_try_flush_stats(). Increasing this var further * is redundant and simply adds overhead in atomic update. */ if (atomic_read(&stats_flush_threshold) <=3D num_online_cpus()) @@ -639,13 +639,17 @@ static inline void memcg_rstat_updated(struct mem_cgr= oup *memcg, int val) } } =20 -static void do_flush_stats(void) +/* + * do_unified_stats_flush - do a unified flush of memory cgroup statistics + * + * A unified flush tries to flush the entire hierarchy, but skips if there= is + * another ongoing flush. This is meant for flushers that may have a lot of + * concurrency (e.g. reclaim, refault, etc), and should not be serialized = to + * avoid slowing down performance-sensitive paths. A unified flush may ski= p, and + * hence may yield stale stats. + */ +static void do_unified_stats_flush(void) { - /* - * We always flush the entire tree, so concurrent flushers can just - * skip. This avoids a thundering herd problem on the rstat global lock - * from memcg flushers (e.g. reclaim, refault, etc). - */ if (atomic_read(&stats_flush_ongoing) || atomic_xchg(&stats_flush_ongoing, 1)) return; @@ -658,16 +662,31 @@ static void do_flush_stats(void) atomic_set(&stats_flush_ongoing, 0); } =20 -void mem_cgroup_flush_stats(void) +/* + * mem_cgroup_try_flush_stats - try to flush memory cgroup statistics + * + * Try to flush the stats of all memcgs that have stat updates since the l= ast + * flush. We do not flush the stats if: + * - The magnitude of the pending updates is below a certain threshold. + * - There is another ongoing unified flush (see do_unified_stats_flush()). + * + * Hence, the stats may be stale, but ideally by less than FLUSH_TIME due = to + * periodic flushing. + */ +void mem_cgroup_try_flush_stats(void) { if (atomic_read(&stats_flush_threshold) > num_online_cpus()) - do_flush_stats(); + do_unified_stats_flush(); } =20 -void mem_cgroup_flush_stats_ratelimited(void) +/* + * Like mem_cgroup_try_flush_stats(), but only flushes if the periodic flu= sher + * is late. + */ +void mem_cgroup_try_flush_stats_ratelimited(void) { if (time_after64(jiffies_64, READ_ONCE(flush_next_time))) - mem_cgroup_flush_stats(); + mem_cgroup_try_flush_stats(); } =20 static void flush_memcg_stats_dwork(struct work_struct *w) @@ -676,7 +695,7 @@ static void flush_memcg_stats_dwork(struct work_struct = *w) * Always flush here so that flushing in latency-sensitive paths is * as cheap as possible. */ - do_flush_stats(); + do_unified_stats_flush(); queue_delayed_work(system_unbound_wq, &stats_flush_dwork, FLUSH_TIME); } =20 @@ -1576,7 +1595,7 @@ static void memcg_stat_format(struct mem_cgroup *memc= g, struct seq_buf *s) * * Current memory state: */ - mem_cgroup_flush_stats(); + mem_cgroup_try_flush_stats(); =20 for (i =3D 0; i < ARRAY_SIZE(memory_stats); i++) { u64 size; @@ -4018,7 +4037,7 @@ static int memcg_numa_stat_show(struct seq_file *m, v= oid *v) int nid; struct mem_cgroup *memcg =3D mem_cgroup_from_seq(m); =20 - mem_cgroup_flush_stats(); + mem_cgroup_try_flush_stats(); =20 for (stat =3D stats; stat < stats + ARRAY_SIZE(stats); stat++) { seq_printf(m, "%s=3D%lu", stat->name, @@ -4093,7 +4112,7 @@ static void memcg1_stat_format(struct mem_cgroup *mem= cg, struct seq_buf *s) =20 BUILD_BUG_ON(ARRAY_SIZE(memcg1_stat_names) !=3D ARRAY_SIZE(memcg1_stats)); =20 - mem_cgroup_flush_stats(); + mem_cgroup_try_flush_stats(); =20 for (i =3D 0; i < ARRAY_SIZE(memcg1_stats); i++) { unsigned long nr; @@ -4595,7 +4614,7 @@ void mem_cgroup_wb_stats(struct bdi_writeback *wb, un= signed long *pfilepages, struct mem_cgroup *memcg =3D mem_cgroup_from_css(wb->memcg_css); struct mem_cgroup *parent; =20 - mem_cgroup_flush_stats(); + mem_cgroup_try_flush_stats(); =20 *pdirty =3D memcg_page_state(memcg, NR_FILE_DIRTY); *pwriteback =3D memcg_page_state(memcg, NR_WRITEBACK); @@ -6610,7 +6629,7 @@ static int memory_numa_stat_show(struct seq_file *m, = void *v) int i; struct mem_cgroup *memcg =3D mem_cgroup_from_seq(m); =20 - mem_cgroup_flush_stats(); + mem_cgroup_try_flush_stats(); =20 for (i =3D 0; i < ARRAY_SIZE(memory_stats); i++) { int nid; diff --git a/mm/vmscan.c b/mm/vmscan.c index c7c149cb8d66..457a18921fda 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2923,7 +2923,7 @@ static void prepare_scan_count(pg_data_t *pgdat, stru= ct scan_control *sc) * Flush the memory cgroup stats, so that we read accurate per-memcg * lruvec stats for heuristics. */ - mem_cgroup_flush_stats(); + mem_cgroup_try_flush_stats(); =20 /* * Determine the scan balance between anon and file LRUs. diff --git a/mm/workingset.c b/mm/workingset.c index da58a26d0d4d..affb8699e58d 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -520,7 +520,7 @@ void workingset_refault(struct folio *folio, void *shad= ow) } =20 /* Flush stats (and potentially sleep) before holding RCU read lock */ - mem_cgroup_flush_stats_ratelimited(); + mem_cgroup_try_flush_stats_ratelimited(); =20 rcu_read_lock(); =20 @@ -664,7 +664,7 @@ static unsigned long count_shadow_nodes(struct shrinker= *shrinker, struct lruvec *lruvec; int i; =20 - mem_cgroup_flush_stats(); + mem_cgroup_try_flush_stats(); lruvec =3D mem_cgroup_lruvec(sc->memcg, NODE_DATA(sc->nid)); for (pages =3D 0, i =3D 0; i < NR_LRU_LISTS; i++) pages +=3D lruvec_page_state_local(lruvec, --=20 2.42.0.rc2.253.gd59a3bf2b4-goog From nobody Sun Feb 8 05:30:15 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B937AC83F15 for ; Mon, 28 Aug 2023 23:34:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234418AbjH1Xd6 (ORCPT ); Mon, 28 Aug 2023 19:33:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234356AbjH1Xd3 (ORCPT ); Mon, 28 Aug 2023 19:33:29 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A794B12D for ; Mon, 28 Aug 2023 16:33:26 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d7496b913e7so4450680276.3 for ; Mon, 28 Aug 2023 16:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693265606; x=1693870406; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=I5n9hS9q/cqFV2qh34A2AZEA4DGYELaonjfoFoCAI8g=; b=sSpYPt7rKW3DtUM15JcLQJplUoRrPMx95M/aXCWUkUGG4gZ450QgwVE4yFUm7CogQH zFv9UI4D9YSxvW6bodhDxj3Ik66YmhEKFtQN01JiGkk9R6pRwoVFGBpQEhzaG5mXyhg+ 7vKrj39/+K2fsqeCBVG9cqcEQsLe/O8dA6loSupqE+p8mxgQd1Y/Cch38q9mTgfWAdOU Mi/PT8DoWdqlQunEGCPiAM+0xArU4vTZKSIUUhJFt8vF/ApSZdUHhIi/YFoCfVUArao7 1xkMsp1FV1LDKVh9Dm5/i7gS4Zp0X1DnugiYstil6izVooJ18sBWRLBaLBmogvidXImj ZLUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693265606; x=1693870406; 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=I5n9hS9q/cqFV2qh34A2AZEA4DGYELaonjfoFoCAI8g=; b=kw12MwxbXbYXAEQ6SIK49f/IYg0qTWjXilxPM+12wlPJJeAG56ea9SxU+cSijnqVcB 5LdIPMH+z0bkIk7kAznincR0RxZlOB8SrL2nFodBqxGzpH5DFHl2S3N5QZLHGk/O7vrN F9CC7Zy7hyNO86qBlmhQpNFzsHziqqfxrlMlwdyItzFzHkjLMNt5cmxvbzz+tpOt30Ip mGbdUq9a1bl3Bw49dGuhYkpjsEvYJ002foN5wpQxuKyq8SHGZ+wWQIHFm4Y4TQIlIsO8 WpaYXyFU7OlgdpWto2kftxQAxfrLJEufs1p32JrIJ7HXMpmGHenCtTTo9Cj0Bs6YWmcH RAEA== X-Gm-Message-State: AOJu0YxXp9gGQbu2n+dOeXLhnO7r8koWG2c0O3idpmyUD1WRPwYbsXWx 3G0b36+ZNqwCvtsmRBZMtiOIBI/+wtzMFOcc X-Google-Smtp-Source: AGHT+IHgw1Dv81YEOafHari2+haF5L0KUBFcH2n6KPrSQNlL17+4o9VM2wgivkwVdbEOE7or4T1k1wZFPbeokEu2 X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a05:6902:1788:b0:d78:3a29:214f with SMTP id ca8-20020a056902178800b00d783a29214fmr506633ybb.10.1693265605965; Mon, 28 Aug 2023 16:33:25 -0700 (PDT) Date: Mon, 28 Aug 2023 23:33:16 +0000 In-Reply-To: <20230828233319.340712-1-yosryahmed@google.com> Mime-Version: 1.0 References: <20230828233319.340712-1-yosryahmed@google.com> X-Mailer: git-send-email 2.42.0.rc2.253.gd59a3bf2b4-goog Message-ID: <20230828233319.340712-3-yosryahmed@google.com> Subject: [PATCH v2 2/4] mm: memcg: add a helper for non-unified stats flushing From: Yosry Ahmed To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Ivan Babrou , Tejun Heo , "=?UTF-8?q?Michal=20Koutn=C3=BD?=" , Waiman Long , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Yosry Ahmed Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Some contexts flush memcg stats outside of unified flushing, directly using cgroup_rstat_flush(). Add a helper for non-unified flushing, a counterpart for do_unified_stats_flush(), and use it in those contexts, as well as in do_unified_stats_flush() itself. This abstracts the rstat API and makes it easy to introduce modifications to either unified or non-unified flushing functions without changing callers. No functional change intended. Signed-off-by: Yosry Ahmed --- mm/memcontrol.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index c6150ea54d48..90f08b35fa77 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -639,6 +639,17 @@ static inline void memcg_rstat_updated(struct mem_cgro= up *memcg, int val) } } =20 +/* + * do_stats_flush - do a flush of the memory cgroup statistics + * @memcg: memory cgroup to flush + * + * Only flushes the subtree of @memcg, does not skip under any conditions. + */ +static void do_stats_flush(struct mem_cgroup *memcg) +{ + cgroup_rstat_flush(memcg->css.cgroup); +} + /* * do_unified_stats_flush - do a unified flush of memory cgroup statistics * @@ -656,7 +667,7 @@ static void do_unified_stats_flush(void) =20 WRITE_ONCE(flush_next_time, jiffies_64 + 2*FLUSH_TIME); =20 - cgroup_rstat_flush(root_mem_cgroup->css.cgroup); + do_stats_flush(root_mem_cgroup); =20 atomic_set(&stats_flush_threshold, 0); atomic_set(&stats_flush_ongoing, 0); @@ -7790,7 +7801,7 @@ bool obj_cgroup_may_zswap(struct obj_cgroup *objcg) break; } =20 - cgroup_rstat_flush(memcg->css.cgroup); + do_stats_flush(memcg); pages =3D memcg_page_state(memcg, MEMCG_ZSWAP_B) / PAGE_SIZE; if (pages < max) continue; @@ -7855,8 +7866,10 @@ void obj_cgroup_uncharge_zswap(struct obj_cgroup *ob= jcg, size_t size) static u64 zswap_current_read(struct cgroup_subsys_state *css, struct cftype *cft) { - cgroup_rstat_flush(css->cgroup); - return memcg_page_state(mem_cgroup_from_css(css), MEMCG_ZSWAP_B); + struct mem_cgroup *memcg =3D mem_cgroup_from_css(css); + + do_stats_flush(memcg); + return memcg_page_state(memcg, MEMCG_ZSWAP_B); } =20 static int zswap_max_show(struct seq_file *m, void *v) --=20 2.42.0.rc2.253.gd59a3bf2b4-goog From nobody Sun Feb 8 05:30:15 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB40DC83F17 for ; Mon, 28 Aug 2023 23:34:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234436AbjH1XeA (ORCPT ); Mon, 28 Aug 2023 19:34:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234358AbjH1Xda (ORCPT ); Mon, 28 Aug 2023 19:33:30 -0400 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 831D112D for ; Mon, 28 Aug 2023 16:33:28 -0700 (PDT) Received: by mail-pf1-x449.google.com with SMTP id d2e1a72fcca58-68bff8f3351so4636139b3a.3 for ; Mon, 28 Aug 2023 16:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693265608; x=1693870408; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=cdnModp3UHPesHrMiYbasA77T6X4L8s34myJUUsNDqw=; b=BaJDLeW20NuEFec2oAO68NEPY8XNBrqkpeisxk5dZbxgnWHQ0r2PhoENHFifb29a85 wkcQ36f5pboCfp5upZdXeouVQ/0c7EuGiOlftOTQ7QED4HRVXJaE8f3Wet7A9n2Rj856 vSFPpwUufWhdTYEK9e0YxtG9T7V5niVLg1OGtXwve+hU15y1awhfiS+ph4sxssMScLfY 3FyWbOnA+EFg7ZsT4U1Ke97tXPWCjqO0X2CsZjdqw14iDY0ncsKKN+1F4C/05uDjI0Yu Vcck/XfFVgXP+e2uByfABv9Rt2GwqKStdZUxd2y8AJciGF9zoxxWBpNJ74POirqQMS0t +/dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693265608; x=1693870408; h=content-transfer-encoding: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=cdnModp3UHPesHrMiYbasA77T6X4L8s34myJUUsNDqw=; b=N64/T2/8SUcXug2XYejTh2N4gHN/dKOA7vOiRQq27kO8Ey4B9FC9FITvSTfHCZeTCV cVtbPbpU7dvolgxUbOnNhQB58iAwjvOnmkBuZUAnYffWr2102puWLz21744AfKKCyJX1 oNfeJbAIWbreISQ6hbXDyGLMF3QdksEsIuLg8D7cbIlE6ogSvdlU555JwOS5d/2pVUFt 5XyNnQl7S+OsMsg6P6I3wJifvV8gcnYo6VlMPEym2UXA2/hv4rEebCIsWUjN1vJz2u8M b6PFiw7cfO8gS9vd4OEHU/xVZIurQcpA3mnV3Gq3jwUm8o16kEed+psGRgdS85OWqsE3 PKsA== X-Gm-Message-State: AOJu0YxaqVb6hZa5akJOv/om3dk2FCIsFzISkRvJMMt2Z+j0vGD/jkAl AMNy4QHCiY6Nu8aKZbCdea8J1CBWkQZDRFGZ X-Google-Smtp-Source: AGHT+IHAq4VgXKo8P6aYPET0HHb7Rp2LuZeLVocuW54MrcmyDai0zFV6jlRJW28aJMih5PpmlindTt5puuPdOpLx X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a05:6a00:13a7:b0:68a:5467:9974 with SMTP id t39-20020a056a0013a700b0068a54679974mr8979137pfg.0.1693265607909; Mon, 28 Aug 2023 16:33:27 -0700 (PDT) Date: Mon, 28 Aug 2023 23:33:17 +0000 In-Reply-To: <20230828233319.340712-1-yosryahmed@google.com> Mime-Version: 1.0 References: <20230828233319.340712-1-yosryahmed@google.com> X-Mailer: git-send-email 2.42.0.rc2.253.gd59a3bf2b4-goog Message-ID: <20230828233319.340712-4-yosryahmed@google.com> Subject: [PATCH v2 3/4] mm: memcg: let non-unified root stats flushes help unified flushes From: Yosry Ahmed To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Ivan Babrou , Tejun Heo , "=?UTF-8?q?Michal=20Koutn=C3=BD?=" , Waiman Long , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Yosry Ahmed Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Unified flushing of memcg stats keeps track of the magnitude of pending updates, and only allows a flush if that magnitude exceeds a threshold. It also keeps track of the time at which ratelimited flushing should be allowed as flush_next_time. A non-unified flush on the root memcg has the same effect as a unified flush, so let it help unified flushing by resetting pending updates and kicking flush_next_time forward. Move the logic into the common do_stats_flush() helper, and do it for all root flushes, unified or not. There is a subtle change here, we reset stats_flush_threshold before a flush rather than after a flush. This probably okay because: (a) For flushers: only unified flushers check stats_flush_threshold, and those flushers skip anyway if there is another unified flush ongoing. Having them also skip if there is an ongoing non-unified root flush is actually more consistent. (b) For updaters: Resetting stats_flush_threshold early may lead to more atomic updates of stats_flush_threshold, as we start updating it earlier. This should not be significant in practice because we stop updating stats_flush_threshold when it reaches the threshold anyway. If we start early and stop early, the number of atomic updates remain the same. The only difference is the scenario where we reset stats_flush_threshold early, start doing atomic updates early, and then the periodic flusher kicks in before we reach the threshold. In this case, we will have done more atomic updates. However, since the threshold wasn't reached, then we did not do a lot of updates anyway. Suggested-by: Michal Koutn=C3=BD Signed-off-by: Yosry Ahmed --- mm/memcontrol.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 90f08b35fa77..f3716478bf4e 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -647,6 +647,11 @@ static inline void memcg_rstat_updated(struct mem_cgro= up *memcg, int val) */ static void do_stats_flush(struct mem_cgroup *memcg) { + /* for unified flushing, root non-unified flushing can help as well */ + if (mem_cgroup_is_root(memcg)) { + WRITE_ONCE(flush_next_time, jiffies_64 + 2*FLUSH_TIME); + atomic_set(&stats_flush_threshold, 0); + } cgroup_rstat_flush(memcg->css.cgroup); } =20 @@ -665,11 +670,7 @@ static void do_unified_stats_flush(void) atomic_xchg(&stats_flush_ongoing, 1)) return; =20 - WRITE_ONCE(flush_next_time, jiffies_64 + 2*FLUSH_TIME); - do_stats_flush(root_mem_cgroup); - - atomic_set(&stats_flush_threshold, 0); atomic_set(&stats_flush_ongoing, 0); } =20 --=20 2.42.0.rc2.253.gd59a3bf2b4-goog From nobody Sun Feb 8 05:30:15 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD3FEC83F11 for ; Mon, 28 Aug 2023 23:34:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234450AbjH1XeB (ORCPT ); Mon, 28 Aug 2023 19:34:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234361AbjH1Xdc (ORCPT ); Mon, 28 Aug 2023 19:33:32 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05C7712D for ; Mon, 28 Aug 2023 16:33:30 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id d9443c01a7336-1c0c64035b8so46359275ad.0 for ; Mon, 28 Aug 2023 16:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693265609; x=1693870409; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=wRGpIX3lyKI055RI8cMjafWOHR4EuDVDQeE9aWNLVUM=; b=eoDxnQJF3X52LCWoBIxxsewZGAjILMgMJpEG4EXQ2YAh0jGR93SKaYdX81UglrX6fo 1wKEaixnEVtkrTCbB/CHL7SnwHFabZVbsYdY6keYxwCeXgS6yY/2Kto8tSYSMEJ/Y2YG pN89ky8l7MzmQ1FBTbeb5i+s04d3wUfDyK8F758aH26chFWvDGxLJn0ispz/NJwci9YX zZyG7Q8Xdlaanlqu4MxEXr+HClTY0BRCmUuRbsTIW6YTWap0g/zatE8xcF8lie3HxjPZ icLK7HqerVKwHQ7cBYh7IgKJ5U1e/mmoItt4cDNTSXRVs/dV4Xbtf/Jcf41tWtLG9YIA UabQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693265609; x=1693870409; 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=wRGpIX3lyKI055RI8cMjafWOHR4EuDVDQeE9aWNLVUM=; b=cTPNeFQhmBz8gG5tKk3h7FwnrrYgxi3PBI+PxGY6ZqwHIekkxHVEhxgUAkArvmAP2D SGm15hZ/buy36hGA71DllIevT68j2pYBjCC8GSrGa/hxGhZaurSbaUOTi1ZeXIO4ZYaQ vtC4gQxjNLfQ7h/jZhNTrROI+1OTKK4fVfQgIADxIw3TlAYLMIkYJCxQjzsgAFxbFFgb vWr4Ws9wd84qBj6nORtzq0HRPnfkURLQHnD9bh7chk+bRkJ6010i4+UPmQpxKbtaLT89 q7cGzZl3p3MKma8COwFGm1gnu+lFGY8zkKqHzYUJyc364UA0f/QUqAM31P08zfnopYnE HEEw== X-Gm-Message-State: AOJu0YzhFZEBSFZgjLA9Zn7Leoo1wrvR9Nit58kViikHsxNjysb/oU81 owqbWS4ECd+ue3o6+/NELLEHqVNTy8yQ+W25 X-Google-Smtp-Source: AGHT+IHG/TRKUOO5sYh5EIId++RdUCNl9wMlTbyfze6/NjsSKmPfNT57qBN5bgwEcgW3z1bCs66pOUtMUV59CqzY X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a17:902:dacd:b0:1bc:1866:fd0f with SMTP id q13-20020a170902dacd00b001bc1866fd0fmr9420007plx.9.1693265609521; Mon, 28 Aug 2023 16:33:29 -0700 (PDT) Date: Mon, 28 Aug 2023 23:33:18 +0000 In-Reply-To: <20230828233319.340712-1-yosryahmed@google.com> Mime-Version: 1.0 References: <20230828233319.340712-1-yosryahmed@google.com> X-Mailer: git-send-email 2.42.0.rc2.253.gd59a3bf2b4-goog Message-ID: <20230828233319.340712-5-yosryahmed@google.com> Subject: [PATCH v2 4/4] mm: memcg: use non-unified stats flushing for userspace reads From: Yosry Ahmed To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Ivan Babrou , Tejun Heo , "=?UTF-8?q?Michal=20Koutn=C3=BD?=" , Waiman Long , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Yosry Ahmed Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Unified flushing allows for great concurrency for paths that attempt to flush the stats, at the expense of potential staleness and a single flusher paying the extra cost of flushing the full tree. This tradeoff makes sense for in-kernel flushers that may observe high concurrency (e.g. reclaim, refault). For userspace readers, stale stats may be unexpected and problematic, especially when such stats are used for critical paths such as userspace OOM handling. Additionally, a userspace reader will occasionally pay the cost of flushing the entire hierarchy, which also causes problems in some cases [1]. Opt userspace reads out of unified flushing. This makes the cost of reading the stats more predictable (proportional to the size of the subtree), as well as the freshness of the stats. Since userspace readers are not expected to have similar concurrency to in-kernel flushers, serializing them among themselves and among in-kernel flushers should be okay. Note that this may make the worst case latency for reading stats worse. Flushers may give up cgroup_rstat_lock and sleep, causing the number of waiters for the spinlock theoritically unbounded. A reader may grab the lock and do some work, give it up, sleep, and then wait for a long time before acquiring it again and continuing. This is only possible if there is high concurrency among processes reading stats of different parts of the hierarchy, such that they are not helping each other out. Other stats interfaces such as cpu.stat have the same theoritical problem, so this is unlikely to be a problem in practice. If it is, we can introduce a mutex in the stats reading path to guard against concurrent readers competing for the lock. We have similar protection for unified flushing, except that concurrent flushers skip instead of waiting. An alternative is to remove flushing from the stats reading path completely, and rely on the periodic flusher. This should be accompanied by making the periodic flushing period tunable, and providing an interface for userspace to force a flush, following a similar model to /proc/vmstat. However, such a change will be hard to reverse if the implementation needs to be changed because: - The cost of reading stats will be very cheap and we won't be able to take that back easily. - There are user-visible interfaces involved. Hence, let's go with the change that's most reversible first. If problems arise, we can add a mutex in the stats reading path as described above, or follow the more user-visible approach. This was tested on a machine with 256 cpus by running a synthetic test The script that creates 50 top-level cgroups, each with 5 children (250 leaf cgroups). Each leaf cgroup has 10 processes running that allocate memory beyond the cgroup limit, invoking reclaim (which is an in-kernel unified flusher). Concurrently, one thread is spawned per-cgroup to read the stats every second (including root, top-level, and leaf cgroups -- so total 251 threads). No regressions were observed in the total running time; which means that non-unified userspace readers are not slowing down in-kernel unified flushers: Base (mm-unstable): real 0m18.228s user 0m9.463s sys 60m15.879s real 0m20.828s user 0m8.535s sys 70m12.364s real 0m19.789s user 0m9.177s sys 66m10.798s With this patch: real 0m19.632s user 0m8.608s sys 64m23.483s real 0m18.463s user 0m7.465s sys 60m34.089s real 0m20.309s user 0m7.754s sys 68m2.392s Additionally, the average latency for reading stats went down up to 8 times when reading stats of leaf cgroups in the script, as we only have to flush the cgroup(s) being read. [1]https://lore.kernel.org/lkml/CABWYdi0c6__rh-K7dcM_pkf9BJdTRtAU08M43KO9ME= 4-dsgfoQ@mail.gmail.com/ Signed-off-by: Yosry Ahmed --- mm/memcontrol.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index f3716478bf4e..8bfb0e3395ce 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1607,7 +1607,7 @@ static void memcg_stat_format(struct mem_cgroup *memc= g, struct seq_buf *s) * * Current memory state: */ - mem_cgroup_try_flush_stats(); + do_stats_flush(memcg); =20 for (i =3D 0; i < ARRAY_SIZE(memory_stats); i++) { u64 size; @@ -4049,7 +4049,7 @@ static int memcg_numa_stat_show(struct seq_file *m, v= oid *v) int nid; struct mem_cgroup *memcg =3D mem_cgroup_from_seq(m); =20 - mem_cgroup_try_flush_stats(); + do_stats_flush(memcg); =20 for (stat =3D stats; stat < stats + ARRAY_SIZE(stats); stat++) { seq_printf(m, "%s=3D%lu", stat->name, @@ -4124,7 +4124,7 @@ static void memcg1_stat_format(struct mem_cgroup *mem= cg, struct seq_buf *s) =20 BUILD_BUG_ON(ARRAY_SIZE(memcg1_stat_names) !=3D ARRAY_SIZE(memcg1_stats)); =20 - mem_cgroup_try_flush_stats(); + do_stats_flush(memcg); =20 for (i =3D 0; i < ARRAY_SIZE(memcg1_stats); i++) { unsigned long nr; @@ -4626,7 +4626,7 @@ void mem_cgroup_wb_stats(struct bdi_writeback *wb, un= signed long *pfilepages, struct mem_cgroup *memcg =3D mem_cgroup_from_css(wb->memcg_css); struct mem_cgroup *parent; =20 - mem_cgroup_try_flush_stats(); + do_stats_flush(memcg); =20 *pdirty =3D memcg_page_state(memcg, NR_FILE_DIRTY); *pwriteback =3D memcg_page_state(memcg, NR_WRITEBACK); @@ -6641,7 +6641,7 @@ static int memory_numa_stat_show(struct seq_file *m, = void *v) int i; struct mem_cgroup *memcg =3D mem_cgroup_from_seq(m); =20 - mem_cgroup_try_flush_stats(); + do_stats_flush(memcg); =20 for (i =3D 0; i < ARRAY_SIZE(memory_stats); i++) { int nid; --=20 2.42.0.rc2.253.gd59a3bf2b4-goog