Re: [PATCH v2 2/2] mm/mglru: fix ineffective memory protection for non-kswapd reclaim

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

On 8/30/2026 6:40 PM, Barry Song wrote:
> On Sun, Aug 30, 2026 at 6:13 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>>
>>
>>
>> On 8/30/2026 3:53 PM, Barry Song wrote:
>>> On Fri, Aug 28, 2026 at 7:10 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>>>>
>>>> From: Ridong Chen <chenridong@xiaomi.com>
>>>>
>>>> memory.min/low is silently bypassed for MGLRU during global proactive
>>>> reclaim (writing to the root memory.reclaim) and global direct reclaim.
>>>
>>> I guess nobody is silently bypassing anything. It's just that the
>>> effective min is stale data. If kswapd has run at least once, should
>>> the protection have been updated already?
>>> I guess we need to update the changelog a bit?
>>>
>>
>> The children's emin/elow are derived from the parent's min/low settings and
>> children_min_usage, both of which can change over time. As a result, emin/elow
>> may become stale, even if kswapd has already run once.
> 
> right, let's just say this in changelog, we are *not* bypassing we are
> just checking
> against stable data. The current changelog seems to be misleading.
> 

Thanks, Will update.

> [...]
>>>> +void mem_cgroup_protection_path(struct mem_cgroup *root,
>>>> +                               struct mem_cgroup *memcg)
>>>
>>> Can we rename it to `mem_cgroup_calculate_protection_path()`?
>>>
>>> BTW, I see that the only caller is in vmscan and it passes NULL as
>>> `root`. Do we need to keep the `root` argument if the new helper is
>>> only used for global reclaim?
>>>
>> I'd suggest keeping it as is. This function updates protection along the path
>> from root to memcg, and could be reused later. Note that
>> mem_cgroup_calculate_protection() assumes the caller has already performed the
>> top-down walk, each level's calculation depends on its parent being updated first.
>>
>> For mem_cgroup_calculate_protection_path(), it can be called in any context
>> without such a precondition.
> 
> I am fine with this -  keeping the root there. but I guess rename is worth it.
> 

Yeah, I will rename in the next version.

-- 
Best regards
Ridong