Linus Torvalds Used Claude Code to Rework the Linux Page Cache: What the Benchmarks Actually Show

Detail	What it actually is
Branch	noref-filemap-read-with-llm, pushed to Torvalds' own tree on top of 7.3 rc6
Reported	October 12, 2026, by Phoronix, then Hardware Busters
Problem addressed	Cross core cache line contention from taking and dropping a folio reference on every small read
Headline result	Eight thread, single file throughput rose from about 9.9 to 10.4 million reads per second to 30 to 33 million, on one four core laptop
Tooling credited	Claude Code wrote the code, the test programs, and the review behind the open problems list, under Torvalds' direction
Status	Not merged. Acceptance depends on memory management maintainer review and reproduction on a many core server

An eight patch series sitting on top of Linux 7.3 rc6 is not, on its own, a story. A kernel maintainer crediting an AI coding agent with writing the patches, the test harness, and part of the cover letter, for a change to how the page cache handles reference counting, is a story, and the benchmarks attached to it are specific enough to take seriously rather than wave at from a distance.

What the patch series actually does

Matthew Wilcox flagged the underlying problem in 2024, from a real customer workload: every small read takes a reference on the page cache folio before copying data out, then drops it. On a machine with many cores reading the same file, those reference count increments and decrements are atomic writes that land on the same cache line, and that cache line becomes a bottleneck every core is fighting over. Earlier attempts at a fix copied data into a stack buffer and validated the copy afterward, but they stalled on races that validation could not reliably catch after the fact.

The Claude Code assisted series takes a different approach: it removes the reference entirely. A folio evicted from the page cache is only actually freed after an RCU grace period completes, which means a reader already inside an RCU read side section can copy directly from the page into the user's buffer without taking a reference first, because the data is guaranteed to stay valid for the duration of that section. That also removes the bounce buffer and, with it, a read size limit that the stack buffer approach imposed.

The benchmarks, with the caveats Torvalds himself raised

Torvalds ran the tests on a four core, eight thread Core i7 8565U laptop with CPU mitigations disabled, using 16 byte pread() calls against a single page. With eight threads reading one file, cycles per read fell from about 2,950 to about 725, and throughput rose from roughly 9.9 to 10.4 million reads per second to 30 to 33 million, close to a threefold gain. Single threaded reads improved too, but much less dramatically: cycles per read dropped from 452 to 454 down to 408 to 409, around 10 percent. The contention signal is the more striking number: perf c2c load HITMs, a measure of cross core cache line fighting, fell from 30,538 to 101, and the single cache line bottleneck the patch targets had accounted for 99.92 percent of cross core HITMs before the change.

None of that comes free. Deferring the folio's actual free until after an RCU grace period means memory sticks around longer than it used to, and Torvalds called this "the part of this series that is least solved." Two of the eight patches exist specifically to bound that risk: once a CPU has more than 1,024 pages queued for deferred freeing, a worker forces an expedited grace period rather than letting the queue grow unbounded. Under a 2 GiB VM memory pressure test, an earlier six patch version of the series triggered the OOM killer on four and eight CPU configurations; the full eight patch series completed cleanly across one, two, four, and eight CPUs. There is also a real single thread regression in one specific path: a read into a user page that is not yet mapped now incurs an extra failed exception before falling back to the slow path, and cycles for that case rose from about 4,150 to 6,550, roughly 58 percent worse for that narrow case.

Torvalds was explicit that this is one laptop's numbers, that he expects larger and multi socket machines to benefit more from removing cross core contention, and that he has not tested that claim yet. He also flagged, in his own words, parts of the design he is not fully confident in. None of that reads like marketing copy, which is itself informative: a maintainer willing to publish an AI assisted kernel series alongside its unresolved tradeoffs is treating the tool as a collaborator whose output still needs the same skepticism as a human contributor's, not as a black box that produces finished work.

What Claude Code actually contributed, and what it didn't

The cover letter's "Tools" section is specific about division of labor: Claude Code produced the code, wrote the test programs, and did the review work behind the list of open problems, all under Torvalds' direction. Torvalds ran the benchmarks himself, on his own hardware, and the judgment calls about what tradeoffs were acceptable, what needed a safety valve, and what remains unsolved are his. He had previously used AI assistance for kernel debugging; crediting an agent with a memory management series specifically is, as outside coverage noted, a further step than debugging help, because memory management correctness bugs are exactly the category of kernel work where subtle mistakes surface as data corruption or crashes under load rather than an obvious test failure.

That division, tool for implementation and test scaffolding, human for benchmarking, risk judgment, and the final call on what ships, is the pattern worth paying attention to if your own engineering org is deciding how far to extend agentic coding tools into systems level or safety critical code. It is also a useful data point against the more sweeping claims in either direction, that agents can't be trusted with anything subtle, or that they're ready to operate unsupervised on kernel internals. The honest middle, which is what actually happened here, is an experienced maintainer using the tool to accelerate a change he was equipped to evaluate rigorously, publishing the result with its rough edges intact rather than smoothed over.

When this applies to your stack

Most organizations are not patching page cache internals, but the underlying question, where does an agentic coding tool earn trust on code where a subtle mistake is expensive to detect, applies directly to infrastructure and platform engineering work: concurrency heavy services, anything touching shared mutable state across threads or processes, and code paths where a correctness bug shows up as an intermittent production incident rather than a failing unit test. The Torvalds series is a working example of the pattern that holds up: use the agent for implementation velocity and test scaffolding, keep a domain expert in the loop for the benchmarks and the tradeoff calls, and publish, or at least internally document, what remains unresolved rather than treating a green test suite as proof of correctness. If your team is scaling agentic coding tool usage into systems level or concurrency sensitive code and wants a second opinion on where the guardrails should sit, that is the kind of AI integration and agent engineering review we do for infrastructure clients.

FAQ

Is this patch series merged into Linux? No. It sits on a branch on top of 7.3 rc6, and Torvalds has said acceptance depends on review from the memory management maintainers and on someone with a many core or multi socket server reproducing the contention improvement, since his own numbers come from a single four core laptop.

Did Claude Code write the kernel patch without human review? No. Claude Code produced the code, test programs, and review work behind the open problems list under Torvalds' direction, but Torvalds ran the benchmarks himself and made the judgment calls on what tradeoffs to accept, including adding the two safety valve patches after the memory pressure test revealed a problem in an earlier version.

What is the actual downside of this change? Deferred freeing of page cache folios means memory held by recently read small files stays allocated longer, which is the tradeoff Torvalds called the least solved part of the series. There is also a measured regression for one specific case, a read into an unmapped user page, where cycle cost rose by roughly 58 percent.

Does this mean AI agents are now writing kernel memory management code unsupervised? No. The cover letter's own disclosure describes agent assisted implementation and testing under a maintainer's direction, not autonomous kernel development, and the patch is explicitly unmerged pending expert review, which is the opposite of unsupervised.

Why does cross core cache line contention matter if single threaded performance barely changes? Because production read heavy workloads on multi core servers are rarely single threaded. A 10 percent single thread improvement paired with a threefold improvement under eight way contention reflects the actual shape of the problem Wilcox originally reported: it was a many core customer workload, not a single threaded benchmark, that exposed the bottleneck in the first place.