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

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

On Thu, 15 Oct 2026 13:42:41 +0200 Konstantin Khorenko <khorenko@virtuozzo.com> wrote:

> On 10/14/26 22:50, Andrew Morton wrote:
> > On Wed, 14 Oct 2026 16:54:36 +0200 Konstantin Khorenko <khorenko@virtuozzo.com> wrote:
> > 
> >> Every memory cgroup allocates, per NUMA node, one shrinker_info_unit
> >> per 64 memcg-aware shrinker ids up to shrinker_nr_max, whether or not it
> >> ever charges an object to those shrinkers. Every superblock registers
> >> such a shrinker, so the cost is
> >>
> >>   memory cgroups x NUMA nodes x shrinker_nr_max / 64 x 1 KiB
> >>
> >> because the unit is 520 bytes and comes from kmalloc-1k.
> > 
> > So we could almost halve this just by using a dedicated kmem_cache?
> 
> Yeap, a dedicated cache gets approximately the same cost per shrinker id.
> On a 48-CPU box SLUB puts 31 units in an order-2 slab, about 528 bytes each:
> 
>                                       ids/unit  bytes/unit  bytes/id
>     today, kmalloc-1k                    64        1024        16
>     patch 1, kmalloc-512                 63         512       ~8.1
>     dedicated cache                      64        ~528       ~8.3
>     dedicated cache, HWCACHE_ALIGN       64         576        9
> 
> So the two are ~equal on memory, and the choice is about the code.
> 
> I went with 63 ids per unit because the unit then simply fills the
> kmalloc slot it already comes from.
> 
> The price is an odd SHRINKER_UNIT_BITS and roundup() instead of round_up(),
> plus the static_assert.
> 
> 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.

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%?