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

[Kairui Song <ryncsn@gmail.com>]

On Thu, Mar 26, 2026 at 03:31:43PM +0800, Baolin Wang wrote:
> 
> 
> On 3/18/26 3:08 AM, Kairui Song via B4 Relay wrote:
> > From: Kairui Song <kasong@tencent.com>
> > 
> > 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@tencent.com>
> > ---
> 
> Overall, I really like the code cleanup here, and it makes the code much
> more readable. Thanks for your work.

Thanks for the review!

> 
> 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.

Right, so I also include very detailed test in the cover letter
for each step. This part of code is kind of coupled together
so by decoupling them, it may get more messy if we try to keep some
of the trivial old behavior.

But will have a try on V2. Already doing some stress testing but
splitting the patch shouldn't effect the final code.