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

[Barry Song]

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.

[...]
> >> +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.

Best Regards
Barry