Torvalds' Claude Code branch lets Linux page-cache reads skip the folio reference count
Linus Torvalds built an experimental Linux page-cache branch with Claude Code that cuts one contended read test to about a quarter of its CPU cost. His own cover letter flags open problems, so the series is a request for review.
The Engineer · Build desk
Key figures: roughly 75 percent of processor cost removed in Torvalds' laptop test, which shows about a quarter of the original cost; the test covers one tiny, contended read workload; the experimental branch has eight patches, a disputed count.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Laptop-test processor cost removed, roughly | 75% | 17 | |
| Workloads in the laptop test | 1 workload | tiny, contended read workload | 14 |
| Experimental branch patches | 8 patches | disputed | 19 |
What happened
- The branch noref-filemap-read-with-llm appeared in torvalds/linux.git, where Phoronix says Torvalds typically hosts only the master branch.
- It targets a contention problem: small reads of one file from many threads fight over folio reference counting.
- The change delays freeing a folio removed from the page cache until an RCU grace period, so a reader can copy data without taking the folio reference.
- The cost lands on another read path: a missing destination user page makes a read more expensive.
Why it matters
- What it limits constraint The sources put a size on the gain and none on the cost of the slower read path, so a reviewer cannot net the two from what was published.
- What it costs cost The CPU saving comes with a cost that important allocator accounting cannot see yet, and that accounting has to be fixed in review before the saving counts.
- What doesn't add up contradiction Phoronix calls the impact of the series significant, while dev.to limits the demonstrated gain to one tiny workload.
Next story · Invest · Oct 6
Meta halves internal use of Anthropic's Claude Code to about 30,000 staffConfirmed6 publishers
Today a cached read takes a reference to the folio and drops it afterwards. That pair of operations writes the same struct page line twice per read [3]. The test program is built to hit that line: several readers repeatedly ask for a tiny piece of one page [4].
The cover letter separates two guarantees. Preventing memory reuse during the protected period is not the same as keeping the reference count above zero [9]. Reclaim, migration and splitting each interact with the count in their own way [11]. Removal from the cache and recycling of the memory become separate events, and a removed page can wait before its memory goes back to the allocator [12]. When the new path cannot continue, the series falls back to the existing path [13].
A quarter of the cost is a 75 percent cut [17]. It comes from one tiny, contended read workload on Torvalds' laptop [14]. According to dev.to, no whole-system speedup is established [18]. For the number to transfer, a workload would need many threads making small reads of the same cached file, with the folio reference count as the dominant cost. The sources do not give the thread count or the core count of the test machine.
Torvalds spelled out the assistant's role in the cover letter. He wrote: "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. The measurements were run on my machine." [15] Dev.to reads that as attribution and a boundary. Torvalds directed the work and ran the measurements, and the assistant's review behind the problem list remains part of his account, with no separate independent validation [16].
The branch holds eight patches, and the commit is dated Saturday, October 10 [19]. Dev.to says the evidence establishes an experiment and a request for review, with no completed mainline merge and no shipped kernel change [7]. We agree. The sources test no other case, and in our view the design deserves review for workloads where many threads hammer one file's reference count.
What to watch
- Whether Torvalds merges the branch for the Linux 7.4 merge window, the question Phoronix raises.
- A revised series that resolves allocator accounting for memory waiting out the RCU grace period.
- Measurements for the slower read path, and runs on machines with more cores than a laptop.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence50
- Adoption3
- Hype gap+30
- Incentives35
- Confidence62
Perspective Coverage
3 publishers- Builder
- Builder 63%
- Operator
- Operator 28%
- Investor
- Investor 9%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The branch addresses a Linux issue where small reads of one file from many threads contend on folio reference counting; the goal is to read from the page cache without folio references.
- [2]
A missing destination user page makes a read more expensive.
- [3]
The existing path takes a reference to the folio and drops it afterwards; those operations update its reference count, writing the same struct page line twice per read.
- [4]
In the selected test, several readers repeatedly ask for a tiny piece of one page.
- [5]
A new branch, noref-filemap-read-with-llm, appeared in torvalds/linux.git; Phoronix says Torvalds typically hosts only the master branch in his main repository.
- [6]
The change delays the final freeing of a folio removed from the page cache until an RCU grace period, so read-side protection lets cached data be copied without acquiring the folio reference for that read.
- [7]
The evidence establishes an experiment and a request for review; it establishes no completed mainline merge or shipped kernel change.
- [8]
Waiting memory remains invisible to important allocator accounting.
- [9]
The letter distinguishes preventing memory reuse during the protected period from keeping the reference count above zero.
- [10]
Phoronix says it will see whether Torvalds merges the branch for the upcoming Linux 7.4 merge window.
- [11]
Reclaim, migration and splitting have their own interactions with the folio reference count.
- [12]
In this design, removal from the cache and recycling the underlying memory are separate events; a removed page can wait before its memory is handed back to the allocator.
- [13]
The primary cover letter describes a fallback to the existing path when the new path cannot continue.
- [14]
Torvalds' laptop test shows about a quarter of the original processor cost for one tiny, contended read workload.
- [15]
"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. The measurements were run on my machine."
- [16]
Torvalds directed the work and ran the measurements; the assistant's review behind the listed problems remains part of the author's account and supplies no separate independent validation of the series.
- [17]
Cutting a cost to about a quarter of the original removes roughly 75 percent of it.
- [18]
No whole-system speedup is established.
- [19]
The experimental branch has eight patches, and the commit is dated Saturday, October 10.
- [20]
Phoronix says the impact of the series is significant.
Sources
3 independent publishers whose own reporting we read for this story.
- dev.toClaude Code and Linus Torvalds: the Linux patch tradeoffs
3 articles · October 13, 2026
- lwn.netLinus Torvalds's first LLM-assisted patch series
1 article · October 14, 2026
- phoronix.comLinus Torvalds Working On A Hefty Linux Kernel Improvement With Claude Code
1 article · October 11, 2026
Topics and entities
Topics
- AI Coding Assistants
- Kernel memory management