Re: [PATCH 0/2] mm/shrinker: per-memcg shrinker units in an xarray, allocated on demand

[Harry Yoo <harry@kernel.org>]

On Mon, Oct 19, 2026 at 07:39:22PM +0200, Konstantin Khorenko 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, plus a pointer array
> sized for shrinker_nr_max. Every superblock registers such a shrinker,
> and shrinker_nr_max never comes down, so a host that mounts many
> filesystems and runs many cgroups pays for every superblock in every
> cgroup, live or dying, and keeps paying for new cgroups after the
> mounts are gone.
> 
> This replaces patch 2/2 of v2, "mm/shrinker: allocate the per-memcg
> shrinker units on demand", with the xarray variant discussed in that
> thread. It applies on top of "mm/shrinker: allocate shrinker_info_unit
> from a dedicated kmem_cache", patch 1/2 of v2 sent on its own as v3:
> https://patch.msgid.link/20261019-vstor-144715-shrinker_info_unit-kmem_cache-v3-1-0fb061e09bf4@virtuozzo.com
> 
> Patch 1 keeps the units in an xarray per memcg and node instead of the
> pointer array. A new unit is inserted where it belongs: nothing is
> reallocated, copied or published under RCU when shrinker_nr_max grows,
> and the readers find a unit with xa_load() or walk the present ones
> with xa_for_each(). The units are still allocated up front, so this
> patch changes no behaviour.
> 
> Patch 2 allocates a unit only when the cgroup gets a list on that
> shrinker's list_lru, which is where map bits are set: a cgroup pays for
> the shrinkers it holds objects of, not for every superblock on the
> host. The install is an xarray insert with the gfp of the list
> allocation; there is no array to race with, so no lock of its own.
> The root memcg keeps its units for the deferred work of global reclaim
> and is the only memcg a shrinker registration still visits.
> 
> Measured on a 4-CPU, single-node VM, 20000 tmpfs mounts (shrinker_nr_max
> 20096) and 2000 memory cgroups, on three kernels:
> 
>   base                 v7.3-rc7 with the kmem_cache patch: every cgroup
>                        has every unit, in a pointer array
>   xarray               base + this series: units on demand, in an xarray
>   old array on demand  base + patch 2/2 of v2, rebased: units on demand,
>                        in the pointer array
> 
>                                                      old array
>                                       base    xarray  on demand
>   slab per empty cgroup               185 KB  18 KB   22 KB
>   shrink_slab_memcg(), empty cgroup   1.6 us  0.2 us  1.6 us
>   same, cgroup with objects on 100 sb 1.9 us  0.9 us  1.7 us
>   mkdir/rmdir the cgroups, 4000 more
>   mounts with them alive              same within noise

I think 'old array on demand' is probably good enough, and replacing it
with xarray is not justifiable unless you have a realistic scenario that
would benefit from it?

-- 
Cheers,
Harry / Hyeonggon