Re: [LSF/MM/BPF] Improving MGLRU

[Gregory Price <gourry@gourry.net>]

On Fri, Feb 27, 2026 at 12:31:39PM +0800, Barry 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.
> 
> Hi Matthew,  
> Can we keep it for now? Kairui, Zicheng, and I are working on it.
> 
> From what I’ve seen, it performs much better than the active/inactive  
> approach after applying a few vendor hooks on Android, such as forced  
> aging and avoiding direct activation of read-ahead folios during page  
> faults, among others. To be honest, performance was worse than  
> active/inactive without those hooks, which are still not in mainline.  
> 
> It just needs more work. MGLRU has many strong design aspects, including  
> using more generations to differentiate cold from hot, the look-around 
> mechanism to reduce scanning overhead by leveraging cache locality,  
> and data structure designs that minimize lock holding.

In presentations where the distribution of generations is shown for
different workloads, I've seen many bi-modal distributions for MGLRU
(where oldest and youngest contain the bulk of the folios).

It makes the value of multiple generations questionable - especially at
the level MGLRU emulates it right now (multiple generations PLUS multiple
tiers within those generations).

One of the issues with MGLRU is it's actually quite difficult to
determine which feature it introduces (there are 7 or 8 major features)
is responsible for producing any given effect on a workload.

In a random test over the weekend where I turned everything but
multiple generations off (no page table scan, no bloom filter, etc -
MGLRU just defaults to a multi-gen FIFO) I found that streaming
workloads did better this way.  

Makes sense, given that MGLRU is trying to protect working set,
but I didn't expect it to be that dramatic.

It seems at best problematic to argue "We just need more heuristics!",
but clearly MGLRU "works, for some definition of the word works".

~Gregory