Kernel RFC seeks lockless page cache reads for hot pages

Kiryl Shutsemau of Meta has posted a second RFC series that would let the kernel copy data from hot page-cache and tmpfs folios without taking a reference on them, cutting the cache-line thrashing that multi-CPU small reads inflict on a shared folio's refcount.

The work reworks an earlier design from Linus Torvalds. Today, concurrent read() calls on the same few cached pages from many threads all take and drop a reference on the same folio. On large machines that bounce is expensive. The series marks only those folios that keep coming back as accessed with a new flag so their memory is freed only after an RCU grace period. A reader that saw the flag under RCU can then copy without a reference. Streaming and cold data stay on the ordinary free path, so the deferred memory stays bounded.

The gain is narrow but real. Programs that hammer the same pages with system-call reads and keep no userspace cache of their own stop collapsing the page cache under themselves. Workloads that already cache hot data (kernel builds, pgbench, SQLite in Shutsemau's tests) show no change. A read still pays for the system call; the change does not replace a process-private cache. It is 64-bit only and stays off under PREEMPT_RT, where expedited grace periods cannot free waiting pages quickly when memory is short. A debugfs switch can disable the lockless path.

To keep lockless readers safe, the series also stops splice and FUSE from stealing page-cache folios that a reader may still be copying from; those paths fall back to a copy. David Hildenbrand of Arm reviewed the infrastructure and preferred a folio-focused config name and clearer separation of the allocator hook from the page-cache user. Torvalds pushed back on narrowing the free path: hooking the single page-free site keeps the mechanism useful for other lock-free code and avoids fragile special cases. He also urged removing the remaining try-steal machinery in splice and FUSE entirely. "Just remove them both. Good riddance," he wrote.

The series remains an RFC; nothing sets the flag in production kernels yet beyond the proposed read paths.