Re: [PATCH 3/8] mm/mglru: restructure the reclaim loop

[Baolin Wang]

On 3/18/26 3:08 AM, Kairui Song via B4 Relay wrote:
> From: Kairui Song <kasong@xxxxxxxxxxx>
>
> The current loop will calculate the scan number on each iteration. The
> number of folios to scan is based on the LRU length, with some unclear
> behaviors, eg, it only shifts the scan number by reclaim priority at the
> default priority, and it couples the number calculation with aging and
> rotation.
>
> Adjust, simplify it, and decouple aging and rotation. Just calculate the
> scan number for once at the beginning of the reclaim, always respect the
> reclaim priority, and make the aging and rotation more explicit.
>
> This slightly changes how offline memcg aging works: previously, offline
> memcg wouldn't be aged unless it didn't have any evictable folios. Now,
> we might age it if it has only 3 generations and the reclaim priority is
> less than DEF_PRIORITY, which should be fine. On one hand, offline memcg
> might still hold long-term folios, and in fact, a long-existing offline
> memcg must be pinned by some long-term folios like shmem. These folios
> might be used by other memcg, so aging them as ordinary memcg doesn't
> seem wrong. And besides, aging enables further reclaim of an offlined
> memcg, which will certainly happen if we keep shrinking it. And offline
> memcg might soon be no longer an issue once reparenting is all ready.
>
> Overall, the memcg LRU rotation, as described in mmzone.h,
> remains the same.
>
> Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>
> ---

Overall, I really like the code cleanup here, and it makes the code much 
more readable. Thanks for your work.

However, one concern is that you've mixed some functional changes (such 
as the offline memcg aging and shifting the scan number by reclaim 
priority) into these cleanups. This makes the commit difficult to 
review, though I think the functional changes make sense to me.

Can we split this up? That means you can send the cleanups as a separate 
patch first, followed by the functional changes in the following patches 
with an explanation of their impact. Then reviewers can focus on 
discussing the functional changes.