A branch that says who wrote it
A branch called noref-filemap-read-with-llm appeared in Linus Torvalds’ own kernel tree last weekend. It holds eight patches, all authored and committed by Torvalds between 9 and 10 October, on top of 7.3-rc6. The last of them is an empty commit that carries nothing but the explanation, and near the end of that text, under a heading reading “Tools”, is a paragraph few kernel commits contain:
“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.”
Phoronix, which found the branch while waiting for 7.3-rc7, noted that Torvalds rarely keeps working branches in his main repository at all. The eight commits are not in master, and he has not said whether they will go into the 7.4 merge window.
The problem is one cache line
The series attacks a contention problem that Matthew Wilcox raised in 2024 from a customer workload. When many threads read small amounts from the same file, every read takes and drops a reference on the folio holding the page, so each one writes the same struct page cache line twice. On Torvalds’ laptop — an i7-8565U with four cores and eight threads — eight threads doing 16-byte pread() calls on a single page put 99.92% of the load HITMs on that one line.
His fix is to stop taking the reference at all. A folio removed from the page cache now goes back to the page allocator only after an RCU grace period, which means a page found under rcu_read_lock() still holds that file’s data until the lock is dropped. The read then copies straight into the user buffer with page faults disabled: no reference, no stack bounce buffer, no check after the copy, no size limit.
Earlier attempts, Torvalds writes, copied without a reference into a stack buffer and validated afterwards, and “stopped at what the validation cannot see” — free, reuse and re-insert at the same index, migration, and reading memory that is no longer page cache at all, including secretmem, unaccepted memory and “even worse MMIO with undesired read-effects”. Deferring the free removes those cases rather than detecting them.
Three times the reads, and 30,538 HITMs down to 101
The numbers in the commit message are from one machine, running ext4 with CPU mitigations and CONFIG_HARDENED_USERCOPY off. With eight threads doing 16-byte reads of one page, the baseline kernel manages 9.9 to 10.4 million reads a second at 2,937–2,975 kernel cycles per read. With the series it manages 30 to 33 million at 725–726 cycles. Four threads, one per core, go from 8.9–11.6 million to 25–26 million. Load HITMs measured with perf c2c fall from 30,538 to 101.
The cost is memory sitting in a queue waiting for a grace period, which is the part Torvalds calls least solved. Wilcox’s objection to deferring the free, quoted in the message, was that “it just feels too risky to have so much memory waiting to be reused”. Patches 7 and 8 exist to contain that: above 1,024 pages pending on a CPU, a second work item calls synchronize_rcu_expedited() and frees the list, which under four hole-punching processes runs 4,600 times a second — something that function’s own documentation says not to do in a loop. Torvalds flags it himself: “Is there a way to get a short grace period without them?”
What he says he has not tested
The message closes with a list of what the series has not been run against: memory pressure beyond one reproducer in a VM, lockdep, KASAN, a kernel built with clang, 32-bit, CONFIG_HARDENED_USERCOPY, and “any machine but this one”. On the scheduler change in patch 8 he writes, “I am not sure this is the direction; I would rather have the freeing task do something synchronous that leaves the scheduler alone.”
That is the part worth watching rather than the tooling. Torvalds has published a performance-critical memory-management series, attributed the code to an assistant, kept the measurements to himself, and asked the subsystem maintainers two open questions. Whether it survives review on the mailing list is a separate test from whether it ran fast on his laptop.
