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

[Muchun Song <muchun.song@linux.dev>]

> On Oct 15, 2026, at 19:42, 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.

Please use a dedicated cache, more straightforward for me. But also give some time to maintainers for reviewing the patch 2 before your update.

Thanks.

> 
> --
> Best regards,
> Konstantin
>