Re: [LSF/MM/BPF] Improving MGLRU

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

>> 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.

Best regards
Barry