Re: [PATCH v7 04/15] mm/mglru: restructure the reclaim loop

[Shakeel Butt]

On Tue, Apr 28, 2026 at 02:06:55AM +0800, 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, e.g, the scan number is only shifted by reclaim priority when
> aging is not needed or when 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 aging and offline memcg reclaim works:
> Previously, aging was skipped at DEF_PRIORITY even when eviction was no
> longer possible, so the reclaimer wasted an iteration until the priority
> escalated.  Now aging runs immediately whenever it is needed to make
> progress; the DEF_PRIORITY skip only applies when eviction is still
> viable.  This may avoid wasted iterations that over-reclaim slab and break
> reclaim balance in multi-cgroup setups.
> 
> Similar for offline memcg.  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, 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 seems
> correct.  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 with reparenting.

After the lru folios reparenting, we should not be seeing folios remaining on
offlined memcg LRUs. So, the above para can be removed.

> 
> Overall, the memcg LRU rotation, as described in mmzone.h, remains the
> same.
> 
> Note that because the scan budget is now pinned at loop entry, tiny
> lruvec might skip this reclaim pass, also skipping aging, which could be
> beneficial as aging is not helpful since it will still be un-reclaimable
> after aging. Reclaim will go on as usual once priority escalates.
> 
> Reviewed-by: Axel Rasmussen <axelrasmussen@xxxxxxxxxx>
> Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>

Acked-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>