Re: [RFC PATCH v2 5/5] mm: mglru: run aging if the preferred type has no folios in reclaimable gens

[Barry Song]

On Fri, Jul 31, 2026 at 3:27 PM Baolin Wang
<baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 7/26/26 8:21 PM, Barry Song (Xiaomi) wrote:
> > Respect the type selected by positive_ctrl_err(). If there are no
> > reclaimable gens left for that type, run aging.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@xxxxxxxxxx>
> > ---
> >   mm/vmscan.c | 4 ++++
> >   1 file changed, 4 insertions(+)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 7c13dedb0b1f..d63322cdb1bc 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -4996,6 +4996,10 @@ static bool should_run_aging(struct lruvec *lruvec, unsigned long max_seq,
> >       if (evictable_min_seq(min_seq, swappiness) + MIN_NR_GENS > max_seq)
> >               return true;
> >
> > +     /* run aging if the preferred type is exhausted */
> > +     if (min_seq[type] + MIN_NR_GENS > max_seq)
> > +             return true;
> > +
> >       /* try to avoid aging, do gentle reclaim at the default priority */
> >       if (sc->priority == DEF_PRIORITY)
> >               return false;
>
> Looks reasonable to me.

Yes, this is reasonable. However, I also noticed that it can
slightly increase system time at moderate swappiness values
during a kernel build.

At swappiness values near 100, overall performance is more
important than strictly preserving the swappiness bias. To
address this, I refined the behavior for balanced swappiness
in v3:
https://lore.kernel.org/linux-mm/20260731083843.37811-7-baohua@xxxxxxxxxx/

>
> Additionally, for sc->priority > DEF_PRIORITY, is there the same check
> logic for the scan type?
>
> if (min_seq[type] + MIN_NR_GENS == max_seq)
>         return true;

We also have an imbalance check: if there are only three
generations (min_seq[type] + MIN_NR_GENS == max_seq) and the
folio distribution is heavily skewed across them, we trigger
aging. This helps preserve the intended swappiness bias:

https://lore.kernel.org/linux-mm/20260731083843.37811-6-baohua@xxxxxxxxxx/

Thanks
Barry