Torvalds published a page-cache branch and named Claude Code in the commit

Linus Torvalds has a branch in his Linux repository, noref-filemap-read-with-llm, for a narrow kind of slowness: many threads taking small reads of one cached file. The tip, commit 4c0f3697118eb3a708ea79175f7f07c43339bfab, is dated 10 October 2026, 07:05 +0200. That commit’s tree matches its parent, so the write-up is the message and the code is the eight patches underneath, dated 8 to 10 October. He names the base as 7.3-rc6 plus fixes, commit 0c2669a9f4a1. On 12 October the repository’s master ref was a different commit, 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907. The series lives on the branch.

The message says how the work was produced. The sentence below is the commit’s, including the double space after the first period:

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.

Each of the eight patches carries an Assisted-by: LLM trailer. The tip commit, which holds that paragraph, does not.

What the reads contend on

A normal read from the page cache takes a reference on the folio and later drops it. Those updates hit the same cache line in the page structure. When many threads read a little of one file, they line up on that line. The message says Matthew Wilcox raised the issue in 2024 from a customer workload. On Torvalds’s laptop, an Intel i7-8565U with 4 cores and 8 threads, eight threads doing a 16-byte pread() of one page put 99.92% of the load HITMs on that line, he writes.

The series tries to skip the reference. A folio removed from the page cache is not given back to the page allocator until an RCU grace period has passed. A reader that finds the page under rcu_read_lock() copies it straight to the user buffer, with page faults disabled, and without a reference, a stack bounce buffer, or a check after the copy. If the fast path has to stop, for a fault, a folio that is missing or not up to date, a readahead mark, end of file, or a fatal signal, the existing reference-counted read continues from there.

He sets this against earlier attempts, including Kiryl Shutsemau’s “fast short reads” patches, which copied into a stack buffer and validated afterwards. The message says that check cannot see a page that was freed, reused and inserted again at the same index, or migration, or a read of memory that is no longer page cache at all. Deferring the free is meant to remove those cases. He calls the memory that then sits waiting for a grace period the least solved part. Two later patches try to shorten the wait when one CPU’s queue is long, and one patch stops splice from stealing page-cache folios so that fuse copies instead. The eight patches run from that deferred free, through the read path, to the expedited grace period.

His measurements

Every figure in this section is from that commit, run on his laptop. He says the machine throttles with temperature, so the comparison he wants is cost per read, not reads per second. The setup is ext4, mitigations off, CONFIG_HARDENED_USERCOPY off, a 16-byte pread() at offset 0 of a one-page file, one file descriptor per thread.

With eight threads, kernel cycles per read go from 2,937-2,975 on the base kernel to 725-726 with the series. He also lists 9.9-10.4 million reads per second against 30-33 million, with the throttle warning attached. One thread moves much less, from 452-454 cycles to 408-409. Four threads, one per core, go from 1,318-1,401 cycles to 417-438. He writes that one thread per core costs 2 to 7 percent more than a single thread, and that the eight-thread figure is two SMT siblings sharing a core. Load HITMs, from perf c2c with eight threads, go from 30,538 to 101. A machine with more CPUs, he writes, should gain more, and nothing bigger has been measured. The HITM count and some of the figures, he notes, come from earlier builds of the series.

He lists the testing as those runs, an eviction race, a partial-fault test, a hole-punch check in a small virtual machine, one gcc build, and use of the laptop. The same message says xfstests, KASAN, a 32-bit build, and any other machine were not run.

Where it stands

Michael Larabel at Phoronix, on 11 October 2026, reported the branch and wrote that we will see whether Torvalds merges it for the Linux 7.4 window. That window is Phoronix’s. The commit does not put the series on a merge schedule. The cgit pages were behind a bot check on 12 October, so the text above is from a git fetch of the branch. The commit was not on the GitHub mirror of torvalds/linux. A search for the subject found the 2025 fast-short-reads thread the message already cites, and no October 2026 mailing of this series.