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

[Ababneh, Ehab]

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.

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.

> >   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.
> 
> We also have this :
> https://lore.kernel.org/linux-mm/20260901220430.79810-1-
> baohua@xxxxxxxxxx/
> 
> you once reported it as :
> "throughput was approximately
> 49.4K to 50.3K ops/s, averaging about 50.0K ops/s, while the 99th-percentile
> latency remained around 7.0 to 7.1 ms"
> 

Yes, this is from before the data was corrupted. I get slightly different results
with my fix and with the revert, but the overall pattern remains consistent.

Thanks,
Ehab

> >
> > Happy to dig further if useful — let me know if you'd like more detail
> > on the latency distribution or a longer run to confirm these numbers
> > are stable.
> >
> 
> Thanks
> Barry