Re: [PATCH 1/6] mm/mglru: batch update lrugen->nr_pages in inc_min_seq()

[Kairui Song]

On Fri, Aug 21, 2026 at 7:09 PM Barry Song (Xiaomi) <baohua@xxxxxxxxxx> wrote:
>
> Currently, folio_inc_gen() updates lrugen->nr_pages for every folio
> as it advances generations. Instead, accumulate the size changes
> and update lrugen->nr_pages in a batch after scanning the entire
> oldest generation, or when the scan stops because remaining reaches
> zero.
>
> Since we only move folios from the oldest generation to the second
> oldest generation, the active/inactive state cannot change. We can
> therefore skip __lru_update_size().
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@xxxxxxxxxx>
> ---
>  mm/vmscan.c | 46 +++++++++++++++++++++++++++++++++++-----------
>  1 file changed, 35 insertions(+), 11 deletions(-)

Hello Barry

Thanks for the patch!

>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c1404a59523d..0d74fc00abd3 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3296,20 +3296,21 @@ static int folio_update_gen(struct folio *folio, int gen, const vma_flags_t *vma
>  }
>
>  /* protect pages accessed multiple times through file descriptors */
> -static int folio_inc_gen(struct lruvec *lruvec, struct folio *folio)
> +static int __folio_inc_gen(struct folio *folio, int old_gen, bool *increased)

I feel the naming is a bit confusing, the __ prefix doesn't tell how
it differs from folio_inc_gen very well, maybe just name one
folio_inc_gen (the old gen could be any gen), another one is
folio_inc_min_gen (the old gen can only be min_seq), and with sanity
check in folio_inc_min_gen that expects get_nr_gens == 4, and
lru_gen_is_active(min_seq) == lru_gen_is_active(min_seq + 1)? This
could be a build-time sanity check instead of a runtime debug check.

I saw baoquan also mentioned the debug check on
lru_gen_is_active(min_seq) == lru_gen_is_active(min_seq + 1), which I
agree.

And BTW I'm suggesting changing the definition of active/inactive for
MGLRU from gen-based to refs-based. The gen-based active/inactive
reading has been giving us headaches for years and is a main blocker
for server production, and I think no one cares about the
active/inactive reading for MGLRU for desktop / mobile right now
(especially anon active / inactive, which is basiclaly random number
at this point :P, and files are almost always stuck at inactive).

However that contradicts this change by a lot, folio_inc_gen will
always have to update the statistic, see (was planning to send RFC
after more test on Android):

https://github.com/ryncsn/linux/commit/d13a3abdd22a97eca32a7207fce56cc6030a3bd7

This is another reason why I'm trying to avoid aging rather than
optimizing it. I once tried some aging optimization two year ago, the
result was good by then but I gave up due to the added complexity:
https://lore.kernel.org/linux-mm/20240123184552.59758-1-ryncsn@xxxxxxxxx/

I realized the main blocker was cmpxchg and maybe async aging with a
refined reclaim cycle was the better solution rather than making
things complex.

But anyway, let's process with this; perhaps we'll need to find a
different way to batch aging later to fit the implementation of the
FG, OOM prevention or refs-based idea.