WHAT ACTUALLY HAPPENED
● Torvalds committed eight patches on 10 October — "mm: read from the page cache without folio references" — written with Claude Code under his direction.
● Roughly 3x on one workload. Eight threads reading 16 bytes from the same cached file went from ~10M reads/sec to 30–33M.
● Single-threaded gained almost nothing — about 8M to just under 9M. This fixes contention, not reading.
● Not merged. Experimental branch, based on 7.3-rc6, with open problems Torvalds lists himself.
On 10 October Linus Torvalds pushed a branch called noref-filemap-read-with-llm — the name is not subtle — containing eight patches that change how the Linux kernel reads from the page cache. The commit message says the code, the tests, the review and the first draft of the message itself were produced with Anthropic's Claude Code, under his direction, and that he ran the measurements personally.
The technical change
When several threads read the same cached file, each read takes a reference on the folio holding that page. Those reference counter updates hit the same cache line, and at sufficient concurrency the counter becomes the bottleneck rather than the data.
The patches use the kernel's Read-Copy-Update mechanism so that certain reads can skip taking the reference at all. Fewer atomic operations on a contended line, more throughput — provided nothing frees the page underneath you, which is what RCU is there to guarantee.
The measurements
Run on Torvalds's own laptop — an Intel Core i7-8565U, ext4, with some security mitigations disabled:
| Workload | Before | After |
|---|
| 8 threads, 16-byte reads, same cached file | ~10M reads/sec | 30–33M reads/sec |
| 4 threads on separate cores | 9–12M reads/sec | 25–26M reads/sec |
| Single thread | ~8M reads/sec | ~9M reads/sec |
The single-threaded row is the most informative one. A change that triples contended throughput and moves uncontended throughput by about 10% is a contention fix, precisely as designed. Anyone quoting "3x faster Linux file reads" has read the first row and stopped.
What Torvalds himself says is unresolved
He lists the open problems in the commit rather than leaving them for reviewers to find: memory allocation behaviour, compatibility concerns, possible regressions, and the cost of delaying memory reuse. The patches also add overhead in some paths — notably when a read misses and the page is not resident.
They sit on an experimental branch based on Linux 7.3-rc6 with additional fixes. They are not in mainline, and nothing here suggests AI-written code is being merged without review.
WHY THIS ONE MATTERS MORE THAN THE BENCHMARK
Kernel memory management is about as unforgiving as production code gets — decades of accumulated invariants, failure modes that surface as data loss, and a maintainer famously hard to impress. The interesting fact is not that the patches are fast. It is the working arrangement: the model wrote and tested, the human directed, scoped and verified, and the human put his name on the result along with a list of what is still wrong with it. That is a more useful template than any benchmark.
What to take from it if you write code
The direction mattered more than the generation. Torvalds knew which bottleneck to attack and which mechanism could legitimately remove it. The model did the work inside a problem that was already well posed.
He measured it himself. Not the model's reported numbers — his own, on his own hardware, with the configuration stated. That step is doing more work here than it is given credit for.
He published the failure list. The open problems appear in the commit message, not in a follow-up after someone caught them. For AI-assisted contributions to systems code, that norm matters more than the speedup.
Sources
Linuxiac — Torvalds experiments with AI-generated kernel code