A new branch has appeared in Linus Torvalds’ own Linux repository, and its description includes a sentence that kernel watchers rarely see from the project’s creator. The code, the test programs and the first draft of the cover letter were produced with Claude Code, Anthropic’s coding assistant, under Torvalds’ direction. The branch is called noref-filemap-read-with-llm, and the work is a performance change to how Linux reads cached file data.
A quiet branch in the main repository
Torvalds normally keeps the main repository simple, with the master branch and not much else. Phoronix, which tracks kernel development closely, noticed the new branch while waiting for the Linux 7.3-rc7 release. The changes sit on Torvalds’ noref-filemap-read-with-llm branch, and they are not part of any release yet. Phoronix says it is not certain whether he will merge them for the Linux 7.4 merge window, the short period when new features are accepted.
The target is a specific bottleneck. When many threads each perform small reads of the same file, they contend on the reference counting of the folio, the kernel’s unit for a chunk of cached file data. The goal of the series is to let that read path work without taking a folio reference at all.
Why counting is slow when everyone counts at once
A plain-language picture helps. When a program reads a file, Linux often serves it from the page cache, a copy of recently used file data kept in memory. To make sure the cached data is not freed or reused while a thread is looking at it, the kernel adds one to a reference counter before reading and subtracts one afterward. Those updates are atomic operations on a single shared memory location.
On a machine with many processor cores, that shared location becomes a meeting point. Each core that touches the counter has to take exclusive ownership of the memory line it sits on, then hand it to the next core. The reads themselves may be tiny, but the cost of passing the counter around grows with the number of threads. In that situation adding cores can make little difference or even slow things down. Avoiding the counter on the read path attacks the cost directly.
This is a known theme. In October 2025, Torvalds commented on an earlier proposal for fast short reads, noting that the page cache already relies on subtle techniques when it looks up folios, and that a speedup for such workloads should not be dismissed as a niche case. That message is in the public kernel mailing list archive, where he also floated freeing folios in a way that waits for readers as a possible direction. I could not open the new commit text, so I cannot say which technique the new series uses.
What the cover letter admits
The most unusual part is the disclosure. In the main patch message, Torvalds writes that the code, the test programs, the review behind the list of changes and the first draft of the text “were done with an LLM coding assistant (Claude Code) under my direction,” and that the measurements were run on his machine. The sentence does three useful things. It names the tool, it says which parts the tool did, and it states that the performance numbers came from a human-run setup, not from the assistant.
According to Phoronix, the performance chart in the series shows a large improvement for the many-threads, small-reads case. The specific figures are in a chart on the original report and in the commit, and I have not reproduced them here because I could not read them directly. Treat any number from this series as one developer’s measurements on one machine until others repeat them.
Not a first for Torvalds
This is the latest in a visible run of AI use by the kernel’s maintainer. In July, he told a mailing list that the Linux kernel is not anti-AI, calling AI a tool like others and saying the question of usefulness is settled, while also saying it can be painful for maintainers because it keeps finding embarrassing bugs. In August, he described a debugging session on an Intel graphics driver as “enormously helped” by an AI that did much of the grunt work, ending in a one-line change after 24 debug patches and 18 boots. And on October 12, Phoronix reported that he used modern LLM tools to make sense of obscure associative-array code, splitting hard-to-read functions and running them through a user-space test harness that confirmed a reported bug and found three more, all dating from the library’s first commit in 2013.
The pattern is consistent. He uses AI for the work that is slow for a human, such as debugging, test harnesses and drafting, and keeps the judgment and the final merge decision for himself.
Why reviewers will still read every line
Disclosure does not replace review. Kernel code lives or dies on correctness in rare conditions, and changes to memory management are among the most delicate. A reference count exists because something could otherwise free memory at the wrong moment. Any series that removes it from a hot path will draw close attention from memory-management maintainers, whatever tool wrote the first draft. Torvalds has said that the kernel judges changes on technical merit, and the same standard applies here.
There is also a fair caution on the other side. Claude Code is made by Anthropic, the same company whose models wrote this article, so readers should weigh this report with that in mind. The facts about the branch and the cover letter come from public kernel records and from Phoronix, not from Anthropic.
What to watch before the 7.4 merge window
Three things will settle how important this change is. First, whether the memory-management maintainers accept the approach and the tests, and whether they ask for changes. Second, whether other people reproduce the speedup on different hardware, since contention results vary a lot between machines. Third, whether Torvalds merges the branch for 7.4 or leaves it for another cycle. For most Linux users the effect will be invisible, because the workload is narrow. For the servers and databases that read hot files from many threads, it could be worth having.
