Re: [RFC PATCH] mm/mglru: dynamically protect readahead fault folios under refault pressure

[Kairui Song]

Ababneh, Ehab <ehab.ababneh@xxxxxxxxx> 于 2026年9月25日周五 01:54写道：
>
> Hi Barry,
>
> > -----Original Message-----
> > From: Barry Song <baohua@xxxxxxxxxx>
> > Sent: Wednesday, September 23, 2026 9:08 PM
> > To: Ababneh, Ehab <ehab.ababneh@xxxxxxxxx>
> > Cc: ryncsn@xxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx;
> > axelrasmussen@xxxxxxxxxx; kasong@xxxxxxxxxxx; lance.yang@xxxxxxxxx;
> > linux-kernel@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; qi.zheng@xxxxxxxxx;
> > shakeel.butt@xxxxxxxxx; weixugc@xxxxxxxxxx; yuanchu@xxxxxxxxxx;
> > yuzhao@xxxxxxxxxx
> > Subject: Re: [RFC PATCH] mm/mglru: dynamically protect readahead fault
> > folios under refault pressure
> >
> > On Thu, Sep 24, 2026 at 11:43 AM Ababneh, Ehab
> > <ehab.ababneh@xxxxxxxxx> wrote:
> > >
> > > Hi Kairui, Barry,
> > >
> > > Apologies for the delay in getting back to you with these results — my
> > > test environment got corrupted and I had to spend some time recovering
> > > it before I could re-run the benchmark.
> >
> > No worries, Ehab. And thanks very much for your testing!
> >
> > [...]
> >
> > > > > > I agree that reverting the commit that caused the regression is
> > > > > > not the optimal path. I expect there are many workloads and
> > > > > > scenarios that benefit from the behavior introduced by that
> > > > > > commit, so reverting it could unnecessarily regress those workloads.
> > > > > >
> > > > > > I will run the Cassandra benchmark with Kairui's MGLRU-FG
> > > > > > patches to see whether they address the issue I am seeing. I
> > > > > > will send the results when they are ready.
> > > > > >
> > >
> > > Thanks for the pointer — I gave your MGLRU-FG fix a try against the
> > > same Cassandra read benchmark I used for my patch (4 nodes, 720s, 100
> > readers).
> > >
> > > Results with MGLRU-FG:
> > >   Op rate:                  55.0k - 56.5k op/s
>
> >
> > I noticed this is even higher than your dynamic readahead fix: "throughput
> > ~51.9k-52.7k op/s"
> >
> > Is this a run-to-run variation, or is the improvement stable across runs?
> >
>
> Yes, I can't explain the slight gain in throughput but loss in latency compared
> to my fix. I'll probably study this in more detail when I can dedicate some
> time to it.

Hi Ehab,

That's very interesting, I think it means we are getting a bit better
at identifying the working set. But maybe a slightly high cost of
aging? And P99 is usually very sensitive to noises, one long tailing
aging event could make it look a lot worse.

> Typically, I get a unique result immediately after a reboot, but subsequent
> runs are very consistent. The variation is usually around 0.1 ms gain/loss in
> latency and approximately 100-200 requests per second in throughput. I
> discard the results from the first run.

Any way I can reproduce this? E.g. what is the test bench, database
size, benchmark, machine spec, etc?

> > >   Latency 99th percentile:  6.8 - 6.9 ms
> > >
> > > For reference, here's where the other variants landed on the same setup:
> > >
> > >   Regression (6cbdd9726fb5, "mm/mglru: use folio_mark_accessed to
> > >   replace folio_set_active"):
> > >       p99 ~9.2-9.5 ms, throughput ~41.8k-43.6k op/s
> > >
> > >   Revert of 6cbdd9726fb5:
> > >       p99 ~5.5-5.6 ms, throughput ~51.9k-53.1k op/s
> > >
> > >   My dynamic readahead-credit fix:
> > >       p99 ~5.8 ms, throughput ~51.9k-52.7k op/s
> > >
> > > So MGLRU-FG recovers most of the latency regression, but the revert
> > > and my fix still recover more of it: p99 with MGLRU-FG is noticeably
> > > higher than with the revert and my fix (6.8-6.9 ms vs ~5.5-5.8 ms),
> > > though it's still a big improvement over the regression's 9.2-9.5 ms

Did you test the V2 or V1 of MGLRU-FG? V2 includes Barry's aging
optimization; I'm not sure if this latency is caused by aging or maybe
some other change.

And is there any swap device you used, or is the test using the same
base commit? MM also changes significantly between different
baselines.