Re: [LSF/MM/BPF] Improving MGLRU

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

On Fri, Mar 6, 2026 at 1:13 AM David Stevens <stevensd@google.com> wrote:
>
> 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.

Nice! Thanks! Do you still plan to continue working on this and
submit it upstream?

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