Linus Torvalds built a Linux kernel speedup with Claude Code

The man who wrote the first Linux kernel just put an AI coding agent's work into his own tree, and he said so in writing. Over the weekend, Linus Torvalds pushed a branch called noref-filemap-read-with-llm to his personal Linux repository. The cover letter for the series is plain about where the work came from: "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."

The branch was spotted by Michael Larabel of Phoronix on October 11, 2026, while he was waiting for the delayed Linux 7.3 rc7 release. That alone was unusual. Torvalds rarely keeps topic branches in his main repository, which normally carries little more than master. This one had "llm" right in the name.

What makes the story bigger than a celebrity using a chatbot is the target. This is not a toy script or a weekend side project. It is a change to the memory management code at the heart of the kernel, aimed at a real scalability problem, and the first numbers are large: on his laptop, eight threads reading the same file now complete roughly three times as many small reads per second.

The problem: one cache line everyone fights over

Linux keeps recently used file data in memory in the page cache. When a program reads a file, the kernel usually serves the bytes from there instead of going back to the disk. Each chunk of cached memory is tracked as a folio, a structure that groups one or more pages.

Today, every small read takes a reference on the folio that backs the page, copies the data, and then drops the reference again. Both steps are atomic writes to the same cache line in memory. When one thread does this, nobody notices. When many threads on many cores hammer tiny reads against the same file, that single cache line bounces from core to core, and the CPUs spend their time fighting over it instead of doing useful work.

According to the commit message reported by Hardware Busters, kernel developer Matthew Wilcox raised this issue in 2024, based on a customer workload. On Torvalds' Core i7 8565U laptop, with eight threads issuing 16 byte pread() calls on one page, that one cache line accounted for 99.92 percent of the cross core load HITMs. A HITM is the event where one core reads a cache line that another core has just modified, which is exactly the expensive ping pong you want to avoid.

Earlier attempts to fix this tried to copy the data into a small buffer on the stack without taking a reference, and then check afterwards whether anything had gone wrong. They stalled on races that such a check cannot see, for example a page that is freed and then reinserted at the same position in the file while the reader is still copying.

The fix: do not free the page yet

Torvalds takes the opposite route. Instead of trying to detect those races, the series removes them. A folio that leaves the page cache is handed back to the page allocator only after an RCU grace period. RCU, short for read copy update, is a long standing kernel mechanism that lets readers work without locks, as long as freed memory is not reused until every reader that might still see it has finished.

With that guarantee in place, a reader inside an RCU read side section can copy straight from the page into the user's buffer. There is no reference count to bump, no bounce buffer, and no limit on the size of the read. The hot cache line simply stops being written on every read.

The series consists of eight patches and sits on top of Linux 7.3 rc6.

The numbers, and where they come from

All measurements in the cover letter come from a single machine: Torvalds' own 4 core, 8 thread laptop, with CPU mitigations disabled. Hardware Busters summarized them like this:

• 8 threads, one file: kernel cycles per read fall from about 2,950 to about 725.
• 8 threads, throughput: from 9.9 to 10.4 million reads per second to 30 to 33 million.
• 1 thread: from 452 to 454 cycles per read down to 408 to 409, roughly 10 percent cheaper.
• Contention: load HITMs measured with perf c2c drop from 30,538 to 101.

The single thread gain is modest, which makes sense: one thread never fights with itself over a cache line. The multi thread result is the headline. Cutting the cost of each read by about three quarters, and the cache line conflicts by more than 99 percent, is the kind of improvement that kernel developers normally chase for months.

Torvalds expects bigger and multi socket machines to gain even more, because they have more cores to fight over the same line. He also admits that nothing larger than his laptop has been tested yet. Those server numbers do not exist, and the laptop numbers have not been reproduced by anyone else.

The catch: memory that waits

Deferring frees is not free. Memory that leaves the page cache now sits around until the grace period ends, instead of going straight back to the allocator. That is exactly the objection Wilcox raised when the idea came up before, and Torvalds does not hide it. He calls it "the part of this series that is least solved."

