Linus Torvalds has posted his first patch series written with help from a large language model, a 10-patch fix for a long-running Linux page-cache bottleneck, and kernel reviewers have already found a race condition in it, LWN reported on Wednesday, October 14.
The tool was Anthropic’s Claude Code. Per The New Stack, Torvalds said the assistant wrote the implementation, tests and initial documentation, and reviewed the code under his direction. He ran the benchmarks himself.
It’s the most credible stress test of AI-assisted coding we’ve seen this year: the author is the person who wrote the kernel, the code sits in one of its hottest paths, and the reviewers are famously unimpressed by anyone.
How it surfaced
Torvalds didn’t announce it with a press release. On Sunday, October 11, Phoronix’s Michael Larabel spotted an experimental branch named noref-filemap-read-with-llm in Torvalds’ kernel tree, which rarely carries anything besides the main development line. That first eight-patch branch, based on Linux 7.3-rc6, carried a top commit dated October 10, according to WebProNews.
On Tuesday, October 13, Torvalds posted a revised 10-patch series, rcu-free-v3, to the kernel mailing list. He noted, dryly, that “the commit messages are a bit more verbose than I would have done it myself without tool use, but maybe it’s better that way.”
The problem being fixed
When many CPU cores read the same cached file data, they fight over a reference count on the “folio,” the kernel’s unit of cached memory. Every reader bumps the counter up and back down, and the cache line holding it bounces between cores like a hot potato.
On Torvalds’ laptop, an Intel Core i7-8565U with four cores and eight threads, eight threads doing tiny 16-byte reads on one page sent 99.92% of load HITMs (a measure of cores fighting over the same cache line) to the line holding that reference count. Oracle’s Matthew Wilcox had flagged the contention in 2024, from a customer workload.
This wasn’t a new itch. The New Stack reports Torvalds had spent 18 months running a broken version of his own earlier fix, and other developers had hit problems with their approaches.
Torvalds’ own description of the new series, from his mailing-list post, is that it notices when folios are “hot,” delays freeing them until after an RCU grace period, and then reads the folio data itself under RCU protection. “No refcount taking needed for the fastpath,” he wrote.
In plainer English: RCU (read-copy-update) is a kernel technique that lets readers proceed without locks, as long as nobody frees memory out from under them until they’re done. By delaying the free, readers can skip the shared counter entirely for the common case, which is where the traffic jam was.
The numbers
The New Stack reported these results:
- Laptop, first 8-patch branch: 8-thread reads went from 10 million to as many as 33 million per second.
- 64-thread Threadripper, revised 10-patch series: throughput jumped from 13.3 million to 304 million reads per second, roughly 23x, with cycles per read falling from nearly 20,000 to 735.
The catch: that’s a synthetic, contention-heavy benchmark, and Torvalds said so first. “Admittedly that is a very artificial case of reading the same small part of a page over and over in a threaded loop on all CPUs, so any real life impact will be much much less,” he wrote. The first version also had a regression for some small single-thread reads, from about 4,150 to 6,550 cycles.
Then came review
This is the part we’d frame. Kernel developer Kiryl Shutsemau found a race in filemap_read_rcu_batch() where a folio could be replaced and the file extended, potentially exposing data that had never been written. That’s the kind of bug that doesn’t crash anything; it quietly hands a program bytes it should never see. Torvalds suggested moving the file-size read earlier, and Shutsemau folded that into a revised patch.
Wilcox, meanwhile, pushed back on the design’s new PG_rcu_free page flag. “I don’t like the PG_rcu_free flag,” he wrote, while conceding that “the numbers are compelling.” Page flags are scarce real estate in the kernel, and Shutsemau suggested a 64-bit-only flag instead, arguing that “we don’t care about the scalability of 32-bit machines here.”
Reviewers also raised concerns about memory reclamation: if freed memory has to wait for an RCU grace period, how much memory sits in limbo under pressure?
Torvalds handed further development to Shutsemau, who had previously worked on the same bottleneck.
What happened next: an 18-patch rework
On October 19, Shutsemau, who works at Meta, posted an 18-patch RFC (request for comments) based on Torvalds’ code, Phoronix reported. “It is Linus’ RFC, reworked: a folio that such a reader may copy from is freed only after an RCU grace period,” his cover letter says.
The rework marks only hot folios for delayed freeing, so “streaming reads and data that never gets hot are not deferred,” frees waiting pages before the kernel reaches for the out-of-memory killer, and extends the lockless reads to large folios and to tmpfs. The core patch keeps Torvalds’ authorship and an Assisted-by: LLM tag, with Shutsemau’s fixes, including the file-size ordering, noted in brackets, per the patch on Patchew.
His benchmarks, run with 64 threads in a virtual machine on an AMD Threadripper 7975WX with default security mitigations on, per WebProNews:
- ext4: from about 15 million to about 70 million reads per second.
- tmpfs: from 1.6-1.7 million to 71-72 million.
- XFS and raw block devices: roughly doubled, held back by a shared lock taken on every read.
- Single-threaded reads: roughly unchanged. A load that keeps refaulting lost 4-6%.
It’s still an RFC with open items, including a patch that drops a lock from tmpfs reads. “I believe this is safe, but would like Hugh to double check,” Shutsemau wrote, referring to tmpfs maintainer Hugh Dickins.
Why it matters
This is about as honest a field test of AI coding as exists. Claude Code turned a hard, long-stuck idea into working code quickly, under the direction of someone who knows exactly what correct looks like. It also produced a subtle data-exposure race that only expert human review caught before merge.
Both halves of that sentence matter. The speedup is real. So is the bug. Anyone citing this story as proof that AI can now write kernel code unsupervised is skipping the second half.
It’s also a little funny. The New Stack notes Torvalds has previously criticized developers for claiming AI writes 99% of their code. Here he is, letting it write most of a patch, then handing the result to a human to fix.
The catch
- Benchmarks are best-case. Real workloads with many threads hammering one small file exist (think shared config or metadata reads), but they’re not most workloads.
- Memory trade-off. Delaying frees until an RCU grace period holds memory back. The rework limits that to hot folios, but behavior under heavy memory pressure is still under review.
- Not merged. Nothing here is in a released kernel. RFCs can change shape, stall or die.
The takeaway
Our read: AI got a hard idea into working code fast, and code review did exactly its job. That’s the healthy version of AI-assisted engineering, and a reminder that review is the expensive part nobody gets to automate away. The Assisted-by: LLM tag riding along in the commit is a quiet precedent worth noticing, too.
What to watch: whether the reworked series clears memory-management review and lands in a future kernel release, what the gains look like on real workloads, and whether more maintainers start labeling AI-assisted patches the same way.
Image: Elizabeth Krumbach Joseph / Wikimedia Commons, CC BY 2.0
