Re: [PATCH v2 7/7] mm/mglru: batch move folios to the second-oldest gen's LRU

[Barry Song]

On Fri, Aug 28, 2026 at 7:47 AM Barry Song (Xiaomi) <baohua@xxxxxxxxxx> wrote:
>
> Detect folios that need to move from the oldest generation to
> the second-oldest generation, and batch-move them together.
> This can significantly reduce the sys time of inc_min_seq(),
> especially when the other type is significantly behind the
> preferred type.
>
> Assisted-by: gemini:gemini-3.6-flash
> Signed-off-by: Barry Song (Xiaomi) <baohua@xxxxxxxxxx>
> Reviewed-by: Baoquan He <baoquan.he@xxxxxxxxx>
> Tested-by: Xueyuan Chen <xueyuan.chen21@xxxxxxxxx>
> ---
>  mm/vmscan.c | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 17524e96fe64..2b6f3f05ce60 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3931,6 +3931,19 @@ static void clear_mm_walk(void)
>                 kfree(walk);
>  }
>
[...]

>                 while (pos != head) {
> @@ -3974,7 +3989,7 @@ static bool inc_min_seq(struct lruvec *lruvec, int type, int swappiness)
>                         new_gen = __folio_inc_gen(folio, old_gen, &gen_increased);
>                         if (gen_increased) {
>                                 delta += nr_pages;
> -                               list_move_tail(&folio->lru, &lrugen->folios[new_gen][type][zone]);
> +                               batch_end = &folio->lru;
>
>                                 /* don't count the workingset being lazily promoted */
>                                 if (refs + workingset != BIT(LRU_REFS_WIDTH) + 1) {
> @@ -3984,11 +3999,14 @@ static bool inc_min_seq(struct lruvec *lruvec, int type, int swappiness)
>                                                    lrugen->protected[hist][type][tier] + nr_pages);
>                                 }
>                         } else {
> +                               flush_lru_batch(head, &batch_end, target_list);
>                                 list_move(&folio->lru, &lrugen->folios[new_gen][type][zone]);

Sashiko says

"Does this change from list_move_tail() to list_move() unintentionally
reverse the relative LRU ordering of lazily promoted folios?
In the baseline code, list_move_tail() was used for all folios, preserving
their relative order when moving them to the new generation's list.
Because the loop in inc_min_seq() processes folios sequentially from head
to tail, inserting them one by one at the head of the new list using
list_move() will reverse their relative order (for example, folios A, B,
and C will end up as C, B, A in the new list).
Could this subtly distort eviction fairness and page replacement optimality
during MGLRU reclaim under memory pressure?"


I feel this comment is not particularly useful. We are focusing on
resolving two specific issues:

1. Make sure promoted folios are always placed ahead of non-promoted
   folios. Right now, mainline can place promoted folios after
   non-promoted folios.

2. Preserve the existing order of non-promoted folios instead of
   reversing them, as mainline currently does.

Sashiko seems to be concerned about the ordering among promoted folios.
I don't think that ordering is particularly meaningful, because we don't
know which folio was actually accessed more recently. Accessed bits are
accumulated over time and handled together. The only way to establish a
meaningful order among promoted folios would be to make every access
trigger a page fault, which is obviously not feasible.

Best Regards
Barry