Re: [RFC] mm/vmscan: add periodic slab shrinker

[Roman Gushchin <roman.gushchin@linux.dev>]

On Mon, Apr 04, 2022 at 01:14:42PM +0800, Hillf Danton wrote:
> On Mon, 4 Apr 2022 11:09:48 +1000 Dave Chinner wrote:
> > On Sun, Apr 03, 2022 at 08:56:18AM +0800, Hillf Danton wrote:
> > > On Sat, 2 Apr 2022 10:54:36 -0700 Roman Gushchin wrote:
> > > > Hello Hillf!
> > > > 
> > > Hello Roman,
> > > 
> > > > Thank you for sharing it, really interesting! I=E2=80=99m actually working o=
> > > > n the same problem.=20
> > > 
> > > Good to know you have some interest in it.
> > > Feel free to let me know you would like to take it over to avoid
> > > repeated works on both sides.

Only if you've something more exciting to work on. It seems like at this
point it's not really clear what exactly we need to do and how to approach it,
so I don't think we're doing any repeated work. The more
ideas/opinions/suggestions, then better.

> > > 
> > > > 
> > > > No code to share yet, but here are some of my thoughts:
> > > > 1) If there is a =E2=80=9Cnatural=E2=80=9D memory pressure, no additional sl=
> > > > ab scanning is needed.
> > > 
> > > Agree - the periodic shrinker can be canceled once kswapd wakes up.
> > 
> > I think we should be waking up per-node kswapd to do the periodic
> > shrinking, not adding yet another way of executing (thousands of)
> > shrinkers (across hundreds of nodes) from a single threaded context.
> 
> Kswapd is majorly responsible for keeping the high water mark, a
> different target from cold slab objects - I am inclined to staying a
> safe distance from any code churn in that area.

The problem is that kswapd is also doing slab shrinking and we can't
simple ignore it, so it has to interact in some way.

Thanks!