A Meta kernel developer reworked Torvalds' Claude Code-written page-cache patches into an 18-patch RFC series, reporting roughly 4.5x faster ext4 reads on LKML and up to 13x with mitigations disabled.
Key points
- What happened: Meta's Kiryl Shutsemau reorganized Torvalds' LLM-generated, 10-patch proof of concept into an 18-patch RFC series and posted it to LKML
- Performance: Roughly 4.5x faster reads on ext4 and 43x on tmpfs; roughly 13x on ext4 with mitigations disabled; almost no change with one thread
- Mechanism: Deferring the freeing of frequently accessed folios until after an RCU grace period eliminates reference-count operations during reads
- Current status: The patches remain at the RFC stage, with seven unresolved issues including a 64-bit restriction and a gap in memcg accounting; the Assisted-by: LLM tag has no bearing on mailing-list review criteria
From experiment to proposal in one week
Last week, Linus Torvalds used an LLM to write patches improving Linux kernel page-cache read performance (in Japanese). The 10-patch series showed roughly 23x faster reads, rising from 13.3 million to 304 million operations per second with 64 threads. As Torvalds himself acknowledged, however, these figures came from an extreme microbenchmark in which every CPU repeatedly reads the same location in the same file. He published a git branch rather than posting individual patches to the mailing list.
Six days later, on October 19, Meta kernel hacker Kiryl Shutsemau posted an 18-patch RFC series to LKML based on Torvalds' code.
Shutsemau is among the developers who have worked on this problem previously, having posted revised patches in October 2025. The new series reorganizes Torvalds' 10 patches with 11 additions of his own. Each of the seven original patches authored by Torvalds carries an Assisted-by: LLM tag.
Experimental AI-written code has been refined by another developer and submitted for formal review on the kernel mailing list.
What is slow, and why does this make it faster?
When Linux reads a file, data retrieved from disk is retained in the page cache. Subsequent reads of the same data return the in-memory copy without going back to disk.
The problem arises when multiple CPUs read the same file concurrently. The memory-management units in the page cache, called folios, are managed through reference counts that must be incremented and decremented on every read. These operations use atomic instructions, exclusive updates that guarantee consistency across CPUs. When 64 CPUs try to update the same folio's counter simultaneously, the cache line keeps bouncing between CPUs, and performance collapses.
The situation is worse on tmpfs, an in-memory file system. Each read acquires a folio lock as well as updating the reference count, so before the patches, even 64 threads delivered the same speed as one thread.
The patches address this by eliminating reference-count acquisition itself. Frequently accessed, "hot" folios receive the PG_rcu_free flag. Even after such a folio is freed, its memory is not reused until an RCU grace period, the interval allowing all CPUs to finish their current processing, has elapsed. Within that interval, readers can copy the data without touching the reference count at all.
The benefit is greater for data that is rarely written. Streaming reads and data accessed only once do not receive the flag, reportedly keeping the amount of memory retained through deferred freeing small.
4.5x on ext4, 43x on tmpfs
Shutsemau's benchmarks use a KVM guest with 64 virtual CPUs on an AMD Ryzen Threadripper 7975WX (Zen 4), based on Linux 7.3-rc7.
Results with 64 threads repeatedly performing 16-byte pread() calls at offset 0, each thread using its own file descriptor, vary considerably by file system.
Joho no Todai confirmed that with the default CPU vulnerability mitigations enabled, ext4 improved roughly 4.5x, from around 15 million operations per second to 68.9–70.1 million. tmpfs jumped roughly 43x, from 1.6–1.7 million to 71–72 million operations per second. Given that the folio lock had previously all but eliminated tmpfs's 64-thread parallelism, this jump shows how much potential was unlocked.
Disabling CPU vulnerability mitigations pushes the figures higher still. ext4 reaches 217M–220M reads per second, roughly 13x faster. tmpfs reaches 230M–239M reads per second. According to the cover letter, default mitigations add about 400 nanoseconds of user/kernel boundary overhead per read, approximately 170 ns for TSA and 230 ns for SRSO, imposing a performance ceiling.
XFS and block devices see more modest improvements than ext4, roughly 1.8x and 2x respectively with 64 threads. Both acquire a shared i_rwsem lock on every read, so lock bouncing remains even after reference-count contention is removed.
In large-folio read tests using 64 KB reads, 64 threads, and one file, huge tmpfs improves from 96–100k MiB/s to 1370–1390k MiB/s, while ext4 rises from 756–775k MiB/s to 1355–1373k MiB/s, substantial gains in both cases.
Single-thread read performance shows no significant change, moving from 1.6–1.9 million to 1.7–2 million operations per second. Where reference-count contention does not arise, the patches' overhead also remains close to zero.
Still an RFC
The patches' subject lines say [RFC PATCH]. In kernel development, RFC, or Request for Comments, means patches seeking feedback on the design direction. They are not a formal submission for merging.
The cover letter lists seven unresolved issues. The PG_rcu_free page flag is available only on 64-bit systems and consumes one of the reference bits used by MGLRU (Multi-Generational LRU, a page-reclaim algorithm) on large configurations. Other issues include a grace period during which folios awaiting deferred freeing are not accounted to any memcg (memory cgroup), and delayed freeing of pageblocks after compaction.
Multiple developers have worked on page-cache reference counting since Matthew Wilcox described it as a buffered-I/O scalability limit several years ago. Shutsemau tackled it himself in 2025, while Ilya Gladyshev pursued another approach through six revisions. The new patches build on the issues those attempts left unresolved.
The speed with which Torvalds' LLM-written proof of concept became a formal RFC patch series in six days is noteworthy, but from here onward, code design and quality are what matter. The Assisted-by: LLM tag has no bearing on whether the patches pass mailing-list review.
Originally published on Joho no Todai. The Japanese original is here.
Top comments (0)