Re: [PATCH v2 2/2] mm/mglru: fix ineffective memory protection for non-kswapd reclaim
From: Ridong Chen
Date: Sun Aug 30 2026 - 06:57:34 EST
On 8/30/2026 6:40 PM, Barry Song wrote:
On Sun, Aug 30, 2026 at 6:13 PM Ridong Chen <ridong.chen@xxxxxxxxx> wrote:
On 8/30/2026 3:53 PM, Barry Song wrote:
On Fri, Aug 28, 2026 at 7:10 PM Ridong Chen <ridong.chen@xxxxxxxxx> wrote:
From: Ridong Chen <chenridong@xxxxxxxxxx>
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.
[...]
I'd suggest keeping it as is. This function updates protection along the path+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?
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