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

[Ababneh, Ehab]

> -----Original Message-----
> From: Barry Song <baohua@xxxxxxxxxx>
> Sent: Thursday, September 3, 2026 2:38 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 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?
> 
Hi Barry, All,

It is not as performant as its best, but it recovers most of the regression. During
the regression, latency had spiked to around 9 ms. After applying the patch, it has
come back down to 5.8 ms. Overall, this is still better than where it was about two
months ago, when I was typically seeing 6.2 to 6.3 ms.

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

Yes, it does seem to access readahead folios. I also think this benchmark exercises
an access pattern that is generic enough that similar behavior could show up in
a wide range of real-world applications, rather than being something specific to
this particular workload.

> BTW, does Kairui's MGLRU-FG bring your benchmark back to the performance
> you had at the very beginning?
> 
Not yet, but I'll be trying Kairui's MGLRU-FG today or tomorrow and will report
Back once I have some results.

Thanks,
Ehab

> Best Regards
> Barry