“I used to think AI was pretty bad, but now I really like using it.”
That is not something you would expect to hear from someone who built one of the world’s most important operating system kernels.
But that is exactly how Linus Torvalds, the creator of Linux, has described his changing attitude toward AI.
On October 10, 2026, Torvalds published an experimental series of eight patches in his Linux kernel repository. The branch name was unusual: noref-filemap-read-with-llm.
The llm part was no accident. Torvalds openly acknowledged using Claude Code to help develop the changes.
And the results were impressive. In a specific test involving eight threads reading tiny pieces of the same file, the new code increased throughput from about 10 million reads per second to as many as 33 million.
So, what did AI help him fix?
Table of Contents
A Small Read With Too Much Overhead
You don’t need to be a kernel developer to follow this.
Linux uses the page cache to keep recently accessed file data in memory. This lets applications read cached data without repeatedly accessing storage.
But when multiple threads read the same cached data, the kernel must ensure that the underlying memory is not freed while it is still being used.
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
Traditionally, this involves updating reference counts on memory objects called folios. When many CPU cores repeatedly update the same shared counter, the synchronization overhead can become expensive.
For large reads, that overhead may be relatively insignificant. For a 16-byte read, it can become a substantial part of the work.
The problem was not entirely new. Linux kernel developer Matthew Wilcox had identified this performance issue years earlier.
Torvalds wanted to try a different approach.
How Claude Code Helped Make It Faster
The experimental solution uses a Linux kernel mechanism called Read-Copy-Update, or RCU.
You do not need to understand every detail of RCU to understand the idea.
Instead of making every reader repeatedly update the same reference counter, the new approach allows readers to access the cached data under RCU protection. The kernel delays reclaiming the relevant memory until it is safe to reuse.
This reduces the need for repeated reference-count updates on the read path.
There is a trade-off, of course. Memory cannot be returned to the allocator immediately if an RCU-protected reader might still be using it. The kernel must wait until the relevant grace period has passed.
But for this particular workload, avoiding repeated synchronization turned out to be worthwhile.
Torvalds tested the changes on a laptop with an Intel Core i7–8565U processor, which has four physical cores and eight threads.
With eight threads issuing 16-byte pread() requests against the same file page, the results looked like this:
- Before: roughly 9.9–10.4 million reads per second.
- After: roughly 30–33 million reads per second.
- CPU cost per read: dropped from around 2,950 cycles to about 725.
The single-threaded improvement was much smaller. CPU cycles per read fell from roughly 452–454 to 408–409.
That difference tells us something important: this is primarily a fix for contention between threads, not a universal speed boost for all file operations.
Torvalds Did Not Just Ask AI to Write Some Code
What makes this story different from another AI coding demonstration is Torvalds’ own description of the process.
In his commit message, he explained that the code, test programs, review work, and initial draft of the commit description were produced with the help of Claude Code under his direction.
So AI was involved in more than generating a few lines of code. It helped with implementation, testing, and the material used to review and explain the changes.
Still, there is a big difference between having AI help develop a patch and letting AI decide that the patch is ready.
Torvalds acknowledged that memory reclamation was one of the weakest parts of the current implementation. Delaying memory reuse can increase memory pressure.
There is also a performance problem when a read targets a page that has not yet been mapped into userspace. The experimental path can trigger an unsuccessful fault-handling attempt before falling back to the original code, adding unnecessary work.
That is why the patches remain experimental rather than being part of the mainline Linux kernel.
The benchmark is promising, but there is more work to do before anyone can say the optimization is ready for production.
The Real Lesson Is Not the 3x Speedup
It is tempting to turn this into a story about AI writing better code than humans. That would miss the point.
The performance gain came from addressing a specific bottleneck: the cost of coordinating shared reference-count updates when multiple threads read tiny amounts of cached data.
Claude Code helped Torvalds work on a solution, and the benchmark showed that the approach could deliver a substantial improvement under those conditions.
Whether the patches eventually make it into the mainline kernel remains an open question.
For Linux developers, the more interesting takeaway is that AI is becoming another tool for investigating difficult problems in systems software. It can help experienced engineers explore ideas, write tests, and work through unfamiliar code.
But the hard part has not changed.
Making code run is one thing. Proving that it is correct, safe, and worth merging into Linux is another.
