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

From: Usama Arif

Date: Tue Jul 14 2026 - 06:22:09 EST


On Tue, 14 Jul 2026 10:09:26 +0800 Qi Zheng <qi.zheng@xxxxxxxxx> wrote:

> 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 Qi, I have sent a patch to push it down to filesystems in [1].
No functional change inteneded in there. You would have to rebase your
patch on top of that one and remove my code in shmem specifically.

[1] https://lore.kernel.org/all/20260714101454.1202449-1-usama.arif@xxxxxxxxx/

>
> >
> > Thanks,
> > Usama
>
>