Re: [PATCH 1/2] mm: vmscan: Split proactive reclaim statistics from direct reclaim statistics

[Johannes Weiner <hannes@cmpxchg.org>]

Hey Michal,

On Wed, Mar 19, 2025 at 11:33:10AM +0100, Michal Koutný wrote:
> On Wed, Mar 19, 2025 at 05:49:15PM +0800, Hao Jia <jiahao1@lixiang.com> wrote:
> > 	root
> >   	`- a `- b`- c
> > 
> > We have a userspace proactive memory reclaim process that writes to 
> > a/memory.reclaim, observes a/memory.stat, then writes to 
> > b/memory.reclaim and observes b/memory.stat. This pattern is the same 
> > for other cgroups as well, so all memory cgroups(a, b, c) have the 
> > **same writer**. So, I need per-cgroup proactive memory reclaim statistics.
> 
> Sorry for unclarity, it got lost among the mails. Originally, I thought
> about each write(2) but in reality it'd be per each FD. Similar to how
> memory.peak allows seeing different values. WDYT?

Can you clarify if you're proposing this as an addition or instead of
the memory.stat items?

The memory.stat items are quite useful to understand what happened to
a cgroup in the past. In Meta prod, memory.stat is recorded over time,
and it's go-to information when the kernel team gets looped into an
investigation around unexpected workload behavior at some date/time X.

The proactive reclaimer data points provide a nice bit of nuance to
this. They can easily be aggregated over many machines etc.

A usecase for per-fd stats would be interesting to hear about, but I
don't think they would be a suitable replacement for memory.stat data.