Re: [PATCH] mm/mglru: fix memcg protection for global proactive reclaim

[Ridong Chen <ridong.chen@linux.dev>]

On 7/24/2026 7:58 AM, Andrew Morton wrote:
> On Thu, 23 Jul 2026 21:05:59 +0800 Ridong <ridong.chen@linux.dev> wrote:
> 
>> memory.min/low is silently bypassed for MGLRU during global proactive
>> reclaim (writing to the root memory.reclaim). It can be reproduced as
>> follows:
>>
>> ...
>>
>> Factor the tree traversal out into update_memcg_protection() and call
>> it from lru_gen_shrink_node() for the non-kswapd path, so the protection
>> is computed before shrinking. kswapd keeps computing it in
>> lru_gen_age_node(), which also needs it for the min_ttl OOM check.
>>
>> Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists")
> 
> Do we want cc:stable on this fix?
> 
> Sashiko said a couple of things - the memcg ref leak looks real:
> 	https://sashiko.dev/#/patchset/20260723130559.2343690-1-ridong.chen@linux.dev
> 

Sashiko said:

   When breaking out of the loop early here, do we need to call
   mem_cgroup_iter_break(NULL, memcg) to release the reference?
   Since mem_cgroup_iter() holds a reference to the active cgroup css, exiting
   without dropping it could cause memory cgroups to leak and accumulate over
   time, eventually leading to kernel memory exhaustion.
   [ ... ]

This is a bug introduced by this patch, and we will fix it.

Regarding the performance regression:

   Placing update_memcg_protection() inside the lru_gen_shrink_node()
   non-kswapd path forces every direct reclaimer into an unbounded full
   cgroup tree walk.
   Will this cause severe performance regressions during global memory pressure?
   All allocating tasks entering global direct reclaim would concurrently
   traverse the entire memcg tree. This could lead to massive css->refcnt
   cacheline bouncing and system latency spikes, scaling negatively with
   the number of memory cgroups.
   Could this full tree walk be optimized or deferred so direct reclaimers avoid
   iterating every single cgroup?

Since MGLRU global reclaim does not iterate over memcgs in the same way 
traditional LRU does (which traverses the hierarchy from top to bottom), it 
appears we are currently required to walk the full tree, similar to what kswapd 
reclaim does.

Does anyone have a better approach in mind?

-- 
Best regards
Ridong