Skip to main content

Linus Torvalds Used Claude Code on the Kernel. What the Benchmark Does and Doesn't Prove

Linus Torvalds says Claude Code helped write a Linux kernel change that sped up one test three times. The result is real but narrow, and the change is not merged.

By Mohammad Muneer Ahmed
Published: Oct 14, 2026
5 mins read
👁️ 24 Unique Views
Linus Torvalds Used Claude Code on the Kernel. What the Benchmark Does and Doesn't Prove
The scale of inference: Optimized for multimodal workloads.
Premium Insight

Why It Matters

I left this blank on purpose, because I found nothing India-specific and a made-up line would hurt accuracy. One factual angle: the branch is public on kernel.org, so students and developers anywhere can read the patches and rerun the test.

Linus Torvalds, who created Linux, has posted an experimental change to the kernel’s file cache, and he says Anthropic’s coding agent Claude Code helped write it. He reports that one test ran about three times faster on his laptop. The change has not been merged. It is a rare, checkable case of AI-assisted work on critical software, from a very prominent maintainer. It is also easy to overread. Here is what the numbers show and what they do not.

What Torvalds Changed

Linux keeps recently read file data in memory, in the page cache. Each time a program reads a piece of a cached page, the kernel normally raises a counter on the memory unit holding it, called a folio, and lowers it afterward. When many CPU cores read the same file, they fight over that counter, and the memory line holding it bounces between cores.

Torvalds’ eight-patch branch, named noref-filemap-read-with-llm, avoids the counter for small reads. A page that leaves the cache is not reused until a technique called RCU, short for read-copy-update, confirms that readers are done with it. The commit also discusses stopping page faults during the copy, because a fault at the wrong moment could break the safety assumptions, according to Mayhemcode. So a reader can copy straight from the page without touching the counter. The branch sits on Linux 7.3-rc6. Phoronix spotted it on October 11, and the series was reportedly posted to the kernel mailing list on October 12.

The idea is not new. In 2023, kernel developer Matthew Wilcox described a workload of tiny cached reads where counter contention was the limit, and suggested freeing page-cache pages through RCU. In a 2025 thread on a different patch, Torvalds himself floated making page-cache freeing RCU-delayed.

What Claude Code Did and What Torvalds Did

In the main patch message, according to Phoronix, Torvalds says Claude Code produced the code, the test programs, the review behind his list of open problems and the first draft of the cover letter, all “under my direction.” He says he ran the measurements on his own machine.

The wording matters. Torvalds directed the work and ran the tests. The agent did much of the writing and checking. He has used AI tools before, including to help debug a graphics driver and to try vibe coding outside the kernel, Phoronix and daily.dev reported.

What the Benchmark Shows

Reports describing the commit message say the test ran on an Intel Core i7-8565U laptop with four cores and eight threads. Eight threads made 16-byte reads of the same cached page. Reads per second rose from roughly 10 million to about 30 to 33 million. Kernel cycles per read fell from about 2,950 to about 725. Torvalds reportedly found that the counter’s memory line accounted for 99.92% of the loads that had to fetch data from another core’s cache in that setup.

In plain terms, the counter was the bottleneck, and removing it helped. That is a real result, and it matches what kernel developers had suspected for years. It is also narrow. Linuxiac reported that the measurements used ext4 with some security mitigations disabled, and that the patches add overhead in some cases, such as when a page is missing. Hardware Busters noted the branch was measured on one laptop and that Torvalds flags design pieces he is unsure about. Linuxiac added that much of the commit message covers unresolved issues: memory allocation, compatibility and possible regressions.

No independent measurements were found in this research. The branch is public, so others can test it.

What It Does Not Prove and What Comes Next

It does not show that AI can write kernel code unaided. An expert directed the work and ran the tests. It does not show a general speedup. The test is an extreme case: many threads, tiny reads, one page. And a kernel change is judged by review, not by one benchmark. Memory-management code is subtle, and the series is unmerged.

What it does show is AI-assisted work on critical infrastructure done in the open, with disclosure and numbers anyone can check. In the near term, watch for maintainer review, independent benchmarks on server hardware and whether it enters the Linux 7.4 merge window, which Phoronix said remains to be seen. Whether AI-assisted patches become routine in the kernel is a prediction, not a finding.

Found this analysis insightful?

Share with colleagues, engineers, and your network.

Link copied to clipboard!