Meta developer turns Torvalds' AI-written page-cache patches into 18-patch RFC with 4.5x ext4 gains

Linus Torvalds' experiment with LLM-generated kernel code has reached the mailing list

On October 19, Meta kernel developer Kiryl Shutsemau posted an 18-patch RFC series to LKML that reorganizes and extends the ten patches Torvalds wrote with an LLM, with benchmarks showing roughly 4.5x faster reads on ext4. According to Joho no Todai, whose report dev.to republished, the jump from git branch to reviewable series took six days.

From git branch to RFC

Torvalds published his patches about a week earlier as a git branch rather than as mailing-list posts. They targeted page-cache read scalability and delivered roughly 23x more read operations per second, from 13.3 million to 304 million with 64 threads, though he acknowledged the figure came from a stress test in which every CPU repeatedly read the same offset of the same file.

Shutsemau, who had posted his own revisions of this work in October 2025, rebuilt the branch into a formal proposal: Torvalds' ten patches reorganized, plus eleven additions of his own. Seven patches authored by Torvalds carry an "Assisted-by: LLM" tag.

What the patches change

When Linux reads a file, the data sits in the page cache as folios, and each read must take and drop a reference on every folio it touches. Those updates are atomic instructions, so when dozens of CPUs hit the same hot folio the cache line holding its counter ping-pongs between cores and throughput collapses. tmpfs was in worse shape: every read also grabbed a folio lock, so before the patches 64 threads ran no faster than one.

The series sidesteps the counter for frequently accessed folios. A folio marked with the new PG_rcu_free flag is not reused after being freed until an RCU grace period has elapsed, the window in which all CPUs finish their current work. Inside that window readers can copy the data without touching the reference count at all. Streaming reads and data read only once do not get the flag, which reportedly keeps the memory held back by deferred freeing small.

The numbers

The benchmarks ran in a KVM guest with 64 virtual CPUs on an AMD Ryzen Threadripper 7975WX, based on Linux 7.3-rc7. The headline test put 64 threads through 16-byte pread() calls at offset 0, each with its own file descriptor.

With default CPU vulnerability mitigations enabled, ext4 climbed from roughly 15 million to 68.9–70.1 million operations per second, about 4.5x, and tmpfs jumped roughly 43x from 1.6–1.7 million to 71–72 million. With mitigations disabled, ext4 reached 217–220 million operations per second, roughly 13x; the cover letter blames about 400 nanoseconds of user/kernel transition overhead per read under default mitigations, around 170 ns for TSA and 230 ns for SRSO, for capping the results.

XFS and block devices improved a more modest 1.8x and 2x, since both still take a shared i_rwsem lock on every read. In 64 KB large-folio tests, tmpfs rose from 96–100k to 1370–1390k MiB/s and ext4 from 756–775k to 1355–1373k MiB/s. Single-threaded reads were essentially unchanged.

Still an RFC

The patches are marked RFC — a request for feedback on the design, not a submission for merging — and the cover letter lists seven unresolved issues. Among them: PG_rcu_free exists only on 64-bit systems and consumes a reference bit that MGLRU needs on large configurations; folios waiting out the grace period are not charged to any memcg; and pageblock freeing is delayed after compaction.

The underlying problem predates all of this: Matthew Wilcox described page-cache reference counting as a buffered-I/O scalability limit years ago, and both Shutsemau and Ilya Gladyshev, the latter through six revisions, chased fixes before.

Why it matters

The series is a striking datapoint for AI-assisted kernel development: an LLM produced the starting point, and within six days a human developer shaped it into something the mailing list can actually review. It also targets a genuine, long-standing bottleneck, and the tmpfs result — from effectively no thread scaling to full parallelism — shows how much performance was being left behind.

But the "Assisted-by: LLM" tag carries no weight on LKML. As Joho no Todai puts it, the series will now be judged on design and code quality alone, with seven open issues standing between it and the mainline kernel.