Linus Torvalds posts an LLM-assisted Linux page-cache series with Claude Code

What did Linus Torvalds publish?

The dated object is a git branch, not a press release. Torvalds’ noref-filemap-read-with-llm branch tip commit 4c0f369 is authored 10 October 2026 at 07:05 +0200, titled “mm: read from the page cache without folio references.” The commit’s tree matches its parent; the write-up is the message, and the code is the eight patches underneath, dated 8–10 October, based on 7.3-rc6 plus fixes (0c2669a9f4a1).

Michael Larabel at Phoronix reported the branch on 11 October after refreshing torvalds/linux.git while waiting for 7.3-rc7, noting that Torvalds rarely hosts feature work as named branches in that tree. As of the materials we inspected, the series is not described as merged to master, and Torvalds does not put a merge window or target release in the message.

That matters for headlines. This is an experimental series with explicit known problems, not “Linux 7.4 will ship Claude-written page cache.” Anyone quoting the laptop speedups without the caveats is misreading the cover letter.

What problem does the series attack?

The bottleneck is narrow and old. When many threads take small reads from one cached file, filemap_get_read_batch takes a folio reference and filemap_read drops it, so every read writes the same struct page cache line twice. Torvalds cites Matthew Wilcox raising it in 2024 from a customer workload. On his laptop (Intel Core i7-8565U, four cores / eight threads), with eight threads doing 16-byte pread of one page, that line took 99.92% of load HITMs in perf c2c.

Earlier attempts copied without a reference into a stack buffer and validated afterwards. Torvalds says those stopped at races validation cannot see: free, reuse and re-insert at the same index; migration paths that do not use page_cache_delete; and reading memory that is no longer page cache at all—secretmem, unaccepted memory, or even MMIO with undesired read effects. Deferring the free after an RCU grace period is meant to remove those cases instead of detecting them.

Matthew’s earlier objection, quoted in the message, was that leaving so much memory waiting to be reused “just feels too risky.” Patches 7 and 8, and “problem 1” in the known-problems list, are Torvalds’ attempt to bound that risk. For kernel context on how AI has already entered Linux review culture, see our coverage of LPC 2026’s Sashiko/Boro kernel review discussion.

How does the no-reference read path work?

The design decision is to defer the final free, not the removal and not the reference. A folio removed from the page cache is marked PG_rcu_free where it leaves i_pages; __free_pages_prepare queues it and returns false, so whoever drops the last reference does not need to know. The guarantee Torvalds states is “the memory is not reused,” not “the refcount stays above zero.” Reclaim, migration and split still freeze the count under a reader; the lockless lookup protocol is unchanged.

Queueing is per CPU: a pending list and one batch whose grace period is in flight via queue_rcu_work on a WQ_MEM_RECLAIM workqueue. A per-CPU irqsave spinlock makes cutting pending into the batch and starting the grace period one step. Above 1,024 pages on a CPU’s pending list, a second work item takes the list, calls synchronize_rcu_expedited and frees it; removal loops reschedule when the scheduler has asked, so the work can run.

The fast read path, per page under rcu_read_lock, does xas_load, uptodate checks, readahead mark, dropbehind, i_size and copy with page faults disabled, using plain copy_page_to_iter. It never reads folio_size or other head fields a split rewrites. FOLIO_BATCH_SIZE pages run per RCU section; any reason to stop falls back to the existing path. Not deferred: folios of an inode with I_FREEING, so removing a big file does not shove all of it through the lists; also not covered: hugetlb and the swap cache.

What numbers did Torvalds measure?

All performance numbers are from Torvalds’ laptop, ext4, with mitigations and CONFIG_HARDENED_USERCOPY off. He warns the laptop throttles on temperature, so compare cost per read, not absolute reads per second. For 16-byte pread at offset 0 of a one-page file, one fd per thread, the message’s table shows roughly: base one thread about 7.9–8.1 million reads/s; base eight threads about 9.9–10.4 million; series one thread about 8.8–8.9 million; series eight threads about 30–33 million; series four threads one-per-core about 25–26 million.

