Re: [LSF/MM/BPF TOPIC] Improving MGLRU

[Nhat Pham <nphamcs@gmail.com>]

On Mon, Mar 2, 2026 at 5:32 PM Axel Rasmussen <axelrasmussen@google.com> wrote:
>
> On Fri, Feb 27, 2026 at 9:56 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> >
> > On Thu, Feb 26, 2026 at 03:54:22PM +0000, Matthew Wilcox wrote:
> > > On Fri, Feb 20, 2026 at 01:25:33AM +0800, Kairui Song wrote:
> > > > MGLRU has been introduced in the mainline for years, but we still have two LRUs
> > > > today. There are many reasons MGLRU is still not the only LRU implementation in
> > > > the kernel.
> > >
> > > To my mind, the biggest problem with MGLRU is that Google dumped it on us
> > > and ran away.  Commit 44958000bada claimed that it was now maintained and
> > > added three people as maintainers.  In the six months since that commit,
> > > none of those three people have any commits in mm/!  This is a shameful
> > > state of affairs.
> > >
> > > I say rip it out.
> >
> > I have very similar concerns. Though rather than ripping it out, I would like
> > we put efforts in unifying the two reclaim mechanism (traditional & MGLRU) over
> > improving MGLRU.
>
> Shakeel, I think this is a great idea. If you have any ideas around
> low hanging fruit here, please share. I'm planning to invest much more
> time here going forward, so I'd be happy to turn some ideas into
> patches. :)

Not Shakeel, but I did play a bit with MGLRU in experimentations :) We
see some slight positive signals in certain cases, and instability in
others.

Regarding unification - do you feel like active/inactive LRU can also
benefit from MGLRU's aging mechanism? The page table walk, bloom
filter, potentially the lookaround heuristics? That's one huge
difference between these two algorithms, and tackling this difference
can go a long way towards the unification effort.

Somewhat related to that, I think it would also be nice to have some
counters to track how much work is spent on this page table walking
step for MGLRU. Right now with active/inactive LRU, we can look at the
various reclaim pg* stats (pgsteal, pgscan, etc.), both at the host
and at the cgroup levels, to understand the reclaim dynamics of the
current workload: where its spinning its wheel on, what is the reclaim
efficiency (for e.g, pgscan rate / pgsteal rate is a nice proxy
metric), etc. With MGLRU, the page table walk is a bit of a black box
here to me. Can we have some measures of the effort spend here, for
the sake of understanding and diagnostics when problems crop up?
Otherwise, we can only study the overall CPU cycles/PSI, without
knowing the exact source of the regression.

Or maybe there is already such counter, and the documentation is just missing:

https://docs.kernel.org/admin-guide/mm/multigen_lru.html