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

[Qi Zheng]

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@xxxxxxxxxxxxx>
>
> 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@xxxxxxxxx/

Thanks,
Qi


>