Re: [PATCH -next] mm: introduce per-node proactive reclaim interface

[Michal Hocko <mhocko@suse.com>]

On Mon 09-09-24 18:51:57, Hillf Danton wrote:
> On Date: Mon, 9 Sep 2024 09:12:03 +0200 Michal Hocko <mhocko@suse.com>
> > On Fri 06-09-24 19:04:19, Hillf Danton wrote:
> > > On Thu, 5 Sep 2024 16:29:41 -0700 Davidlohr Bueso <dave@stgolabs.net>
> > > > On Fri, 06 Sep 2024, Hillf Danton wrote:\n
> > > > >The proactive reclaim on the cmdline looks like waste of cpu cycles before
> > > > >the cases where kswapd fails to work are spotted. It is not correct to add
> > > > >it because you can type the code.
> > > > 
> > > > Are you against proactive reclaim altogether (ie: memcg) or this patch in
> > > > particular, which extends its availability?
> > > > 
> > > The against makes no sense to me because I know your patch is never able to
> > > escape standing ovation.
> > 
> > I fail to understand your reasoning. Do you have any actual technical
> > arguments why this is a bad idea?
> > 
> > > > The benefits of proactive reclaim are well documented, and the community has
> > > > been overall favorable towards it. This operation is not meant to be generally
> > > > used, but there are real latency benefits to be had which are completely
> > > > unrelated to watermarks. Similarly, we have 'compact' as an alternative to
> > > > kcompactd (which was once upon a time part of kswapd).
> > > >
> > > Because kswapd is responsible for watermark instead of high order pages,
> > > compact does not justify proactive reclaim from the begining.
> > 
> > What do you mean? How does keeping a global watermark helps to trigger
> > per NUMA node specific aging - e.g. demotion?
> >
> In addition to the cost of pro/demorion, the percpu pages prevent random aging
> from making any sense without memory pressue, because I think it is aging that
> rolls out red carpet for multi-gen lru.

I am sorry but I do not get what you are trying to say. Can you be
_much_more_ specific?
-- 
Michal Hocko
SUSE Labs