Linus Torvalds used Claude Code to rework the Linux page cache, tripling small read speed

Linus Torvalds Claude Code experiments just reached the heart of Linux. The creator of the kernel has published a branch in his own Linux tree that reworks how the kernel reads from the page cache, and he says plainly that an AI coding assistant wrote most of it. The branch is called `noref-filemap-read-with-llm`, and the name alone tells you how open he is being about where the code came from.

The work is not merged. It is an experiment, and Torvalds himself flags the weakest part. But when the person who has guarded the kernel for more than three decades puts AI written patches in his own repository, people pay attention, and the early benchmark numbers give them a reason to.

What happened

Phoronix founder Michael Larabel spotted the branch on the evening of October 11 while waiting for the next Linux 7.3 release candidate. According to Phoronix, the branch sits in Torvalds' own `torvalds/linux.git` repository, a place where he rarely hosts topic branches. Hardware Busters, which went through the patches in detail on October 12, reports that the series has eight patches built on top of Linux 7.3-rc6.

The cover letter is where the AI part comes in. Phoronix quotes it directly: "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."

So the split of labor is clear. Claude Code, the agentic coding tool from Anthropic, produced the code, the test programs and a review of open problems. Torvalds directed the work and ran the benchmarks himself.

The problem the Linus Torvalds Claude Code branch tries to fix

Every time a program reads a file, Linux usually serves the data from the page cache, a chunk of memory that holds recently used file contents. The cache is organized in units called folios. To read from a folio safely, the kernel normally takes a reference on it so the memory cannot be freed in the middle of the copy.

That reference is a shared counter. When many threads read small pieces of the same file at once, they all hammer the same counter, and the CPU cores spend their time passing that cache line back and forth instead of doing useful work. Hardware Busters notes that kernel developer Matthew Wilcox raised this exact bottleneck in 2024 after seeing it in a customer workload.

The new approach skips the reference entirely. Folios that leave the page cache are only freed after an RCU grace period, a standard kernel mechanism that waits until every reader that might still be looking at the memory has finished. Because the memory is guaranteed to stay valid for that window, readers can copy data straight out without touching the shared counter.

The benchmark numbers

Torvalds tested on his own laptop, which Hardware Busters identifies as a machine with an Intel Core i7-8565U (four cores, eight threads) running with CPU mitigations disabled. The results it reports are striking for the case the patches target:

• With eight threads reading one file, kernel cycles per read dropped from about 2,950 to about 725.
• Throughput in that test rose from roughly 10 million reads per second to between 30 and 33 million, about a threefold jump.
• With a single thread, the cost per read fell from about 453 cycles to about 409, roughly 10% cheaper.
• Cross core cache contention, measured with the `perf c2c` tool, fell from 30,538 load HITMs to 101.

There is a cost on one path. Hardware Busters reports that a 16 byte single thread read into a user page that is not yet mapped got slower, rising from about 4,150 cycles to about 6,550.

The part Torvalds says is unsolved

Delaying frees has a side effect. Memory that would normally be released right away now waits for a grace period, and under pressure that queue can grow. Two of the eight patches add a safety valve: once more than 1,024 pages are waiting per CPU, a worker forces an expedited grace period.

That valve matters. According to Hardware Busters, a stress test in a 2 GiB virtual machine triggered the out of memory killer on four and eight CPUs with only the first six patches applied. With the full series, the test finished on one, two, four and eight CPUs. Torvalds calls the deferred free behavior "the part of this series that is least solved," and that is an honest label for it.

Why it matters

There are two stories here, and both are worth following.

The first is technical. Linux runs most of the world's servers, phones and cloud infrastructure. A change that removes a hot spot in the page cache could help any workload where many threads read the same files, such as web servers, databases and build systems. If something like this lands, most people would never know, but their software would quietly get faster.

The second is cultural. AI written code has a mixed reputation in open source. Earlier this month Google paused its open source bug bounty after a flood of AI generated reports, and a recent survey linked AI coding tools to production outages at large firms. Maintainers worry about volume, about code that looks right but is subtly wrong, and about who is accountable when it breaks.

Torvalds' approach answers some of that. He disclosed the tool in the branch name and in the cover letter, he kept the design decisions under his direction, he ran the measurements himself, and he called out the weak spot instead of hiding it. That is close to what many projects have been asking contributors to do when they use AI.

Not his first time

This is not a sudden conversion. Phoronix notes that Torvalds has used AI for kernel debugging before and has done some "vibe coding" with Google's Antigravity tool outside the kernel tree. The page cache branch is the most visible step so far because it touches core memory management code.

Who is affected

For now, nobody running Linux needs to do anything. The branch is experimental and lives outside the main line of development.

Kernel developers and memory management maintainers are the people who will decide its fate. Hardware Busters points out that acceptance depends on review by the memory management maintainers and on testing on many core and multi socket machines, since a four core laptop is a narrow test bed for a change aimed at heavy contention.

Developers who use tools like Claude Code or similar AI agents will also watch closely. A high profile example of a careful workflow, with disclosure, human direction and human benchmarks, may shape how other projects write their AI policies.

What to watch next

Phoronix says it remains to be seen whether Torvalds merges the branch during the upcoming Linux 7.4 merge window. A few signals will show where it is heading:

• Comments from memory management maintainers on the design, especially the deferred free approach.
• Benchmarks on large servers with many cores, where the contention problem is worst.
• Whether the small read regression on unmapped pages gets fixed or accepted as a tradeoff.
• Whether other senior maintainers follow with their own disclosed AI assisted work.

If you are new to working with coding assistants, our guide to writing better AI prompts covers the basics of directing a model clearly, which is exactly what Torvalds describes doing here. For more coverage like this, visit our AI section.

Frequently asked questions

Did Linus Torvalds really use Claude Code to write kernel code?

Yes. His cover letter, quoted by Phoronix, says the code, test programs, review and first draft of the letter were done with Claude Code under his direction, and that he ran the measurements on his own machine.

Is the change part of Linux now?

No. It lives on a separate branch called `noref-filemap-read-with-llm` and has not been merged. Phoronix says a merge during the Linux 7.4 window is still an open question.

How much faster is it?

On Torvalds' four core laptop, Hardware Busters reports that small reads of one file from eight threads went from about 10 million to 30 to 33 million per second. Single thread reads got about 10% cheaper, while one narrow case got slower.

Should regular Linux users do anything?

No. This is experimental kernel work. Any benefit would only reach users after review, testing and a merge into a future kernel release.