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

[Barry Song]

On Fri, Sep 4, 2026 at 3:46 AM Ababneh, Ehab <ehab.ababneh@xxxxxxxxx> wrote:
[...]
> > > > I guess we could instead try to mitigate the cases where some
> > > > workloads are negatively affected while preserving the original
> > > > intention. Does the fix below address both of your cases, or is Ehab's case
> > actually different from Kairui's?
> > > > (The kernel-build test on my machine looks quite positive. It not
> > > > only preserves the original optimization, but even provides further
> > > > gains.)
> > > >
> > >
> > > 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 very much, Ehab. Could you please also run my proposed quick fix:
> >
> > https://lore.kernel.org/linux-mm/20260901220430.79810-1-
> > baohua@xxxxxxxxxx/
> >
>
> Hi Barry,
>
> Thanks for sending the suggested fix. I tested it with the Cassandra benchmark,
> and the results look promising. Across the runs, 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. This represents an improvement over
> the baseline of approximately 43.98K ops/s and 9.025 ms p99 latency.
>

I am happy to see it is much better, but it still doesn't seem as good
as it was at the very beginning?

- with commit 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
- with revert of commit 6cbdd9726fb5 ("mm/mglru: use folio_mark_accessed to
  replace folio_set_active"):
  p99 ~5.5-5.6 ms, throughput ~51.9k-53.1k op/s
- with this fix: p99 ~5.8 ms, throughput ~51.9k-52.7k op/s

> The underlying idea in both solutions is very similar: A credit-based
> system protects file folios when readahead proves useful. In my version,
> I further tuned credit accounting and used per-CPU batching to
> reduce atomic contention on multicore systems.
>

Your benchmark seems quite likely to access readahead folios.
Let me dig into your patch a bit deeper and see if we can find
a combination of the two approaches.
BTW, does Kairui's MGLRU-FG bring your benchmark back to the
performance you had at the very beginning?

Best Regards
Barry