[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <hvdw5o6trz5q533lgvqlyjgaskxfc7thc7oicdomovww4pn6fz@esy4zzuvkhf6>
Date: Wed, 19 Mar 2025 10:15:18 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Hao Jia <jiahao.kernel@...il.com>
Cc: hannes@...xchg.org, akpm@...ux-foundation.org, tj@...nel.org,
corbet@....net, mhocko@...nel.org, roman.gushchin@...ux.dev,
shakeel.butt@...ux.dev, muchun.song@...ux.dev, cgroups@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
Hao Jia <jiahao1@...iang.com>
Subject: Re: [PATCH 1/2] mm: vmscan: Split proactive reclaim statistics from
direct reclaim statistics
On Wed, Mar 19, 2025 at 10:38:01AM +0800, Hao Jia <jiahao.kernel@...il.com> wrote:
> However, binding the statistics to the memory.reclaim writers may not be
> suitable for our scenario. The userspace proactive memory reclaimer triggers
> proactive memory reclaim on different memory cgroups, and all memory reclaim
> statistics would be tied to this userspace proactive memory reclaim process.
It thought that was what you wanted -- have stats related precisely to
the process so that you can feedback-control the reclaim.
> This does not distinguish the proactive memory reclaim status of different
> cgroups.
a
`- b
`- c
Or do you mean that you write to a/memory.reclaim and want to observe
respective results in {b,c}/memory.stat?
(I think your addition to memory.stat is also natural. If the case above
is the explanation why to prefer it over per-writer feedback, please
mention that in next-rev commit message.)
Thanks,
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists