[KongchangAI]
· 3 min read· 1,622 words

Torvalds Lets Claude Code Write Kernel Patches: 3x Small-Read Speedup in Page Cache, Not Yet Merged

Torvalds Lets Claude Code Write Kernel Patches: 3x Small-Read Speedup in Page Cache, Not Yet Merged

Torvalds uses Claude Code to refactor kernel page cache small reads, achieving 3x throughput on eight threads while retaining some regressions.

Linus Torvalds pushed a branch named noref-filemap-read-with-llm in his personal tree, using eight patches generated by Anthropic Claude Code under his direction to refactor the Linux kernel page cache small-read path. Previously, every small read required atomic reference count increment/decrement on the folio, causing the same cache line to bounce repeatedly across cores; the new approach bypasses reference counting via RCU delayed release. On Torvalds's Core i7-8565U laptop, eight-thread single-file 16-byte pread improved from about 10 million/sec to 30–33 million/sec, and load HITM dropped from 30538 to 101, but single-thread reads into unmapped user pages showed about a 58% cycle regression, and delayed release was called the least well-solved part by Torvalds. The article uses this to propose an engineering paradigm for agent collaboration and disclosure, and introduces the kernel's existing Assisted-by specification.

Every small read operation on the Linux kernel page cache requires an atomic reference count increment/decrement on the folio. When multiple cores read the same file simultaneously, this shared cache line bounces back and forth between cores, becoming the primary bottleneck for concurrent reads. Linus Torvalds recently pushed a branch named noref-filemap-read-with-llm in his own Linux tree, reimplementing this path with eight patches, and explicitly noted that the code, test programs, issue lists, and even the cover letter draft were all generated by Anthropic's Claude Code under his direction.

rss source: Torvalds Let Claude Code Write 8 Kernel Patches: 3x Reads on One Laptop, Not Merged

What the Patches Changed

In the existing implementation, every small read from the page cache takes and releases a folio reference, which is an atomic write operation to the same cache line. On Torvalds's Core i7-8565U laptop, when eight threads perform 16-byte pread() calls to the same file, this line accounts for 99.92% of cross-core load HITM events. Kernel developers had previously reported this bottleneck in 2024 based on customer workloads, and Phoronix noticed the branch while waiting for the Linux 7.3-rc7 tag.

The new approach bypasses reference counting using the RCU mechanism: folios that leave the cache are returned to the page allocator only after a grace period, so readers can copy data directly from pages without touching the reference count. The trade-off is that these pages linger for a short time and cannot be reused. Two of the eight patches add safety valves—forcing an accelerated grace period when a CPU queues more than 1024 pages—but Torvalds still calls delayed release "the least well-solved part" of the entire series.

RCU (Read-Copy-Update) is a synchronization mechanism in the Linux kernel known for zero overhead on the read side. Its core idea: read operations take no locks and rely only on atomic reads/writes of pointers; write operations first create a new copy, then atomically replace the pointer. The old copy is not freed immediately but waits until all ongoing readers have left the critical section before being reclaimed. This waiting period is called a "grace period." Determining the end of a grace period requires confirming that every CPU has undergone a context switch or is idle, so classic RCU grace periods are typically on the order of milliseconds; the kernel provides interfaces like synchronize_rcu() and call_rcu() for this purpose. The cost of grace periods is precisely delayed reclamation: old data occupies extra memory before being freed, and if readers remain active or a CPU stays in a busy loop for a long time, the grace period is extended. These patches exploit exactly this property—folios leaving the page cache are not immediately returned to the allocator but are placed on an RCU callback queue, allowing subsequent readers to safely copy data without touching the reference count; the CPU queue threshold (1024) added by Torvalds is meant to prevent the grace period from being extended indefinitely and exhausting memory.

perf c2c is a subcommand in the Linux perf toolset specifically for diagnosing cache-to-cache (C2C) false sharing and cache line bouncing. It samples HITM (Hit Modified) events in hardware performance counters to count: when a core accesses a cache line that is currently held in Modified state by another core and must be forwarded across cores, a HITM occurs. perf c2c resolves the memory address corresponding to each HITM event, the two CPUs involved, and the instruction and call stack that triggered the access, aggregates by cache line, and outputs a ranking of "which variable is being bounced repeatedly by which thread." This makes it more capable than generic perf stat at pinpointing specific fields or struct members. In the article, load HITM drops from 30538 to 101, meaning that in the original implementation almost every small read was moving across cores the cache line containing the same folio reference count field; the new approach eliminates this hotspot, and the remaining 101 events likely come from other unavoidable shared accesses. Using perf c2c typically requires root privileges and mounting perf_event_paranoid at a sufficiently permissive value.

The Numbers, Including the Regressions

The following data all come from the same 4-core 8-thread laptop, with CPU mitigations disabled during testing. In the eight-thread single-file scenario, cycles per read drop from approximately 2950 to approximately 725, and reads per second increase from 9.9–10.4 million to 30–33 million; in the single-thread scenario, cycles drop slightly from 452–454 to 408–409; perf c2c load HITM drops from 30538 to 101.

