Re: [LSF/MM/BPF] Improving MGLRU

[David Stevens <stevensd@google.com>]

On Tue, Mar 03, 2026 at 12:06:20PM +0800, Barry Song wrote:
> 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:
> > 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.

I did some experiments with splitting anon and file generations on
ChromeOS a bit over a year ago and got fairly positive results. Although
shifting personal and team priorities unfortunately prevented me from
finishing the project. It didn't get to the point where I was confident
enough in it to send it upstream, but I think it's still worthwhile to
mention here.

For a bit of background, due to a combination of low-spec hardware and a
complicated file system structure, many Chromebooks have poor file I/O
performance. We found that a fairly significant contributor to jank was
important threads being blocked on .text faults. We tried adjusting
swappiness but found that MGLRU was unresponsive to such tuning.
Splitting anon and file into seperate generations and then setting a
fairly high swappiness value resulted in meaningful jank reductions,
especially under very high memory pressure. However, there were
regressions to some workloads that I did not get a chance to try to
address. 

If anyone is interested in seeing the code, it is here [1] in ChromeOS's
6.1 kernel. I also have a WIP series posted to Android's 6.12 GKI kernel
[2], but it hasn't been merged there. This version fixes some issues in
my original series that were exposed by runing on a very different
system, in particular around memcgs. However, it hasn't been tested as
extensively.

[1] https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/929932351492d01f0aee37a0ac3be8c7bd88f80d
[2] https://android.googlesource.com/kernel/common/+log/49cd20cfb0da2361be064f7fd70b36867065277a