Re: [LSF/MM/BPF] Improving MGLRU

[Barry Song <21cnbao@gmail.com>]

On Mon, Mar 2, 2026 at 7:10 PM Kairui Song <ryncsn@gmail.com> wrote:
>
> On Fri, Feb 27, 2026 at 11:30 AM Barry Song <21cnbao@gmail.com> wrote:
> >
> > > 4. MGLRU's swappiness is kind of useless in some situations compared to
> > >   Active / Inactive LRU, since its force protects the youngest two gen, so
> > >   quite often we can only reclaim one type of folios. To workaround that, the
> > >   user usually runs force aging before reclaim. So, can we just remove the
> > >   force protection of the youngest two gens?
> >
> > I guess not—MGLRU needs at least two generations to function,
> > similar to active and inactive lists, meaning it requires two lists.
>
> Hi Barry,
>
> You are right. But I think that doesn't mean we can't never reclaim
> the folios in the oldest gen? Or maybe, just let the kernel itself

I think we could reclaim the oldest generation even when
only two generations remain. However, that would make
MGLRU more conceptually confusing. We currently map the
youngest two generations to “active” and the oldest two
to “inactive.”

If there are only two generations, they effectively both
fall into the “active” category, so reclaiming one of them
would mean reclaiming from “active,” which feels rather
counterintuitive to me.

So I’d prefer a two-step approach:
1. Age pages to form inactive generations.
2. Reclaim the “inactive” generations

rather than reclaiming active generations directly.

> perform aging when one type of folios is not reclaimable.

I would prefer to avoid having only two generations.
Ideally, new generations should be created before reaching
that point—similar to the active→inactive transition,
but driven by aging.

>
> We have an internal workaround for forces aging, and waits for sync
> aging if one type of folios are not reclaimable (without the wait, we
> still hit the MIN_NR_GEN protect again since aging is not finished).
> And without the MIN_NR_GEN protection we might end up over reclaiming
> without aging.

I see your point—I did exactly the same thing in Android.
However, there’s a significant problem. If anon has two
generations and files have four, they end up sharing
generations. To age anon, we would also need to move file
folios between generations; otherwise, the hottest and
oldest generations would overlap, causing cold/hot
inversion. Furthermore, in inc_min_seq(), moving folios
means the oldest generation gets pushed into the second-
oldest generation:

new_gen = folio_inc_gen(lruvec, folio, false);
list_move_tail(&folio->lru, &lrugen->folios[new_gen][type][zone]);

This is far from ideal, as it still mixes cold and hot pages
to some extent. Could we keep anon and file generations
separate instead? I feel this is a strong requirement and
likely the first step toward making swappiness work properly.

>
> The problem with that is that the OOM killer became very slow to
> trigger since aging is costly, so the system will hang for minutes
> before OOM is triggered when it should get triggered immediately.

There’s a shrink_active_list() in active/inactive to
prevent inactivation starvation. We likely need something
similar.

A key difference between MGLRU and active/inactive is that
active/inactive performs demotion—moving pages from
active to inactive, with the ability to specify anon or file
types—whereas MGLRU performs promotion, scanning PTEs
to identify young folios for new generations without
distinguishing between anon and file. This could slow down
MGLRU aging exactly when faster memory reclamation is
needed?

Of course, we could treat mm_state as null and skip
walk_mm() for scanning PTEs, but this would make aging
purely a matter of moving folios, without any basis in
whether the PTEs are actually young?

>
> And for the OOM part I saw David Rientjes also mentioned the TTL
> config in MGLRU, I do think TTL is a good idea, we just need to figure
> out a good way to make better use of that.
>
> I think a feasible solution might be (just idea): implement async
> aging; decouple aging and reclaim, reclaim just keep shrinking
> whatever is oldest; and optionally improve thrashing and OOM with TTL.

I’m not sure we want to add a separate thread for async
aging, since kswapd is already quite complex. Could async
aging be handled mainly by kswapd instead? For direct
reclamation cases, if aging is urgent, we might just skip
walk_mm(), or alternatively call inc_max_seq() directly. On
Android, we once completely disabled walk_mm() and only
observed positive effects, which also reduced mmap_lock
contention. So I’m thinking we could consider disabling
walk_mm() by default on hardware that lacks non-leaf
(e.g., PMD) access bits.

I agree that we can leverage TTL to improve OOM handling
and reduce thrashing.

Thanks
Barry