Load HITMs for eight threads fell from 30,538 to 101. Kernel cycles per read on the contended eight-thread same-file case fell from about 2,937–2,975 to about 725–726. Some paths get worse: a read into a user page that is not present costs an extra failed exception per read on the series. Large 64 KiB reads stay on the fast path with fewer instructions; 1 MiB behaviour is messier across runs.

Memory waiting for a grace period is the other measured axis. With only patches 1–6, a hole-punch stress loop left hundreds of mebibytes waiting on average and peaks over a gibibyte; with patches 7 and 8 the averages drop sharply, though peaks remain material when no CPU is idle. Kiryl’s OOM reproducer in a 2 GiB VM without swap killed a large anonymous process under patches 1–6 at four and eight CPUs; with 1–8 it ran to the end. These are still single-developer measurements. Compare them the way you would any carefully labelled self-test, not a multi-machine lab study like a formal training-versus-inference benchmark suite.

What does the Claude Code credit actually say?

Near the end of the cover letter, under “Tools,” Torvalds writes: “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.” That sentence is why the branch name ends in “with-llm” and why the story travelled beyond mm/. It is also carefully scoped: direction, measurement and the decision to publish remain his.

Claude Code here is Anthropic’s agentic coding product, not a silent autocomplete tab. Torvalds has previously talked about AI as a useful tool for kernel work; this series is a concrete, named instance with a primary-source credit line. It sits beside other Anthropic tooling news such as Claude Code Projects, but the kernel branch is not an Anthropic announcement—it is a Linux maintainer publishing work that used the tool.

Readers should not infer that mainline Linux is about to accept unreviewed LLM patches. The message spends more words on known problems and missing tests than on the assistant. The interesting fact is that the person with merge authority chose to disclose the tool, keep the measurements local, and ask for specialised review.

What is still unfinished?

Torvalds’ known-problems list is unusually frank for a viral AI story. Problem 1: the allocator cannot see waiting pages—they have refcount 0, are not PageBuddy, and sit in no counter—so reclaim math and OOM decisions can be wrong; patches 7 and 8 shorten lists but do not make the allocator account for them; alloc_contig_range can return -EBUSY and hurt CMA. Problem 2: one more page flag, with possible pressure on MGLRU bits under MAXSMP. Problem 3: splice steal of page-cache folios into fuse is removed—does anyone depend on it? Further items cover s390 secure folios, unmeasured free-path cost, ordering arguments without litmus tests, missing xfstests/KASAN/lockdep/clang/32-bit coverage, quieter page-cache tracepoints, RCU batching choices, and lazy-preemption interactions with expedited grace periods.

Testing named in the message includes an evict-race harness with about 10^8 reads, partial-fault reads, hole-punch wait sampling, Kiryl’s VM reproducer, a gcc build of one x86-64 config, and running the laptop on it. That is serious for an experimental branch and nowhere near merge bar for mm/. Torvalds asks for eyes especially on the allocator visibility problem and on whether there is a better RCU hook than a custom pending list.

Why does this matter beyond one branch?

The durable news is not “AI wrote the kernel.” It is that a high-stakes subsystem patch series can be LLM-assisted, openly credited, narrowly measured, and still treated as unfinished engineering. That is a healthier pattern than silent tool use or hype that skips the risk list. It also complements security work on stopping unwanted model extraction—see Anthropic’s distillation defences—by showing constructive, disclosed use of the same class of tools inside infrastructure software.

For application developers, the takeaway is smaller: if your workload is many threads doing tiny reads of one hot file, this is the contention shape Torvalds is chasing; watch whether a cleaned-up series lands, and do not expect 3× on every machine from an unmerged laptop experiment. For AI-tooling watchers, the takeaway is larger: disclosure plus maintainer judgment plus listed unknowns is the bar worth copying.

Until then, the branch is what it says it is—an experimental eight-patch series with a Claude Code credit line and a long homework list for memory-management reviewers.