Re: [PATCH v2 0/2] mm/shrinker: make per-memcg shrinker units cheaper

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 16 Oct 2026 14:27:32 +0200 Konstantin Khorenko <khorenko@virtuozzo.com> wrote:

> On 10/16/26 02:58, Andrew Morton wrote:
> > On Thu, 15 Oct 2026 13:42:41 +0200 Konstantin Khorenko <khorenko@virtuozzo.com> wrote:
> ...
> >> If you prefer the cache, I'm happy to redo patch 1 that way.
> >> Patch 2 does not care about the unit size.
> > 
> > OK, thanks.  Yes, using a kmem_cache is a simple no-brainer.  Let's get
> > that done first and then let's look at additional optimizations on top
> > as a separate activity.
> 
> OK, no problem. I'll redo patch 1 with a dedicated kmem_cache and send
> it separately.

Great.

> 
> > But a tweak which reduces 145GB of bloat to half of that is lipsticking
> > the pig, and what a pig it is.
> > 
> > Why the heck is memcg allocating so many of these things?  What sort of
> > rip-out/rethink/start-over can we do to reduce this by 99.x%?
> 
> That is what patch 2 does:
>   [PATCH v2 2/2] mm/shrinker: allocate the per-memcg shrinker units on demand
> 
> Today every memcg allocates, on every node, a unit for every 63 shrinker
> ids up to shrinker_nr_max, whether or not it ever has an object on those
> shrinkers. Patch 2 allocates a unit only when the memcg gets a list on that
> shrinker's list_lru, so a memcg pays for the shrinkers it uses, not for
> every superblock on the host.
> 
> In the synthetic test from the cover letter (8000 tmpfs mounts,
> shrinker_nr_max 8064, 2000 empty memcgs, 4 nodes):
> 
>                      units               slab per memcg
>   base               1011518 x 1024 B    548 KB
>   + patch 1          1023787 x  512 B    289 KB
>   + patches 1-2          136 x  512 B     42 KB

OK.

> Size: it would replace patch 2 with two patches. The first turns the
> array into an xarray, with the units still allocated up front, and
> removes struct shrinker_info and the expand path. The second allocates
> the units on demand, without the lock and the expand handling patch 2
> needs now. Together I expect about the size of patch 2 today, around
> 170 changed lines, mostly in mm/shrinker.c, with fewer lines in total
> than now.

That sounds like a good plan.

> Which way would you prefer: patch 2 as it is, or the xarray version in
> its place? Or something else?

The xarray approach sounds more complex?  If so I'd say only do that if
it's justified for some reason.