Torvalds' page cache patch reworked: 4.5x faster on ext4

Meta engineer Kiryl Shutsemau posted a reworked version of Linus Torvalds' Linux page cache patch on October 19, 2026. The new series has 18 patches. In a 64-thread test on the ext4 file system, small reads of one file rose from about 15 million to about 70 million a second. It also adds fixes for memory problems Torvalds had left open, though the code is still a draft for review.

What changed since Torvalds' version

A week ago, Torvalds published a set of page cache patches he wrote with Claude Code, Anthropic's AI coding assistant. Shutsemau has now taken that work further. His series is titled "mm: read the page cache without folio references."

The cover letter, as archived on Patchew, credits Torvalds' earlier draft. Shutsemau wrote 11 of the 18 patches and Torvalds wrote 7. Together they touch 20 files, adding 770 lines and removing 92. The series builds on Linux 7.3-rc7, a test release.

It is marked RFC, short for "request for comments." That label means the author wants feedback before anyone merges it. Phoronix, which covers Linux performance, called the results a "Fabulous improvement."

The problem: one counter, many processors

Linux keeps recently used file data in memory, in an area called the page cache. The kernel tracks that memory in units called folios. Each folio has a reference count, a counter that says how many readers are using it.

Every read briefly raises that counter and then lowers it. When many processor cores read the same small file, they all fight over one counter. "Small reads of one file from many CPUs all take and drop a reference on the same folio," Shutsemau writes.

How the series fixes it

The series lets ordinary file reads copy data without touching the counter. It covers filemap_read(), the kernel function behind normal file reads. It also covers shmem, the code behind tmpfs, a file system that lives entirely in memory.

To make that safe, a folio such a reader may copy from is freed only after an RCU grace period. RCU is a kernel method that lets readers work without locks. A grace period is a short wait after which every earlier reader is known to be done.

Only busy folios get this treatment. They carry a new flag called PG_rcu_free, which works on 64-bit systems only.

Four patches deal with the memory left waiting during that delay. They add a counter for it and speed up grace periods when memory runs low. Waiting pages are also freed before the out-of-memory killer, large contiguous allocations or memory removal give up. Torvalds had listed the first two as unsolved problems. A final patch adds a switch to turn the new fast path off.

The numbers

Shutsemau tested on a virtual machine with 64 virtual CPUs and 2 GB of memory, running on an AMD Threadripper 7975WX. Each thread read 16 bytes from the start of one file. Results are millions of reads per second.

Test	Before	After
ext4, 64 threads	15.0-15.7	68.9-70.1
tmpfs, 64 threads	1.6-1.7	71-72
XFS, 64 threads	11.3-11.4	20.4-20.5
Raw block device, 64 threads	14.7	28.8-28.9
Any of these, 1 thread	1.6-1.9	1.7-2.0

Those runs used the default CPU security mitigations, which are protections against flaws in the processor itself. Shutsemau says they add about 400 nanoseconds to every read as it crosses into the kernel. With them turned off, the ext4 gain grows from 4.5x to 13x, reaching 217-220 million reads a second. Those figures come from an earlier version with the same small-read path.

There are costs. A workload that keeps re-reading pages the kernel already dropped loses 4% to 6%.

What is still open

The cover letter lists several open questions:

• One patch relies on a check that no file holds the inode open. An inode is the kernel's record of a file. The f2fs file system broke that rule for atomic writes, and a fix is on its way.
• A patch drops a lock from tmpfs reads. Shutsemau thinks it is safe but asks another developer, Hugh, to double-check.
• During a grace period, a waiting folio counts toward no cgroup, the Linux feature that limits memory per container.
• The effect on memory compaction, which gathers free memory into large blocks, has not been measured.
• On some architectures, files mapped for writing still take the slow path.

What this means for developers

• Nothing ships yet. This is an RFC, and no target release is named. Memory-management reviewers will decide its shape.
• Busy shared reads gain most. The big wins come when many threads read the same small cached file. Single-thread reads barely move.
• tmpfs users should watch closely. It went from about 1.6 million to 71 million reads a second at 64 threads, the largest jump in the table.
• Benchmark with your real security settings. Mitigations cost about 400 nanoseconds per read here. Results with them off will not match a hardened production server.
• AI-assisted drafts still go through review. Torvalds' Claude Code draft became a reworked series from another engineer within a week. The normal kernel review path did the rest.