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

[Barry Song]

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?

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

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