Linus Torvalds wrote a Linux kernel speedup with Claude Code
Linus Torvalds has published an eight-patch series for the Linux kernel's page cache and says the code, the test programs and the first draft of the write-up were done with Claude Code under his direction. On his laptop, eight threads reading the same small file got three times the reads for a quarter of the CPU cycles. It isn't merged, and Linus lists ten problems he hasn't solved.
What happened
Between October 7 and 10, Linus Torvalds put a branch called noref-filemap-read-with-llm in his own kernel tree: eight patches on top of Linux 7.3-rc6, touching 11 files. His cover letter is plain about how it was made: the code, the test programs, the review behind his list of known problems and the first draft of the text were "done with an LLM coding assistant (Claude Code) under my direction." The measurements, he adds, were run on his own machine. He doesn't name the model.
Every patch carries the tag Assisted-by: LLM next to his sign-off. That's the form the kernel's own rules for AI-assisted contributions settled on this summer: a human signs off and stays responsible, and the tag says a tool helped.
Phoronix spotted the branch on October 11, and the story spread on Reddit, Bluesky and Hacker News.
What the patches do
When many threads read small pieces of the same file, each read briefly takes and drops a reference on the cached page. Those two atomic updates hit the same cache line from every CPU, and on Linus's laptop that one line took 99.92% of the contention. The problem was raised in 2024, and earlier fixes stalled on edge cases.
The series takes a different route: a page that leaves the page cache isn't handed back to the memory allocator until an RCU grace period has passed. A reader that finds the page can then copy the data straight to the user without taking a reference at all. Linus notes that the idea had been suggested several times before but never tried.
The numbers, and their limits
- Eight threads, one file: 9.9–10.4 million reads a second before, 31–33 million after, and kernel cycles per read down from about 2,950 to about 720. In his words: three times the reads, for a quarter of the cycles.
- One thread: a smaller gain, 8 million to 8.8 million reads a second.
- One machine: all of it is from an Intel i7-8565U laptop with 4 cores and 8 threads. He expects bigger servers to gain more, but says nothing bigger has been measured.
- The cost: a read into a memory page that isn't loaded yet gets slower, about 6,700 cycles against about 4,150, because it now faults twice.
What isn't solved
The cover letter ends with ten open problems, the kind of list a reviewer would write. Memory waiting for its grace period is invisible to the allocator. In a 2 GB virtual machine, the first six patches let the out-of-memory killer fire, which patches 7 and 8 work around. There's a regression for CMA memory. The series hasn't been through the kernel's file system test suite, lockdep or KASAN, or run on any machine but his laptop. Two of the items are direct questions to the RCU and scheduler maintainers.
Nothing is merged, and Linus doesn't name a target release. The same weekend he published a second set of fixes, saying a bug report's code was too obscure to follow, so he had LLM tools work through it. They confirmed the reported bug and found three more, the oldest from 2013.
Why it matters
Linus has said for a while that the kernel isn't an anti-AI project and that AI is just a tool. This is the clearest example yet of what he means in practice. The tool wrote the code and the tests, the human chose the approach, ran the benchmarks and signed his name to it, and the write-up spells out what the tool did and what still needs expert review.
Try it
Two prompts for Claude Code that follow the same pattern: you direct, it does the legwork, and the output tells you what it couldn't check.
Read [file or directory, e.g. lib/assoc_array.c] and explain it to me as if I know the language but not this code: what each main function does, the data structure it maintains, and the invariants the code relies on. Then look for places where those invariants can break: off-by-one errors, missing checks, races, error paths that leak or double-free. For each suspected bug, give the line, a concrete input or sequence that triggers it, and how confident you are. Write a small test that reproduces each one you rate high confidence. Don't change the code yet.
Write the description for the change on this branch, for reviewers who know the subsystem. Sections: Problem (what is slow or broken, with the evidence), Idea (the approach in two or three sentences), Numbers (only figures from runs we actually did, with the machine and the exact test), Costs (what gets slower or harder), and Known problems: a numbered list of everything that is untested, argued but not proven, or likely to worry a maintainer. Don't claim anything we haven't measured, and mark guesses as guesses.
More in our Claude Code prompts and the Claude Code cheat sheet.
Sources
- Linus Torvalds, noref-filemap-read-with-llm branch and its cover letter, October 7–10, 2026: the patches, the tools note, numbers and open problems
- Linus Torvalds, assoc-array-fixes tag, October 11, 2026
- Linux kernel documentation, AI coding assistants: the Assisted-by tag and sign-off rules
- Phoronix, Linus Torvalds working on a hefty Linux kernel improvement with Claude Code, October 11, 2026
- Phoronix, Linux is not one of those anti-AI projects, July 2026
- Linus Torvalds on LKML, AI is just a tool, January 7, 2026