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

[Qi Zheng <qi.zheng@linux.dev>]

On 7/14/26 6:17 PM, Usama Arif wrote:
> On Tue, 14 Jul 2026 10:09:26 +0800 Qi Zheng <qi.zheng@linux.dev> 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@linux.dev/
>>> 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.

Thanks! I will rebase my patch once your patch is merged into
linux-next.

> 
> [1] https://lore.kernel.org/all/20260714101454.1202449-1-usama.arif@linux.dev/
> 
>>
>>>
>>> Thanks,
>>> Usama
>>
>>