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

["Michal Koutný" <mkoutny@suse.com>]

On Wed, Mar 19, 2025 at 11:44:28AM -0400, Johannes Weiner <hannes@cmpxchg.org> wrote:
> Can you clarify if you're proposing this as an addition or instead of
> the memory.stat items?

1) more precise info for given reclaim daemon
2) slight saving in the long list of memory stats (sorry, I must
   question new entries :-) to balance flushing[*])

I was originally motivated by 2) to propose the alternative but it is
not strong alone if 1) is unnecessary at the moment (and it seems the
blurring via aggregation is acceptable for the users), so let's consider
that idea a (potential) addition.

Michal

[*] You'd be right to argue that per-writer collection may not be more
    efficient in implementation.



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

That could be collected from memory.reclaim too.

> 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.

There could be reclaim daemons running at different levels of hierarchy,
the higher one would see effects of its operations only. Or differently
parametrized reclaimers (swappiness), each interested in their own
impact.