Linus Torvalds has spent decades reviewing code that ends up running on servers, phones, laptops, and a lot of devices we never think about. So when he put an experimental Linux kernel branch online and openly credited Claude Code for much of the work, people noticed. The branch had an unusually direct name, noref-filemap-read-with-llm, and it came with benchmark numbers that were hard to ignore. In one test, the kernel handled roughly three times as many tiny cached-file reads per second.
The natural reaction was to turn this into another argument about whether AI can replace programmers. I think that misses the more useful part of the story. Torvalds described what he directed the tool to do, published code that other developers can inspect, measured it on his own laptop, and listed problems that still needed attention. The result is a rare public example of an experienced engineer using a coding agent on difficult systems code without pretending that generated code is automatically ready to ship.
There is also a catch. This was a very narrow benchmark, the patch series was experimental when it appeared in October 2026, and at least one test case became slower. A threefold gain in a selected workload is worth studying. It does not mean your Linux laptop, website, or database suddenly runs three times faster.
Access without medium partner: Claude Code on the Linux Kernel
What Torvalds Actually Published
On October 10, 2026, Torvalds committed an experimental change titled mm: read from the page cache without folio references. It appeared on the noref-filemap-read-with-llm branch in his Linux tree. Reports from Phoronix and It's FOSS described an eight-patch series aimed at a bottleneck in the page-cache read path. The work had not entered the mainline Linux kernel when the story broke on October 11 and 12.
The most talked-about part was his credit to Claude Code. In the commit explanation, Torvalds said the code, test programs, review behind the issues list, and first draft of the text had been prepared with Claude Code under his direction. He also said the measurements were run on his machine. That distinction is worth keeping. It tells us the assistant had a broad role in preparing the patch, but it doesn’t establish how many prompts Torvalds used or which parts he personally changed afterward.
And no, this was not a case of asking a chatbot to build a new operating system from scratch. The problem was already understood. Matthew Wilcox had raised the underlying page-cache contention issue in 2024 after a customer workload exposed it. The branch tried a specific way to remove unnecessary reference-count operations from a common read path.
A useful starting point is the original commit mirror, which contains the technical explanation and performance measurements. Anyone interested in this story should read that before accepting the short social-media version. The kernel source is public, and its actual details are more interesting than the headline.
Why Tiny File Reads Can Become Surprisingly Expensive
Linux keeps recently accessed file contents in memory through the page cache. If an application requests data that’s already cached, the operating system can often serve it without waiting for a storage device. You would expect that to be cheap, and in many situations it is. The problem arrives when several CPU threads repeatedly read tiny pieces of the same cached file.
The existing path may take a reference to a memory object called a folio, then release that reference after copying the requested data. A folio is a unit of memory management used by the kernel; for this discussion, think of it as the object holding cached file data and related bookkeeping. Reference counts help the kernel know when objects are safe to release. They are important for correctness, but changing a shared count requires coordinated writes.
Now put eight busy threads on the same file. They all try to update a count connected to the same cached memory. Even if each thread only wants 16 bytes of data, the processor cores can spend time passing ownership of the cache line containing that count between themselves. This is called cache-line contention. The file content might already be in fast memory, but the bookkeeping still creates a bottleneck.
It’s a strange performance problem because the actual job is tiny. Read 16 bytes. Copy them to the application. Repeat. But the metadata changes around those reads can become more expensive than the data transfer itself. If you’ve worked with multithreaded code, you’ve probably seen a version of this: more threads are added, and performance gets worse because everyone needs the same lock or shared counter.
In his commit message, Torvalds described a test on an Intel Core i7–8565U laptop with four cores and eight threads. Eight threads repeatedly performed 16-byte pread() operations against one cached page. He reported that the folio's reference-count cache line accounted for 99.92% of the load HITM events in that setup. HITM, meaning Hit Modified, is a useful signal of cores fighting over modified cache lines. That's much more specific than saying Linux had a vague memory problem.
So the work targeted those repeated reference updates. The idea was to let the reader access cached data while relying on an existing kernel mechanism to keep the memory safe for the duration of the operation. That gets us into the part where the code has to be correct, not just fast.
The Fix Uses an Old Linux Idea: RCU
The experimental patch uses Read-Copy-Update (RCU), a technique already used across Linux for coordinating readers and updates. RCU lets certain read operations proceed with very little coordination while delaying the reclamation of memory until readers that could still access it have finished. It is useful in read-heavy code, but getting the lifetime rules right is serious work.
In this case, the patch argument is that a folio removed from the page cache does not immediately go back to the page allocator. It waits until an RCU grace period has passed. A reader holding the appropriate RCU protection can therefore find a cached page and copy data from it without taking the usual folio reference for that path. The commit also discusses preventing page faults during the copy to the userspace buffer, because faulting at the wrong point could break the safety assumptions.
That sounds simple when condensed to two sentences. The awkward part is everything around it: what happens if the page is removed, if a read overlaps a change, if the destination address is unsuitable, or if another kernel path needs different treatment? A small change inside the memory-management subsystem can create bugs that take months to show up. Tests that repeatedly read 16 bytes from one page won’t cover every possible file operation.
The patch description says the new approach avoids the folio reference, an on-stack bounce buffer, a sequence counter, and a check after the copy in the targeted path. Those are concrete engineering choices. They also explain why the speed improvement is plausible: the code removes work that every small read used to perform. The risky question is whether the lifetime and fault-handling rules remain correct everywhere the new path runs.
I would be far more interested in the patch’s behavior under concurrent truncation, file invalidation, and memory pressure than in another screenshot of an AI assistant writing C code. That’s where systems programming tends to get unpleasant. The easy benchmark is the part you can run before lunch; the bad race condition is the part that shows up later in production.
What the Benchmarks Say, and What They Don’t
Torvalds’s reported numbers came from a narrow workload on one laptop. With eight threads performing 16-byte reads of the same cached page, throughput went from roughly 10 million reads per second to around 30–33 million. His reported kernel cycles per read dropped from about 2,950 to about 725. Those two figures do not need to scale by the same factor because throughput and per-operation cycle measurements describe different parts of performance.
Another number is even more revealing. The load HITM count reportedly fell from 30,538 to 101. If the measurement setup is comparable between runs, that supports the claim that the patch removed much of the cache-line contention it was designed to address. It doesn’t prove that every possible read pattern is faster, but it provides a sensible explanation for this particular improvement.
Here is the detail I wouldn’t leave out of an article about the result: a single-thread case involving an unmapped page became slower, with a reported cost rising from about 4,150 cycles to about 6,550. That is a real tradeoff in the available numbers. It may be acceptable if the gain on contended reads matters more, or it may lead maintainers to change the implementation. We don’t know from one laptop benchmark which side wins across actual Linux workloads.
There are other limits. The test uses tiny repeated reads from one page, which is almost designed to expose the old bottleneck. A desktop application loading photos, a database fetching many pages, and a server reading different files may behave differently. Disk I/O can dominate some workloads. Memory bandwidth, the file layout, CPU topology, and how many threads touch the same object can all change the outcome.
Even the release status matters. The eight-patch series was in an experimental branch, not a merged mainline update. A kernel patch can go through review, revisions, benchmark requests, and more testing before anyone decides it belongs in a release. Sometimes an idea that wins a microbenchmark fails a wider regression test. Sometimes it survives and becomes normal kernel behavior years later.
So the correct claim as of October 13 is fairly narrow: Torvalds reported a roughly threefold throughput improvement in a specific small-read test using an experimental branch built with Claude Code assistance. Claims that Claude made Linux three times faster leave out most of the story.
The Interesting Part Is How Claude Code Was Used
The tool wasn’t just completing a function. According to Torvalds’s own credit, Claude Code helped write implementation code, create tests, review the work against a known-issues list, and draft the description. That’s a wider job than the autocomplete tools developers were using a few years ago. It looks more like delegating a bounded engineering task to an assistant and then checking the result.
The phrase under my direction does a lot of work here. Torvalds knew the subsystem, understood the existing problem, had a plausible design to explore, and could run meaningful measurements. Those things don’t appear automatically because an AI agent can produce C code. A new developer might ask for the same feature and get something that compiles without understanding whether it keeps page-cache memory safe.
That distinction matters for all the teams discussing AI productivity. Counting how many lines the assistant produced is a poor way to measure what happened. The difficult part may be choosing a useful problem, deciding which invariants must hold, checking benchmark methodology, and knowing what needs review. Code generation can save time, but accepting wrong code in a kernel is not the sort of shortcut anyone wants.
I also think this experiment makes the argument over whether AI-generated code is real engineering feel a bit tired. Engineers have always used tools that automate parts of their work. The question is whether the tool helps them build something correct, understandable, and maintainable. Claude Code can suggest a patch. It cannot make the Linux maintainers’ responsibility disappear.
There is a practical lesson for ordinary software projects here. If you give a coding agent a tight problem, an existing codebase, a test target, and a clear definition of success, its output is easier to check. If you ask it to make the app faster without saying which operation is slow, you may get a pile of changes and a performance claim nobody can reproduce.
Then Torvalds Used AI on Some Old, Hard-to-Read Code
A separate story appeared on October 12, and I find it just as useful. Phoronix reported an assoc-array-fixes tag in Torvalds's Linux tree. The work concerned the kernel's associative-array library and a bug reported by Nils Ollrogge. Torvalds said the original patch was hard for him to follow, so he used modern LLM tools to make sense of the code and help split difficult functions into more readable pieces.
The resulting user-space test setup confirmed Ollrogge’s bug and found three more problems that dated back to the library’s introduction in 2013. That’s a more relatable use for AI than a dramatic speedup graph. Real codebases contain old functions that work most of the time, but are difficult to inspect when a bug appears. Making code easier to reason about can expose errors that had been sitting unnoticed for years.
We need to keep the two stories separate, though. The page-cache patch explicitly credits Claude Code. The separate associative-array work credits modern LLM tools without clearly identifying Claude Code as the one used there. Saying Claude Code found all four bugs would go beyond what the published account supports. Ollrogge also deserves credit for finding and reporting the original issue.
And there is a bigger reason this example interests me. The AI’s contribution was connected to making the code readable enough to test, not just generating a replacement function. A test harness then uncovered failures. That is a workflow a normal developer can borrow without pretending to be Linus Torvalds: understand the old code, make controlled changes, build a reproducible test, and see what breaks.
This Doesn’t Mean Torvalds Has Dropped His Warnings About AI
In October 2026, Torvalds also spoke publicly about AI coding at Open Source Summit Europe. Reporting on his comments describes a mixed view. He sees AI as a useful entry point for newcomers and a tool that can help people explore programming, but he has warned about relying on it for serious development without understanding the goals and consequences.
That fits the two kernel examples rather well. In neither story do we see a claim that an assistant’s output should be trusted just because it was generated quickly. We see a maintainer using AI to investigate, generate, and test changes within a technical process that still requires review.
Open-source maintainers have another problem to deal with. AI tools make it cheap to produce patch proposals and bug reports, including low-quality ones. People receiving those submissions still have to spend time checking them. A tool can reduce effort for the person pressing Enter while increasing effort for the reviewer who has to prove whether the result is safe.
This is the uncomfortable side of the whole discussion. The same tool that helps an expert explore a hard memory-management idea can help someone flood a project with confident but broken reports. It’s not an argument for ignoring AI, but it is a reason to care about authorship, test evidence, and accountability. The maintainer still needs to know who did what and what was checked.
The kernel community will judge this patch on its technical merits. That’s the right standard. If the code is safe and produces repeatable gains without unacceptable regressions, its development history may become a useful case study. If review finds problems, that will also be valuable information about where agent-generated systems code needs stronger checks.
What Developers Can Take From This Experiment
The first useful idea is to start with a measurement, not a prompt. Torvalds’s work targeted a known performance complaint, and the commit explained the exact source of contention. The eight-thread pread() test gave the patch a clear job: reduce expensive shared reference-count updates. Even when the benchmark is narrow, it gives reviewers something concrete to question and reproduce.
The next idea is to ask the agent for tests and explanations along with implementation. Those artifacts can be wrong too, so they require human review, but they make the output easier to inspect. You want a change that says what it assumes and why, not a mysterious patch accompanied by a cheerful message that everything is complete. In the kernel example, the known-issues list matters just as much as the headline benchmark.
And treat regression results as part of the result. If the single-thread unmapped-page test loses performance, put that number next to the faster eight-thread case. Don’t hide it in a footnote. Engineers need to decide whether a trade is suitable for the code they maintain, and that decision becomes impossible when only the best benchmark survives into the write-up.
For ordinary projects, the equivalent might be using a coding agent to reduce latency on one database endpoint. First capture request traces. Have the agent suggest a change and write a repeatable load test. Test the endpoint when traffic is light and heavy. Then inspect how the change affects errors, CPU use, and other queries. If the improvement vanishes outside the synthetic test, you have learned something useful before shipping a regression.
I would also avoid copying Torvalds’s workflow as if his expertise were part of the software license. A kernel maintainer can spot problems that most of us won’t recognize. We should borrow the careful measurement and review, not assume we can safely delegate unfamiliar low-level code just because someone famous got a promising result.
What Happens Next Matters More Than the Headlines
The branch was still experimental when the reports appeared. Reviewers may find missing cases, suggest a different approach, or ask for tests on more processors and real workloads. The measured threefold gain is a reason to investigate the idea, not proof that Linux has received a universal performance upgrade. As of this article’s date, there is no basis to write as though the patch has already been merged into a stable release.
And that leaves us with a more useful story than AI wrote Linux. Torvalds used Claude Code as part of an engineering process on a difficult subsystem, disclosed the tool’s role, measured the result, and left the code open for other people to challenge. In separate work, AI-assisted cleanup and testing helped expose bugs in code that had been around since 2013.
If I were following this story, the next thing I’d watch wouldn’t be a new AI marketing demo. I’d watch the kernel review discussion: what breaks, what gets rewritten, and whether independent benchmarks confirm the speedup. That’s where we find out how much of this experiment survives contact with the rest of Linux.