Meta engineer Kiryl Shutsemau on Monday, October 19, posted a reworked version of Linus Torvalds’ AI-assisted patches that let Linux read from the page cache without taking folio references. The 18-patch request for comments, “mm: read the page cache without folio references,” combines seven patches by Torvalds with 11 of Shutsemau’s own and shows large gains for small, many-threaded reads of a single file, Phoronix reported.
“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,” Shutsemau wrote in the cover letter. “It is Linus’ RFC, reworked: a folio that such a reader may copy from is freed only after an RCU grace period.”
From a Claude Code branch to the mailing list
The work started as an eight-patch branch named noref-filemap-read-with-llm that appeared in Torvalds’ kernel tree, with its top commit dated October 10 and based on Linux 7.3-rc6. In that cover commit, Torvalds wrote that on his laptop, an Intel Core i7-8565U with four cores and eight threads, eight threads doing 16-byte pread() calls on one page sent 99.92% of load HITMs to the line holding the folio’s reference count. Matthew Wilcox had raised the contention in 2024 from a customer workload.
The fix has a folio removed from the page cache go back to the page allocator only after an RCU grace period, so a reader under rcu_read_lock() can copy the data straight to the user buffer with page faults disabled. On the laptop, kernel cycles per read with eight threads fell from 2,937-2,975 to 725-726, and reads per second rose from 9.9-10.4 million to 30-33 million. Torvalds cautioned that the machine throttles on temperature, so cost per read was the better comparison.
“The code, the test programs, the review behind the list above and the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction. The measurements were run on my machine,” he wrote. The cover commit also listed ten known problems, including that the page allocator cannot see pages waiting for a grace period, which in one test let the OOM killer fire in a 2 GiB virtual machine.
On October 13 Torvalds took a revised ten-patch version, rcu-free-v3, to the kernel mailing list under the subject “Improve page refcount scalability.” That version delays the free only for folios that reads keep returning to. He reported 64 threads going from 13.3 million to 304 million reads per second on a Ryzen Threadripper, though he added that “that’s not a real number in the sense that no real load will ever see it.” WebProNews covered a second LLM-assisted Torvalds branch, for the assoc_array library, on October 14.
What the rework changes
Shutsemau’s version, based on Linux 7.3-rc7, marks only hot folios with the new PG_rcu_free flag. “Streaming reads and data that never gets hot are not deferred, so the memory held back stays small and most frees are not touched,” he wrote. His patches also free the waiting pages before the kernel resorts to the OOM killer or lets an isolation fail, and extend the lockless reads to large folios and to tmpfs.
He tested in a 64-vCPU KVM guest on an AMD Threadripper 7975WX with default CPU security mitigations, which he said cost about 400 ns per read at the user/kernel boundary on that machine. With 64 threads, ext4 went from 15.0-15.7 million to 68.9-70.1 million reads per second, and tmpfs from 1.6-1.7 million to 71-72 million. XFS rose from 11.3-11.4 million to 20.4-20.5 million and a raw block device from 14.7 million to 28.8-28.9 million; both still take a shared i_rwsem on every read. With mitigations off, an earlier version of the series pushed ext4 to 217-220 million. Single-threaded reads were roughly unchanged, and a load that keeps refaulting lost 4-6%, which he said matches Torvalds’ RFC.
The series is still an RFC with open items. One of them is patch 17, which drops the folio lock from tmpfs reads. “I believe this is safe, but would like Hugh to double check,” Shutsemau wrote.