senn-techsenn-tech
KI & Entwicklung
KI & Entwicklung2026-10-16· By Franz Senn

Torvalds has Claude Code rework the page-cache read path: what the numbers show and what they do not

On 10 and 11 October 2026 Linus Torvalds created a branch in his repository torvalds/linux.git, where he otherwise keeps only master. The branch is called noref-filemap-read-with-llm. Phoronix reported it on 11 October, and Linuxiac on 12 October with the measurements from the commit message. This post rests on those reports. We did not read the commit message or the branch itself, and there are no measurements of our own.

What the patches change

The series is titled "mm: read from the page cache without folio references". According to Linuxiac it is eight experimental patches based on Linux 7.3-rc6. They use the Read-Copy-Update mechanism so that certain reads can do without a reference counter on the memory page (folio). The background: when many threads read small pieces of the same file from the page cache, they all raise and lower the same counter. The counter becomes the bottleneck and the reading itself does not.

On the role of the AI, Torvalds writes in the commit message, according to Phoronix and Linuxiac, that the code, test programs, review and the first draft of the text were produced with an LLM coding assistant, Claude Code, under his direction, and that the measurements ran on his machine.

What was measured

Linuxiac gives the values from the commit message: a laptop with an Intel Core i7-8565U (4 cores, 8 threads), ext4, some kernel mitigations switched off.

Reads per second on an i7-8565U, in millions8 threads, before108 threads, after31.54 threads, before10.54 threads, after25.51 thread, before81 thread, after9035
Values from the commit message after Linuxiac. Ranges are given (8 threads: about 10 to 30 to 33, 4 threads: 9 to 12 to 25 to 26) and the chart shows their middle. Single thread: about 8 to just under 9. All values come from Torvalds' own machine. (Quelle: Linuxiac, 12 Oct 2026, after the commit message)

With eight threads each reading 16 bytes from the same cached file, throughput rises from about 10 million to 30 to 33 million reads per second, roughly three times. With four threads on separate cores it goes from 9 to 12 up to 25 to 26 million. A single thread gains little, from 8 to just under 9 million.

What is missing

According to Linuxiac the commit message lists open points: behaviour of memory allocation, compatibility, possible regressions and the cost of delaying later reuse of memory. In some cases the patches can add overhead, above all when reading missing pages. Measurement was on a single, older machine, not on servers with many cores and not with other file systems.

A report by The New Stack of 14 October carries a headline saying reviewers found a race condition in the code. We could not retrieve the article text, so we give the headline only as a claim. Anyone who needs the statement reads the report in the original.

From experiment to kernelExperimental brancheight patches, based on7.3-rc6Measurement on alaptopTorvalds, i7-8565UReview by maintainersa race found according tothe headlineClear the open pointsmemory, compatibility,regressionsMerge windowunclear whether 7.4
Five steps from branch to mainline. Only the first two are documented, the rest is open. (Quelle: Phoronix, Linuxiac, The New Stack (headline))

What operators and developers take from it

  1. The number "three times" applies to a microbenchmark with heavy contention on the same counter. Anyone running databases or web servers cannot derive the effect from it. A statement about production load needs measurement on your own load.
  2. What matters is the handling of the AI share. Torvalds discloses what the AI wrote, what he measured and which points are open. That is the pattern against which AI-assisted changes in your own company can be judged: who reviewed, on which hardware was it measured, what is unresolved.
  3. A race that only a reviewer finds shows where the effort lies. AI lowers the effort of writing a first draft. Checking the draft remains work for people who understand concurrency.
  4. Experiments in the kernel reach distributions only after merge and testing. Nothing needs doing on servers at the moment.

What forums say

The Phoronix report stands on Hacker News with 32 points and with 5 points and at most 2 comments, and the Startup Fortune piece has 17 points and 12 comments (thread). We found no technical discussion of the patches there. The assessment of the code happens on the kernel mailing list, which we did not read.

How we checked

On 16 October 2026 we read the Phoronix and Linuxiac reports. Phoronix gives no numbers in the text, only a chart, so the measurements come from Linuxiac. The New Stack article was not readable and the headline is the only information from it. We did not check the commit message and the branch.

Further reading

Reports

Community

Questions?
Is the code in the Linux kernel?+

No. It is an experimental branch named noref-filemap-read-with-llm in Torvalds' repository. Phoronix writes that it is open whether it lands in the merge window for Linux 7.4. Inclusion in the mainline is not documented.

Does three times faster mean Linux gets three times faster?+

No. A narrow case was measured: many threads read small pieces of the same cached file, on an older laptop with kernel mitigations switched off. With a single thread the gain is small, and in some cases the patches add cost, for example when reading missing pages.

Did the AI write the code on its own?+

Torvalds writes in the commit message that the code, test programs, review and the first draft of the text were produced with Claude Code under his direction. He says he ran the measurements on his machine. A New Stack report says in its headline that reviewers found a race condition. We could not read the article text.