Two of the eight patches add a safety valve. Once a CPU has more than 1,024 pages queued for freeing, a worker forces an expedited grace period and releases them. The cover letter describes a stress test in a virtual machine with 2 GiB of memory. With only the first six patches, the out of memory killer fired on 4 and 8 CPUs. With the full series, the test ran to completion on 1, 2, 4 and 8 CPUs.

There is also a regression. A read into a user page that is not mapped yet now takes one extra failed exception before it falls back to the old path. For a 16 byte single thread read, that pushes the cost from roughly 4,150 to 6,550 cycles. It is a corner case, but it is the sort of detail memory management maintainers will look at closely.

What Claude Code actually did

The disclosure sits in a short "Tools" section near the end of the cover letter. The split of work is spelled out:

• Claude Code wrote the code, wrote the test programs, did the review behind Torvalds' list of open problems, and produced the first draft of the cover letter.
• Torvalds directed the work and ran the measurements on his own machine.

That framing is important. This is not a model that went off on its own and opened a pull request. It is a senior engineer who knows the problem, knows the history of failed fixes, and used an agent to do the heavy lifting of writing, testing and documenting an idea under close supervision. The open problems list, including the unsolved memory pressure question, is part of the same letter. Nothing about it reads like marketing.

It is still a meaningful step. Torvalds has used AI for kernel debugging before, and he has done some vibe coding with Google's Antigravity outside the kernel tree, according to Phoronix. Crediting an agent with a memory management series in his own repository goes further than either.

A second LLM branch, and three bugs from 2013

The page cache work was not the only sign of this over the weekend. Phoronix reported on October 12 that an assoc-array-fixes tag also appeared in Torvalds' tree. In the tag message, he explained that Nils Ollrogge had reported a bug in the kernel's assoc_array library, along with a fix, but that the code was too obscure for him to follow.

"So I did what I preach: use modern LLM tools to help make sense of it all," Torvalds wrote. The result is an LLM assisted branch that splits large, hard to read functions into smaller ones. The code was then run through a test harness in user space. That harness not only confirmed the reported bug, it found three other bugs, all going back to the very first commit that added the library in 2013.

Those two branches show two different uses of the same tools. One builds a new optimization from a design idea. The other makes old code readable enough that humans and machines can actually test it, and that turned up flaws that had survived for more than a decade.

What happens next

None of this is merged. The page cache branch has been measured on exactly one laptop, and Torvalds openly flags parts of the design he is not sure about. Whether it lands, possibly in the Linux 7.4 merge window, will come down to how the memory management maintainers judge it, and whether someone with a many core server reruns the numbers.

That process is the real test. Kernel review is famously strict, and a patch does not get a pass because of who sent it, or because of which tool helped write it. If the series survives that review, it will be one of the clearest public examples so far of an AI coding agent contributing to core infrastructure that billions of devices depend on.

Why it matters

For years, the debate about AI coding tools has swung between hype and dismissal. This weekend gave a concrete data point from someone with no reason to flatter anyone. Torvalds did not claim the model replaced him. He used it the way he would use a fast, tireless assistant, then published the uncomfortable parts next to the good numbers.

For developers, the lesson is practical. The value here did not come from asking an agent to "make Linux faster." It came from a clear problem statement, a known history of failed approaches, a specific design idea, and careful measurement. The agent helped with code, tests and writing. The judgment stayed human.

For the AI industry, it is a signal that agents are moving from demos into the most conservative code bases in the world, with full disclosure attached. That transparency is worth copying.

Sources

• Phoronix: Linus Torvalds Working On A Hefty Linux Kernel Improvement With Claude Code
• Hardware Busters: Linus Torvalds Uses Claude Code to Rework the Linux Page Cache
• Phoronix: Linus Torvalds "Did What I Preach", Used AI To Make Code Decipherable
• The noref-filemap-read-with-llm branch on git.kernel.org