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

[Qi Zheng]

Hi Usama,

On 7/13/26 11:34 PM, Usama Arif wrote:
> On 13/07/2026 14:12, Qi Zheng wrote:
> > Hi Usama,
> >
> > On 6/9/26 8:30 PM, 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.
> >
> > This makes sense for now, but how should we handle this if these
> > shrinkers are made memcg-aware in the future?
> >
> > I've recently been working on making the shmem huge shrinker
> > memcg-aware, but noticed my changes broke after rebasing onto the latest
> > tree, which led me to this patch.
> >
> > As for the shmem huge shrinker, I can work around this limitation by
> > making it a separate shrinker. But this feels more like an overall
> > design decision, effectively meaning that all nr_cached_objects are
> > precluded from being memcg-aware.
> >
> > Thanks,
> > Qi
>
>
> Hi Qi,
>
> Thanks for raising this. I think the alternative is what I mentioned in
> https://lore.kernel.org/all/cfdb8620-ea55-4226-98bf-d006820e6270@xxxxxxxxx/
> move this down to the fs own callbacks instead of here. Would that
> be better?

Yes, I think this is a better approach.

Later on, shrinkers that are converted to be memcg-aware can lift this 
restriction themselves.

Thanks,
Qi

> Thanks,
> Usama