Re: [PATCH 2/8] mm/mglru: relocate the LRU scan batch limit to callers

[Kairui Song <ryncsn@gmail.com>]

On Thu, Mar 19, 2026 at 10:00 AM Chen Ridong <chenridong@huaweicloud.com> wrote:
> On 2026/3/18 3:08, Kairui Song via B4 Relay wrote:
> > From: Kairui Song <kasong@tencent.com>
> >
> > 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.
> >
> > Signed-off-by: Kairui Song <kasong@tencent.com>
>
> I prefer to keep it as is.
>
> If we move min(nr_to_scan, MAX_LRU_BATCH) out of scan_folios, callers
> (potentially many functions in the future) would need to handle this logic
> themselves, which seems unnecessary. The scan_folios helper should remain cohesive.
>

Hi Ridong,

This patch is mostly for later use, and there are currently only two
callers. One from the default reclaim loop, one from the manual
reclaim interface (not memory.reclaim, I mean the MGLRU's command
interface).

In the default reclaim loop, later we want to control the exact number
of folios being scanned for each iteration, or at least use a smaller
batch value. For the manual reclaim interface using a large batch
seems more reasonable.

So this patch is needed I think. I can merge it into a later patch but
keeping it seperate seems more clean.