Linus Torvalds, the creator of Linux and the lead maintainer of kernel development, used Anthropic’s Claude Code tool to help address a more-than-two-year-old bottleneck in the file-read path. A series of 10 patches delivered a 23-fold improvement in read throughput in an artificial test on a 64-core Threadripper system, but Linux kernel reviewers later discovered a race condition and raised questions about the safety of the memory-reclamation design, meaning that the patches have not yet been merged.
A problem with page-memory reference counters
The work concerns contention over reference counters for objects known as folios inside the page cache, a layer that retains data read from files to speed up access. The bottleneck was reported in 2024 after appearing in a customer workload, and tests on Torvalds’s laptop showed that this contention accounted for 99.92% of HITM operations across the cores in a test using eight threads.
Torvalds said he had spent 18 months running a flawed version of his earlier fix for the problem, while other developers encountered issues in their attempts. The new patches aim to remove folio reference increments and decrements from the most commonly used cached-read path, with Torvalds warning that the gains would be much smaller in real-world workloads than in the artificial test.
Claude Code’s role and the result’s limitations
A test branch named noref-filemap-read-with-llm appeared in Torvalds’s tree, and the series then included an explanation of Claude Code’s role. According to Torvalds, the tool wrote the implementation, tests, and initial documentation, and also reviewed the code under his direction, while he ran the performance tests himself.
The first series increased the read rate on his laptop from about 10 million to 33 million reads per second, and reduced the number of kernel cycles per read from approximately 2,950 to 725. The revised series increased performance on a Threadripper system from 13.3 million to 304 million reads per second under heavy load, while reducing cycles per read from nearly 20,000 to 735.
Why performance figures are not enough
The improvement came with potential costs. The initial implementation imposed a forced waiting period when the CPU exceeded 1,024 pages pending reclamation. Reads into unrelated user pages also incurred an additional fault before returning to the existing path, increasing the cost of a single-threaded 16-byte read from approximately 4,150 to 6,550 cycles. It is not yet clear whether this regression will remain in the rcu-free-v3 release.
Review revealed the more serious risk
Matthew Wilcox objected to using the new PG_rcu_free flag and proposed an alternative based on the page type and a different mechanism for reclaiming inactive folios. Kiryl Shutsemau also proposed restricting the flag to 64-bit systems, an approach supported by David Hildenbrand.
Shutsemau also discovered a race condition in the filemap_read_rcu_batch() function: replacing a folio and then enlarging the file could expose data that had not actually been written. Torvalds proposed reading the file size earlier and grouping the checks, which was included in a revised patch.
certi.news’s editorial reading: The case shows that AI programming tools can quickly achieve major improvements in kernel tests, but they do not eliminate the need for specialized review that understands concurrency and the memory life cycle. The record figures here demonstrate a gain in a specific environment, not automatic readiness for merging or a guarantee of implementation safety.