Re: [RFC PATCH 00/18] mm: read the page cache without folio references

[Kiryl Shutsemau]

On Mon, Oct 19, 2026 at 10:20:52PM +0100, Harry Yoo wrote:
> On Mon, Oct 19, 2026 at 04:48:53PM +0100, Kiryl Shutsemau (Meta) wrote:
> > Small reads of one file from many CPUs all take and drop a reference on
> > the same folio, and its refcount bounces between the CPUs.  This series
> > lets filemap_read() and shmem copy from the page cache without taking a
> > reference.  It is Linus' RFC [1], reworked: a folio that such a reader
> > may copy from is freed only after an RCU grace period.
> >
> > Only the folios that reads keep coming back to get the flag,
> > PG_rcu_free: those that folio_mark_accessed() finds as accessed as the
> > LRU records.  Streaming reads and data that never gets hot are not
> > deferred, so the memory held back stays small and most frees are not
> > touched.
> 
> By applying this to hot folios only, small reads would benefit only when
> they contend on the refcount. That further narrows down the scope of
> workload that would benefit from this. Random or sequential small reads
> still perform the atomics on the refcount.

They do, but an atomic on a cache line the CPU already owns is cheap.
The cost is the line bouncing between CPUs, and that takes many reads of
the same folio, which is what the hot marking looks for.

Single thread, 16-byte pread() of one page, mitigations=off: base does
7.4-7.7M reads/s, the series 7.7-8.0M.  Dropping the reference saves a
few percent when nothing contends.  With 64 threads on the same page,
base falls to 17M reads/s in total and the series does 220M.

> Maybe we should try to either 1) find a better heuristic to mark
> which folios should have PG_rcu_free to make it beneficial for wider
> range of workloads or 2) identify workload that heavly contends on the
> refcount of a small set of folios...

Marking more is not free either.

A flagged folio goes back to the page allocator only after a grace
period, so what reclaim and compaction free is not usable right away,
and they have to work harder to keep up.

I am all for finding a better heuristic. But it is hard balance.

I will get back with data from real workloads.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov