linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Leon Huang Fu <leon.huangfu@shopee.com>
Cc: linux-mm@kvack.org, hannes@cmpxchg.org, roman.gushchin@linux.dev,
	shakeel.butt@linux.dev, muchun.song@linux.dev,
	akpm@linux-foundation.org, joel.granados@kernel.org,
	jack@suse.cz, laoar.shao@gmail.com, mclapinski@google.com,
	kyle.meyer@hpe.com, corbet@lwn.net, lance.yang@linux.dev,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org
Subject: Re: [PATCH mm-new] mm/memcontrol: Introduce sysctl vm.memcg_stats_flush_threshold
Date: Tue, 4 Nov 2025 10:21:35 +0100	[thread overview]
Message-ID: <aQnFn6vPQ5D6STGw@tiehlicka> (raw)
In-Reply-To: <20251104031908.77313-1-leon.huangfu@shopee.com>

On Tue 04-11-25 11:19:08, Leon Huang Fu wrote:
> The current implementation uses a flush threshold calculated as
> MEMCG_CHARGE_BATCH * num_online_cpus() for determining when to
> aggregate per-CPU memory cgroup statistics. On systems with high core
> counts, this threshold can become very large (e.g., 64 * 256 = 16,384
> on a 256-core system), leading to stale statistics when userspace reads
> memory.stat files.
> 
> This is particularly problematic for monitoring and management tools
> that rely on reasonably fresh statistics, as they may observe data that
> is thousands of updates out of date.
> 
> Introduce a new sysctl, vm.memcg_stats_flush_threshold, that allows
> administrators to override the flush threshold specifically for
> userspace reads of memory.stat. When set to 0 (default), the behavior
> remains unchanged, using the automatic calculation. When set to a
> non-zero value, userspace reads will use the custom threshold for more
> frequent flushing.

How are admins supposed to know how to tune this? Wouldn't it make more
sense to allow explicit flushing on write to the file? That would allow
admins to implement their preferred accuracy tuning by writing to the file
when the precision is required.

-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2025-11-04  9:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-04  3:19 Leon Huang Fu
2025-11-04  9:21 ` Michal Hocko [this message]
2025-11-05  6:01   ` Leon Huang Fu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aQnFn6vPQ5D6STGw@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=hannes@cmpxchg.org \
    --cc=jack@suse.cz \
    --cc=joel.granados@kernel.org \
    --cc=kyle.meyer@hpe.com \
    --cc=lance.yang@linux.dev \
    --cc=laoar.shao@gmail.com \
    --cc=leon.huangfu@shopee.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mclapinski@google.com \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox