Re: [PATCH v3 0/3] make unused huge shrinker memcg aware

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

Hi David,

On 8/3/26 8:21 PM, David Hildenbrand (Arm) wrote:
> On 8/3/26 10:46, Qi Zheng wrote:
>> From: Qi Zheng <zhengqi.arch@bytedance.com>
> 
> I'm missing description and motivation here.

My bad, since v1 was just a single patch, I got lazy and didn't bother
adding a cover letter description later on.

> 
> This is only about shrinking huge pages that span end of shmem files.
> 
> Is this really a problem? And if so, why?

Yes, this is a real-world problem that we encountered in production.

The root cause is that shmem unused shrinker used to be non-memcg-aware.
This could lead to a scenario where reclaim triggered by one memcg A
reclaims the shmem of another memcg B, causing unexpected impact on it.

Even worse, memcg A might have no reclaimable shmem at all, making this
completely useless work and incurring some performance overhead.

such as:

tid 11340 comm scanner locked a page for 182264 us! kstack:
         unlock_page+1
         split_huge_page_to_list+3135
         shmem_unused_huge_shrink+767
         super_cache_scan+329
         do_shrink_slab+291
         shrink_slab+533
         shrink_node+400
         do_try_to_free_pages+206
         try_to_free_mem_cgroup_pages+262
         try_charge_memcg+591
         mem_cgroup_charge+136
         __handle_mm_fault+2431
         handle_mm_fault+194
         do_user_addr_fault+462
         __do_page_fault+176
         do_page_fault+48
         page_fault+62

Later, with Usama's patch [1], the shmem unused shrinker is no longer
triggered during memcg-level reclaim. But this actually doesn't make
sense either, since we can clearly just reclaim from memcg A individuallty.

[1]. 
https://lore.kernel.org/all/20260715103516.2410175-1-usama.arif@linux.dev/

Thanks,
Qi


>