A laptop with four cores, eight patches, and a line in a cover letter that made the kernel community sit up: “Tools: Claude Code.” With that simple sentence, Linus Torvalds revealed on October 10, 2026, that an AI coding agent helped build a memory-management patch series for the Linux kernel. Linux kernel AI is no longer an abstract future question — it is a concrete, inspectable branch in the kernel creator’s own repository, complete with benchmark data, open questions, and a clearly named trade-off.
The branch is called “noref-filemap-read-with-llm” and reaches deep into how the kernel reads data from the page cache. It was spotted by Phoronix editor Michael Larabel, who made the release public. For developers, systems programmers, and anyone following the technical future of the kernel, this case tells two stories at once: one about performance optimization in the page cache, and one about the use of AI agents in one of the world’s most scrutinized software projects.
Table of Contents
Key Takeaways
- On October 10, 2026, Linus Torvalds published the branch “noref-filemap-read-with-llm” with eight patches touching the Linux kernel’s
filemap_readfunction. - The patch series reduces contention from many simultaneous small reads on the same file, measured on Torvalds’ own laptop (Intel Core i7-8565U).
- Kernel cycles per read with 8 threads dropped from roughly 2,950 to roughly 725, and throughput roughly tripled.
- Torvalds explicitly names a safety valve against memory pressure, as well as a regression for unmapped page faults.
- In the cover letter, Torvalds confirms that the code, the test programs, the review work behind the list of open issues, and the first draft of the text itself were produced with Anthropic’s Claude Code — a new step for the Linux kernel AI story.
What is “noref-filemap-read-with-llm”?
The branch is based on Linux 7.3-rc6 and lives in Linus Torvalds’ personal Git repository. The name already hints at the core idea: “noref” stands for skipping classic reference counting on read, “filemap-read” points to the affected kernel function filemap_read, and “with-llm” makes it transparent that a language model took part in the development process.
The eight patches change how the kernel delivers data from the page cache to reading processes. The underlying problem isn’t new: Matthew Wilcox reported it back in 2024, triggered by a real customer workload in which many threads simultaneously read small amounts of data from the same file.
The technical problem: contention in the page cache
When multiple threads read from the same file at once, the kernel must ensure the underlying memory page (folio) doesn’t disappear mid-read. Classically, this happens via atomic reference-counting operations like lock cmpxchg and lock decl. These operations are correct, but under heavy parallel access to the same cache line they create significant contention between CPU cores — an effect that grows disproportionately with thread count.
This is exactly the behavior Matthew Wilcox described in 2024 from a customer workload: many threads, small reads, one shared file — a pattern that shows up in practice more often than one might initially assume, for instance in heavily parallelized server applications.
The core idea behind the Linux kernel AI patch series
The central trick of the patch series is as elegant as it is risky: a folio removed from the page cache is not immediately returned to the page allocator. Instead, it waits until an RCU grace period (Read-Copy-Update) has elapsed.
“The least-solved part of the series,” is how Torvalds himself describes the fact that memory stays in the system longer before it can be reused.
During this waiting period, a reading thread can copy directly from the page cache inside an RCU read-side section, with page faults disabled — without the expensive atomic reference-counting operations. Because the RCU grace period guarantees the folio is still valid, the reader needs no lock and no counting. That’s the core of the performance gain.
Benchmark results: what the Linux kernel AI optimization really delivers
All numbers come from Torvalds’ own laptop, an Intel Core i7-8565U with four cores and eight threads, mitigations disabled. Among other tests, 8 threads performed 16-byte pread() calls on a shared file.
| Metric | Before | After | Change |
|---|---|---|---|
| Kernel cycles per read (8 threads) | ~2,950 | ~725 | significantly reduced |
| Throughput (reads/second) | 9.9-10.4 million | 30-33 million | ~3x |
| Cross-core Load-HITMs (perf c2c) | 30,538 | 101 | massively reduced |
| Cycles per read (1 thread) | 452-454 | 408-409 | ~10% cheaper |
Especially notable is the drop in cross-core Load-HITMs, measured with the profiling tool perf c2c. This value shows how often CPU cores access the same cache line and end up blocking each other. A drop from over 30,000 to just 101 events confirms that the contention has practically disappeared.
Even with a single thread — so no parallelism at all — the change brings a small but measurable benefit of around 10 percent fewer cycles per read.
Trade-off and safety valve
Giving up immediate memory release comes at a price: memory stays “pending” in the system longer before it’s available to the page allocator again. This theoretically carries the risk that too many pages pile up in the queue under memory pressure.
To mitigate this risk, two of the eight patches introduce a safety valve. The rule is simple:
- Once a CPU has accumulated more than 1,024 pages in its queue, a worker forces an accelerated RCU grace period.
- Memory is then released promptly, before bottlenecks can form.
The effectiveness of this mechanism was verified in a stress test on a 2-GiB VM. The result is unambiguous:
| Version | 1 CPU | 2 CPUs | 4 CPUs | 8 CPUs |
|---|---|---|---|---|
| 8-patch version (with safety valve) | clean | clean | clean | clean |
| 6-patch version (without safety valve) | clean | clean | OOM killer | OOM killer |
Without the safety valve, the reduced 6-patch version triggered the out-of-memory killer at 4 and 8 CPUs — clear evidence that the two extra patches aren’t a cosmetic addition but a functional necessity for stable operation under memory pressure.
The regression: a price for the speedup
No optimization without a trade-off. The new read path introduces a measurable regression in one specific scenario: when a process accesses a user page that isn’t yet mapped, that access now needs an extra failed exception before the old, familiar code path takes over.
Concretely, cycles for 16-byte single-thread reads on an unmapped page rise from about 4,150 to about 6,550. That’s a substantial increase for this specific case, but it’s a deliberate trade-off against the massive improvement for contending reads. Torvalds documents this regression openly in the cover letter instead of hiding it — a sign of the series’ factual, technically transparent character.
Linux kernel AI in the cover letter: Claude Code as a tool
The real talking point for many observers isn’t the performance number — it’s the “Tools” section of the patch series’ cover letter. There, Torvalds explicitly describes that the following work was done with Anthropic’s Claude Code, an AI coding agent, under his direction:
- the actual patch code
- the test programs used for verification
- the review work behind the list of open issues
- the first draft of the cover letter text itself
The measurements themselves still ran on Torvalds’ own machine, not inside an AI simulation. In other words: the AI was a tool in the development process, not a substitute for real-world validation of the results.
Torvalds has used AI tools for kernel debugging before. What’s new is that an entire memory-management patch series in his own tree is now credited to an AI agent as a contributor. For the Linux kernel AI story, this marks a turning point: it’s no longer just about code completion or bug hunting, but about actively shaping an architecturally demanding change to the heart of the operating system.
If you’re curious how different AI coding agents actually perform in practice, our comparison of AI coding agents is a good starting point. Human validation still remains the decisive factor. Torvalds ran the measurements himself, checked the numbers, and named the open questions transparently. Linux kernel AI in this case does not mean unsupervised automation, but a division of labor in which AI acts as a tool under human guidance — with all the opportunities and unresolved questions such an early step inevitably brings.
Status: not merged yet
Despite the impressive numbers, the branch “noref-filemap-read-with-llm” is explicitly not a finished feature. Several caveats apply:
- The measurements come from a single laptop, not from a broad test environment.
- Torvalds himself names open design questions, such as whether a better RCU hook exists for this use case.
- Also unclear are the costs of the inter-processor interrupts (IPIs) from
synchronize_rcu_expedited(), which are needed for the accelerated grace period in the safety valve.
The branch therefore serves as a discussion basis for the kernel mailing list, not as a merge candidate for the next stable release. This caution is typical for the kernel’s development process, where radical changes to central subsystems like the page cache traditionally go through long maturation periods before they’re even proposed for inclusion.
What does this mean for the future of Linux kernel AI?
The “noref-filemap-read-with-llm” case shows how the role of AI agents in systems programming is shifting. Instead of just generating boilerplate code or catching syntax errors, a tool like Claude Code here takes on tasks that traditionally require deep understanding of kernel internals: writing test programs for concurrency scenarios, structured review work on a list of open issues, and even drafting technical documentation.
Human validation remains decisive. Torvalds ran the measurements himself, verified the numbers, and transparently named the open questions. Linux kernel AI, in this case, doesn’t mean automation without oversight — it means a division of labor where AI acts as a tool under human direction, with all the opportunities and unresolved questions that such an early step inevitably brings.
Conclusion and next steps
The “noref-filemap-read-with-llm” patch series delivers two relevant takeaways for the Linux community at once. First: the technical optimization itself is substantial — up to a threefold throughput gain for contending small reads is a significant advance for many parallel workloads, even though the unmapped-page regression and the open design questions around RCU grace periods still need to be resolved before a merge. Second: the open handling of using Claude Code in the development process sets a precedent for transparency on the Linux kernel AI topic.
For developers and systems programmers, it’s now worth a look at the branch itself, especially the full cover letter with its list of open issues. Anyone working with page-cache internals, RCU mechanisms, or performance profiling with perf c2c will find a concrete, well-documented case study here. Discussion on the kernel mailing list over the coming weeks should show whether the open questions about RCU hooks and IPI costs can be resolved, and whether the branch finds its way into a later kernel release.
Sources
- Official kernel commit and cover letter, kernel.org, 2026: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=noref-filemap-read-with-llm&id=4c0f3697118eb3a708ea79175f7f07c43339bfa
- HWBusters, “Linus Torvalds Uses Claude Code To Rework The Linux Page Cache, Tripling Small Read Throughput”, 2026: https://hwbusters.com/news/linus-torvalds-uses-claude-code-to-rework-the-linux-page-cache-tripling-small-read-throughput/