But the published data also preserves regressions: for single-threaded 16-byte reads into an unmapped user page, cycles rise from approximately 4150 to approximately 6550. Memory pressure tests also exposed problems—in a 2 GiB virtual machine, the six-patch version without the safety valve patches triggered the OOM killer in 4-core and 8-core configurations, while the full series completed under 1, 2, 4, and 8 cores. Torvalds expects the benefits to be more pronounced on larger and multi-socket machines, but has not yet tested such hardware.

It should be noted that the 3x figure comes from only one machine and was measured by the person directing the series. Before citing it to describe your own server, it's best to test the branch on your own hardware.

Read the Cover Letter as a Review Checklist

The cover letter clearly states the division of labor: Claude Code produced all the signed-off content above under Torvalds's direction, and the benchmarks were run on his own machine. This is not a one-off—It's FOSS also links a previous record of AI-assisted fixing of an Intel Xe graphics driver bug, and Torvalds said at Open Source Summit Europe in Prague that "I actually really like using AI."

This division of labor can be broken down into four reproducible habits applicable to any agent-written changes submitted to a team: declare agent authorship in the branch name or PR title, so reviewers adjust how they read; run the numbers yourself on named hardware—the agent can write benchmarks, but you own the results; publish regressions with the same precision as gains; keep an open issues list and let the agent help write it—having it review its own work first is low-cost before others spend time.

The Kernel Already Has Rules in Place

No need to invent a disclosure format. The kernel's AI Coding Assistants guidelines require contributions to carry an Assisted-by: LLM [TOOL1] [TOOL2] tag, where tools are optional analysis tools like coccinelle, sparse, etc., and explicitly state that "AI agents must not add Signed-off-by tags," because only humans can certify the Developer Certificate of Origin. Humans review all AI-generated code and bear full responsibility.

In your own repository, you can follow the same convention with ordinary git. Add the trailer and your sign-off when committing:

git commit -s --trailer "Assisted-by: LLM"

Reviewers can then list which commits on a branch were agent-assisted:

git log main..HEAD \
  --format='%h %s %(trailers:key=Assisted-by)'

The --trailer option and the %(trailers) placeholder are both standard git features.

Developer Certificate of Origin (DCO) is a statement that open source projects like the Linux kernel require contributors to sign; its text states: the submitter certifies that they have the right to submit the code and that the contribution complies with the project license. The kernel reflects this signing through the Signed-off-by: Name <email> trailer in the commit message, automatically appended with git commit -s. This tag is not a copyright transfer but a legal "origin guarantee," so it must be given by a natural person with legal capacity (or someone authorized to represent a legal entity), and the name and email must be real and traceable. This is precisely why the kernel's AI assistant guidelines explicitly state that "AI agents must not add Signed-off-by tags"—LLMs cannot bear the legal responsibility required by the DCO and cannot be held accountable. In contrast, Assisted-by: is merely a factual annotation telling reviewers which parts of the commit involved tools; it carries no legal commitment, so it can point to LLMs, coccinelle, sparse, and other analysis tools. In practice, human contributors keep their own Signed-off-by with git commit -s and add Assisted-by separately, separating and making auditable the two dimensions of "accountability" and "tool disclosure."

Engineering Practice Takeaways

Torvalds's branch isolates agent output on a named branch and reviews it in chunks—exactly the workflow many AI-assisted development tools are built around. For developers using coding agents like Claude Code, the core value of this event is not the 3x number itself but a reusable collaboration paradigm: the agent handles code generation, test writing, and issue list drafting, while humans handle direction, hardware verification, and final merge decisions. The fact that the patches are not yet merged also shows that the human gatekeeping step in this process has not been bypassed.

One-line Summary

Torvalds uses Claude Code to refactor kernel page cache small reads, achieving 3x throughput on eight threads while retaining some regressions.

Paragraph Summary

Linus Torvalds pushed a branch named noref-filemap-read-with-llm in his personal tree, using eight patches generated by Anthropic Claude Code under his direction to refactor the Linux kernel page cache small-read path. Previously, every small read required atomic reference count increment/decrement on the folio, causing the same cache line to bounce repeatedly across cores; the new approach bypasses reference counting via RCU delayed release. On Torvalds's Core i7-8565U laptop, eight-thread single-file 16-byte pread improved from about 10 million/sec to 30–33 million/sec, and load HITM dropped from 30538 to 101, but single-thread reads into unmapped user pages showed about a 58% cycle regression, and delayed release was called the least well-solved part by Torvalds. The article uses this to propose an engineering paradigm for agent collaboration and disclosure, and introduces the kernel's existing Assisted-by specification.

#Torvalds#Claude Code#Linux kernel#page cache#RCU#perf c2c#AI code disclosure#Assisted-by
Share:

Related articles