Eight patches on a new branch in Torvalds’ own tree go after a page cache bottleneck first raised in 2024, and the cover letter credits an AI coding agent for the code, the tests and the first draft.
Linus Torvalds has pushed a branch called noref-filemap-read-with-llm to his own Linux repository, and the suffix is not a joke. According to the series’ cover letter, the work was done with Claude Code, Anthropic’s command-line coding agent, and it targets a real scalability problem in the Linux page cache. On his laptop, eight threads hammering the same file now complete roughly three times as many small reads per second.
The branch was spotted by Phoronix’s Michael Larabel while he waited for Sunday’s Linux 7.3-rc7 tag. That alone was unusual. Torvalds rarely hosts topic branches in his main tree, which normally carries little more than master.
A cache line everyone fights over #
When many threads issue tiny reads against the same file, each read takes a reference on the folio backing that page and drops it again afterwards. Both steps are atomic writes to the same struct page cache line, so the line bounces from core to core. Per the commit message, Matthew Wilcox raised the issue in 2024 from a customer workload. On Torvalds’ Core i7-8565U laptop, with eight threads doing 16-byte pread() calls on one page, that single line accounted for 99.92% of the cross-core load HITMs.
Earlier attempts, including a “fast short reads” series, copied data without a reference into a stack buffer and checked it afterwards. They ran aground on cases that check cannot see: a page freed and reinserted at the same index, page migration, or memory that has stopped being page cache altogether.
Don’t free the page yet #
Torvalds takes the opposite route. Instead of detecting those races, the series removes them. A folio that leaves the page cache goes back to the page allocator only after an RCU grace period, so a reader inside an RCU read-side section can copy straight from the page into the user buffer. No reference, no bounce buffer, no limit on the size of the read.
The numbers, all from that single 4-core, 8-thread laptop with mitigations disabled:
- 8 threads, one file: kernel cycles per read fall from about 2,950 to about 725, and throughput climbs from 9.9–10.4 million to 30–33 million reads per second.
- 1 thread: 452–454 cycles drop to 408–409, roughly 10% cheaper per read.
- Contention: load HITMs measured with perf c2c drop from 30,538 to 101.
- 64 KiB reads, 8 threads, one file: around 18,000 cycles per read down to about 11,000.
The catch #
Deferring frees means memory sits around waiting to be reused, which is exactly the objection Wilcox raised when the idea surfaced before. Torvalds concedes this is “the part of this series that is least solved.” Two of the eight patches add a safety valve: once a CPU has more than 1,024 pages queued, a worker forces an expedited grace period and frees them. Folios belonging to a file that is being deleted skip the queue entirely, so removing a huge file does not flood it. In a 2 GiB VM stress test, the six-patch version let the OOM killer fire on 4 and 8 CPUs, while the full series ran to completion on 1, 2, 4 and 8.
There is a regression, too. A read into a user page that is not yet mapped now takes one extra failed exception before falling back to the old path, which pushes a 16-byte single-thread read from roughly 4,150 to 6,550 cycles.
The AI part #
The disclosure sits in a short “Tools” section near the end of the cover letter. Torvalds writes that the code, the test programs, the review behind his list of open problems and the first draft of the letter itself came from Claude Code working under his direction, while the benchmarks ran on his own machine. He has spoken before about using AI to help with kernel debugging and has played with vibe coding outside the kernel, but crediting an agent for a memory-management series in his own tree is a step further.
None of this is merged. The branch sits on top of 7.3-rc6, it has been measured on exactly one laptop, and Torvalds openly flags pieces of the design he is not sure about. He expects bigger and multi-socket machines to gain more, though he admits nothing larger has been tested. Whether it lands will come down to how the memory-management maintainers take it, and whether someone with a many-core server is willing to rerun his numbers.