Linus Torvalds has published a kernel branch whose cover letter says an AI wrote most of it. The branch is called noref-filemap-read-with-llm, and in the cover letter he states that "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," adding that "the measurements were run on my machine." The quotes come via Startup Fortune's report; Phoronix spotted the branch first. The patch has not been merged.
This is the most concrete step yet in a run of public moves by Torvalds on AI, after the Open Source Summit Europe conversation we covered on October 9. Below: what the patch does in plain language, the numbers and how far to trust them, and what the reaction should look like if you build with coding agents.
TL;DR: the patch at a glance
| Question | Answer |
|---|---|
| What is it? | A patch series on branch noref-filemap-read-with-llm in Torvalds's repository |
| Who wrote it? | Claude Code wrote the code, tests, review and first cover-letter draft, "under my direction" |
| What does it fix? | Contention on the folio reference count when many threads do small reads of one file |
| Reported gain | About 2,950 to 725 kernel cycles per read; roughly 10M to 30-33M reads per second (his laptop) |
| Reported cost | A single-thread unmapped-page case got slower, about 4,150 to 6,550 cycles |
| Merged? | No. Phoronix says it could target the Linux 7.4 merge window |
| Independently verified? | No public reproduction on other hardware at the time of writing |
What does the patch change in the Linux page cache?
The page cache keeps recently read file data in memory so the kernel does not hit the disk again. It stores that data in folios, the unit the kernel uses to manage groups of pages. When a thread reads from a cached file, the kernel normally takes a reference on the folio, copies the data out, then drops the reference.
That reference is an atomic counter. If many threads read small pieces of the same file at once, every read increments and decrements a counter on the same cache line. According to the Pasquale Pillitteri write-up, the CPUs end up waiting on each other instead of copying data.
The patch removes that counter from the read path. Per the reports, reads now happen inside an RCU read-side critical section. RCU (read-copy-update) is the kernel mechanism that lets many readers proceed without locking, while memory is freed only after a grace period guarantees no reader still holds it. Startup Fortune also describes a safety valve: if more than 1,024 pages per CPU are queued waiting to be freed, the kernel forces an expedited grace period so memory does not pile up.
If that sounds abstract, the practical point is simple. The kernel spends its life reading files that are already in memory, so even small savings on this path get multiplied by enormous call counts.
The numbers: what was measured and how much to trust it
The figures circulating come from Startup Fortune, which attributes some of them to Hardware Busters, and are repeated by Pillitteri. They describe one machine: a Core i7-8565U laptop doing 16-byte reads across eight threads.
| Measure | Before | After |
|---|---|---|
| Kernel cycles per read (8 threads) | about 2,950 | about 725 |
| Load HITM events (cache-line contention) | 30,538 | 101 |
| Reads per second | about 10 million | about 30-33 million |
| Single thread, unmapped page (cycles) | about 4,150 | about 6,550 |
A HITM is a load that finds its cache line already modified by another core, the signature of the ping-pong this patch targets. The drop from 30,538 to 101 is the clearest evidence that the contention really went away on that workload.
Treat the headline as preliminary for three reasons. First, the benchmark was built to maximize contention: tiny reads, many threads, one file. Second, the numbers are Torvalds's own, from one laptop, and sources disagree on the exact throughput range (the "before" is quoted as 9.9 to 10.4 million, the "after" as 30 to 33 million). Third, the single-thread row got worse. That is a normal trade for a path designed around concurrency, but real workloads mix reads, writes and mapped pages, so the net effect on servers is unknown until others measure it.
Magnifying lens inspecting one replacement tile in a mosaic, representing review of a Claude Code kernel patch
Why this patch has a history
The idea did not appear from nowhere. According to Pillitteri, in October 2025 Kiryl Shutsemau proposed a shortcut called "mm/filemap: Implement fast short reads," based on a sequence counter. David Hildenbrand objected that the code had to guarantee it was reading from a folio that had not been reused, and suggested delaying folio freeing with RCU instead. Torvalds noted that the page cache already has the whole folio_try_get() dance and that freeing was not delayed with RCU.
A year later, the alternative raised in that thread, deferred freeing under RCU, is the route this branch takes. So the interesting part is not that an AI invented a new concept. It implemented a direction humans had already argued for, in a part of the kernel where mistakes are expensive, and a human with decades of context chose the trade-off and ran the numbers.
A timeline of Torvalds and AI tools
Torvalds's stance has moved in steps, as best we can reconstruct from the coverage:
- October 2024: he said about 90 percent of AI talk was marketing hype, as Startup Fortune recalls.
- January 2026: he admitted in the README of his AudioNoise guitar-pedal project that its Python visualizer was vibe coded with Google Antigravity, per Pillitteri citing Phoronix.
- May 2026: he said AI-generated bug reports had made the kernel security list "almost entirely unmanageable," per Startup Fortune. That complaint echoes what we saw when Google froze its open-source bug bounty over AI slop reports.
- July 15, 2026: he wrote that "Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it," then "Or just walk away."
- August 21, 2026: he signed an Intel Xe driver fix and wrote that an AI did much of the grunt work, per Pillitteri's account of Phoronix.
- October 9, 2026: at Open Source Summit Europe he said he "really likes using AI" but urged care on real projects (our summary).
- October 12, 2026: the page-cache branch with Claude Code named in the cover letter.
Read in order, this is a progression from hobby code to a debugging session to a function in the heart of memory management. That jump in stakes is the real story.
What people are asking
Does "written by Claude Code" mean nobody reviewed it?
No. Torvalds's phrase is "under my direction," and he says the measurements were run on his machine. The disclosure also covers the review, which raises a fair question Pillitteri flags: when tests and code come from the same source, who checks whom? The kernel's answer is the same as before the AI era. The patch goes through mailing-list review by the memory-management maintainers, who read every line they accept. Nothing in the reports says that review has happened yet.
Is this different from the AI slop kernel maintainers complain about?
Yes, and Startup Fortune draws the same line: a maintainer who directed the tool, verified output against measurements and attached his name is a different thing from a model-written vulnerability report nobody asked for. The disclosure itself matters too. Compare how System76's COSMIC desktop banned AI-generated code outright. Two prominent open-source projects now sit on opposite sides of the question, and the kernel is the one with the larger installed base.
Should I trust AI-written systems code?
The honest answer from this episode is: trust the process, not the label. The same discipline applies whether a human or a model wrote the first draft. We made the case in should developers stop reviewing AI-generated code, and this branch is a live example of the opposite behavior: lots of AI output, with an expert reviewer and real hardware measurements in the loop.
What does this mean for people building with coding agents?
Three practical takeaways:
- Give the agent a measurable target. The patch has a benchmark, a counter (HITM events) and a named regression (single-thread cycles). An agent works far better when the success criterion is a number it can run.
- Keep the expert in the loop. The value Torvalds brought was knowing which approach had already been argued for, and which trade-off was acceptable.
- Disclose. A cover letter that says how the code was produced is cheap and builds more trust than silence. Similar rewrite stories, such as DHH's Fable-assisted Rust rewrite and the LLM-written Rust port of the TypeScript compiler, show how much depends on the parity checks around the model.
If you let agents run commands against real systems, add guardrails first; the rm -rf incident write-up shows what goes wrong without them. For autonomous agents more broadly, AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions.
What is still unknown
- Merge status. The branch is not in the mainline. Phoronix reports it could be taken in the Linux 7.4 merge window. One source says the branch targets 7.3-rc6 while Phoronix framed it around waiting for 7.3-rc7, so the exact base is inconsistent across coverage.
- Reviewer reaction. The coverage we read has no responses from the memory-management maintainers.
- Other hardware. No public benchmarks on many-core servers, mixed read and write loads, or other architectures.
- Correctness under pressure. Delaying folio freeing under RCU changes memory behavior. Memory pressure, hot unplug and filesystem edge cases are what review and testing exist to catch.
We could not load the Phoronix page directly in our fetch tool, so details here rest on Startup Fortune and Pillitteri's write-ups plus the quoted cover-letter lines. Check the branch on kernel.org and the mailing-list thread for the authoritative text.
Bottom line
The headline "Torvalds used AI" matters less than the specifics. A narrow, measurable kernel optimization was produced with Claude Code, by a maintainer who disclosed it, ran the benchmarks himself and still has to get the series past review. If the gain holds on other machines and the patch lands in 7.4, it becomes the strongest public data point that agent-assisted work can meet the kernel's bar. If review turns up problems, that will be just as informative. We will update this post when the thread moves. For the coding-agent landscape that this sits in, see our look at Claude Haiku 5.5's pricing cut, which shows how cheap running an agent on routine work is becoming.
Related reading
- Linus Torvalds on AI: "I use it for the things I'm bad at"
- Google freezes its OSS bug bounty over AI slop reports
- COSMIC desktop bans AI-generated code
- Should developers stop reviewing AI-generated code?
- ts-rust: an LLM-written Rust port of the TypeScript compiler
- DHH's Fable Rust rewrite
- Claude Code rm -rf incident and sandboxing
Details are accurate as of October 12, 2026 and may change as the patch is reviewed.