Re: [PATCH v2 0/2] mm/shrinker: make per-memcg shrinker units cheaper
From: Andrew Morton
Date: Thu Oct 15 2026 - 21:04:02 EST
On Thu, 15 Oct 2026 13:42:41 +0200 Konstantin Khorenko <khorenko@xxxxxxxxxxxxx> wrote:
> On 10/14/26 22:50, Andrew Morton wrote:
> > On Wed, 14 Oct 2026 16:54:36 +0200 Konstantin Khorenko <khorenko@xxxxxxxxxxxxx> 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%?