Re: [PATCH] fs/super: skip non-memcg-aware nr_cached_objects in memcg slab shrink

[Shakeel Butt <shakeel.butt@linux.dev>]

On Tue, Jun 09, 2026 at 05:30:47AM -0700, Usama Arif wrote:
> The super_block shrinker is registered with SHRINKER_MEMCG_AWARE because its
> dentry and inode LRUs are memcg-aware (via list_lru). But the optional
> ->nr_cached_objects() hooks that the shrinker also drives are not memcg-aware:
> btrfs extent maps and xfs inode reclaim operate on filesystem-global
> state, and shmem's unused-huge shrinker walks a per-superblock shrinklist.
> None of them filter by sc->memcg.

I see the underlying objects whose count is returned by ->nr_cached_objects()
hook is memcg charged for shmem and xfs but not for btrfs. Do you envision
there might be a rare scenario where we have a lot of memory charged to a memcg
consumed by objects which ->nr_cached_objects() tracks and that memory becomes
unreclaimable due to this patch?

> 
> The mismatch shows up under memcg-heavy slab reclaim. shrink_slab_memcg()
> calls do_shrink_slab() once per (memcg, NUMA node) pair for every memcg
> whose bit is set in the per-superblock shrinker bitmap, which on a busy
> host means hundreds of calls per reclaim pass. Each scan queues the same
> global shrinker work item that's already kicked from the root path.
> 
> Because btrfs/xfs global count is typically non-zero on any in-use filesystem,
> the returned total stays positive even if a memcg's own dentry/inode LRUs
> are empty. shrink_slab_memcg() therefore never clears the SB shrinker bit
> in the memcg bitmap, so subsequent reclaim passes from the same memcg
> re-enter super_cache_count() and pay for the global counter walk again.

What is the main concern? Is it the amount of CPU wasted or are we over
reclaiming or reclaiming from unrelated memcgs?

> 
> Restrict ->nr_cached_objects() to the global shrink path (sc->memcg NULL
> or root). The memcg-aware dentry/inode LRUs keep being counted and
> scanned per memcg as before; only the global fs-specific hooks are skipped.
> The root/global shrink path still drives those hooks; only their
> invocation from non-root memcg slab reclaim is removed.
> 
> Signed-off-by: Usama Arif <usama.arif@linux.dev>

I am fine with the stopgap but it would be nice to have proper memcg awareness
in xfs and shmem callbacks. For btrfs, I am not sure if it makes sense to memcg
charge btrfs_extent_map objects but at least to decision to skip memcg reclaim
will be inside the fs callbacks i.e. nr_cached_objects.