Re: [PATCH v7 03/15] mm/mglru: relocate the LRU scan batch limit to callers

[Kairui Song]

On Fri, May 29, 2026 at 1:40 PM Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote:
>
> On Tue, Apr 28, 2026 at 02:06:54AM +0800, Kairui Song via B4 Relay wrote:
> > From: Kairui Song <kasong@xxxxxxxxxxx>
> >
> > Same as active / inactive LRU, MGLRU isolates and scans folios in batches.
> > The batch split is done hidden deep in the helper, which makes the code
> > harder to follow.  The helper's arguments are also confusing since callers
> > usually request more folios than the batch size, so the helper almost
> > never processes the full requested amount.
> >
> > Move the batch splitting into the top loop to make it cleaner, there
> > should be no behavior change.
> >
> > Reviewed-by: Axel Rasmussen <axelrasmussen@xxxxxxxxxx>
> > Reviewed-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
> > Reviewed-by: Barry Song <baohua@xxxxxxxxxx>
> > Reviewed-by: Chen Ridong <chenridong@xxxxxxxxxxxxxxx>
> > Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>
> > ---
> >  mm/vmscan.c | 16 +++++++++-------
> >  1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 7f011ff4c478..a011733a6392 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -4695,10 +4695,10 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
> >       int scanned = 0;
> >       int isolated = 0;
> >       int skipped = 0;
> > -     int scan_batch = min(nr_to_scan, MAX_LRU_BATCH);
> > -     int remaining = scan_batch;
> > +     unsigned long remaining = nr_to_scan;
> >       struct lru_gen_folio *lrugen = &lruvec->lrugen;
> >
> > +     VM_WARN_ON_ONCE(nr_to_scan > MAX_LRU_BATCH);
>
> Do we really need a warning here? Also why are we limiting it to MAX_LRU_BATCH?
> For memcg/proactive reclaim, we can get larger number. What will break if we
> remove this limitation?

Hi,
Isolating a large chunk of folios off the list is usually a bad idea,
livelock is one concern, besides, concurrent reclaimer won't see them
anymore, and LRU operations on them will be skipped (eg. roration).
Under heavy pressure, this could lead to premature OOM because some
reclaimers will see the LRU as empty. or accuracy loss.

There is a LRU isolate throttle for CLRU, which is missing for MGLRU,
so just being careful here, can be removed anytime, but I won't think
isolating more than MAX_LRU_BATCH for a single time will ever be a
good idea.

>
> Anyways, these questions are orthogonal to the patch, so:
>
> Acked-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>

Thanks!