Linus Torvalds Develops Kernel Patches with Claude Code, Boosting Performance 3x

A real kernel experiment, not a slogan

The working headline matches the story: Linus Torvalds used Claude Code in a Linux kernel performance experiment that began as an eight-patch branch targeting page-cache read scalability and showed roughly threefold throughput improvement on a specific laptop benchmark [1]. The branch, named noref-filemap-read-with-llm, addressed a narrow but serious bottleneck: many threads repeatedly reading small amounts from the same cached file can all contend on the same folio reference-counting cache line [1].

That distinction matters. This is not a claim that “Linux is three times faster” in general. The original benchmark was a concentrated stress case: eight threads repeatedly reading the same small cached file, where the old path had to take and drop folio references over and over [1]. In that workload, the reported result moved from roughly 10 million reads per second to about 31–33 million reads per second, while kernel cycles per read fell from around 2,950 to roughly 720–725 [1].

The story also matters because of who did it. Torvalds is not just another developer experimenting with an AI coding assistant; he is the founder and lead maintainer of the Linux kernel. The initial report said the code, tests, review notes, and first draft of the write-up were produced with Claude Code under his direction, while the measurements were run on his own machine [1]. In other words, the experiment was not “AI replaces the maintainer.” It was closer to “the maintainer scopes the problem, directs the tool, measures the result, and exposes the unresolved risks.”

From eight patches to a ten-patch rcu-free-v3 branch

The current state is more nuanced than the first wave of coverage. On October 13, Torvalds described a newer rcu-free-v3 branch in his public tree and said it had grown into a “fairly short series of ten patches” [2]. He wrote that the work came after several earlier attempts to improve page reference scalability around normal read() and pread() calls, including older approaches that had turned out to be broken or incomplete [2].

The revised idea is to make hot folios eligible for delayed freeing after an RCU grace period, then extend the RCU-protected region beyond lookup to cover the actual data access when the copy to userspace does not fault [2]. The goal is to avoid taking a folio reference on the fast path. If the page-cache entry remains safe to read inside the RCU window, the code can skip the shared reference-count writes that caused the scalability wall [2].

Torvalds was careful about the interpretation of the bigger number. In the same message, he reported a 23x increase on his Ryzen Threadripper, with a synthetic 64-thread benchmark rising from 13.3 million reads per second to 304 million reads per second and cycles per read falling from nearly 20,000 to about 735–736 [2]. But he also emphasized that the benchmark was highly artificial: it repeatedly read the same small part of a page across all CPUs, so real-life impact would be “much much less” [2].

That caveat is the most important sentence in the performance story. The threefold laptop result is already workload-specific, and the 23x Threadripper result is even more synthetic. What the benchmarks prove is that the old reference-counting path can become a severe scalability limiter under extreme contention. They do not prove that ordinary desktops, servers, databases, or build farms will see a proportional speedup.

Why page-cache reference counts are hard

The page cache is one of the Linux kernel’s most performance-sensitive subsystems. It keeps file data in memory so repeated reads can avoid slower storage access. The catch is that correctness is unforgiving: the kernel must not allow a reader to access memory that has been reclaimed, replaced, truncated, or reused.

Traditional reference counting gives a straightforward safety rule. A reader takes a reference to the folio, uses it, then drops the reference. The cost is that these operations are atomic writes to shared state. Under heavy multithreaded contention, the data itself may be hot in cache, but the reference count becomes a traffic jam.

The Claude-assisted patch series is interesting because it attacks that traffic jam directly. Instead of making the reference count cheaper, it tries to avoid touching it for the fast path. The mechanism is RCU, or Read-Copy-Update, a kernel synchronization technique that lets readers proceed while reclamation is deferred until after readers that might have seen the old object are done. Torvalds’ newer description says the branch delays freeing the underlying folio data and then reads the data inside an RCU-protected region [2].

That is also why the work is risky. Whenever a performance patch changes object lifetime rules, the kernel community asks a brutal question: what exact interleaving can break it? Page-cache reads interact with truncation, hole punching, reclaim, page faults, filesystem behavior, and the file size. Getting one order wrong can turn a speedup into a data exposure or corruption bug.

Review found a race before merge

Fresh review coverage shows the kernel process doing what it is supposed to do. LWN summarized the series as Torvalds’ first LLM-assisted patch series and noted that review had already identified a race condition, meaning further work would be needed [3]. That point should temper the “AI wrote a kernel optimization” narrative. The patch set had not simply sailed into mainline; it was being tested by the same adversarial review culture that all risky memory-management work faces.

The race was discussed directly on the kernel mailing list. Kiryl Shutsemau described a problem in filemap_read_rcu_batch(): if a folio is replaced and then i_size is extended, the read path could return data that had never been written there [5]. Torvalds suggested moving the file-size check earlier and consolidating the validity checks, and Shutsemau replied that the approach was workable and included a patch adjustment [5].

That exchange is the real signal. AI assistance may have helped generate code, tests, and documentation, but human maintainers still found a concurrency hazard. The kernel’s review model did not become obsolete; it became the safety net that determines whether AI-assisted code is useful or dangerous.

Maintainers are debating the design, not just the tool

The technical disagreement is not limited to the race. Matthew Wilcox called the numbers compelling but objected to the new PG_rcu_free flag, suggesting that a page type might be a better fit and raising questions about how page-cache folios should move through reclaim states after an RCU period [4]. Shutsemau later floated restricting the flag to 64-bit systems, where flag scarcity is less severe [5].

These are not cosmetic objections. Kernel memory-management design is often a trade-off among speed, correctness, architecture constraints, and maintainability. A new flag may solve the immediate implementation problem while consuming scarce metadata space or complicating behavior on some systems. An inactive-list or page-type approach may be cleaner in one dimension and messier in another. The fact that maintainers are arguing at this level means the series is still design work, not a finished product.

It also clarifies the role Claude Code played. The assistant may have accelerated exploration and produced a coherent prototype, but the debate is about invariants: when a folio may be mapped, when it may be freed, which memory barriers are sufficient, and which architectures should participate. Those questions require deep subsystem knowledge and conservative judgment.

What the experiment proves

The experiment proves three things, and only three.

First, AI-assisted coding can now participate in serious systems-programming work when directed by someone who understands the subsystem. Torvalds chose a real bottleneck, not a toy problem, and the resulting patches were good enough to start a substantive kernel discussion [2].

Second, benchmarks can be both impressive and narrow. The original eight-patch branch delivered about a threefold improvement in a laptop stress test [1]. The later ten-patch branch produced a 23x result on a Threadripper synthetic test [2]. Both are meaningful; neither should be generalized into “Linux reads are now 3x or 23x faster.”

Third, review remains the gating mechanism. A race was found before merge, maintainers are questioning the reclamation design, and the patch set still needs more work [3][5]. That is not a failure of the process. It is the process.

The broader meaning for AI-assisted Linux development

For Linux, the most important precedent may be transparency. The original branch made the AI role explicit: Claude Code helped with implementation, tests, review notes, and the first write-up, while Torvalds directed the work and ran the measurements [1]. The newer mailing-list discussion then moved the conversation from novelty to engineering: better benchmark numbers, a revised RCU design, a discovered race, and maintainers debating memory-reclamation semantics [2][3][4][5].

That is likely the model AI tools will have to meet in core infrastructure. Not “trust the model,” and not “ban the model,” but “show the code, show the measurements, disclose the limits, survive review.” Torvalds’ Claude Code experiment is important precisely because it does not end with the benchmark. It continues into the hard part: proving that a faster page-cache path is also correct.

As of the latest reviewed material in the 72-hour window, the safest conclusion is restrained. Linus Torvalds has demonstrated that Claude Code can help produce a serious Linux kernel patch series with striking performance results in targeted benchmarks. But the work is not a mainline Linux speedup yet. It is an experimental, actively reviewed memory-management change whose promise depends on resolving the race, settling the reclamation design, and proving that the fast path remains safe outside synthetic tests.

Developments

1. Linus Torvalds Uses Claude Code for Kernel Patches, Boosts Performance by 3x36Kr · Oct 16, 2026, 6:32 AM · 8/10
2. Linus Torvalds Confirms Claude Code Wrote Linux Kernel PatchesCyberSecurityNews · Oct 16, 2026, 6:08 AM · 8/10
3. Linus Torvalds Reveals Claude Code Wrote Linux Kernel Patches and Test ProgramsCyberSecurityNews · Oct 16, 2026, 6:08 AM · 8/10
4. Linus Torvalds Uses Claude Code for Linux Kernel, Boosts Performance by 3x36Kr · Oct 14, 2026, 10:50 AM · 8/10
5. Linus Torvalds Implements Claude Code for Linux Kernel, Tripling Performance36Kr · Oct 14, 2026, 10:50 AM · 9/10
6. Linus Torvalds Uses Claude Code to Triple Linux Kernel Read ThroughputBigGo Finance · Oct 12, 2026, 2:05 PM · 8/10
7. Linus Torvalds Uses Claude Code to Triple Linux Kernel Read Performancefinance.biggo.com · Oct 12, 2026, 2:05 PM · 8/10
8. Linus Torvalds says Claude Code helped write a Linux kernel patchPasquale Pillitteri · Oct 12, 2026, 12:24 PM · 9/10
9. Linus Torvalds credits Claude Code for aiding Linux kernel patchPasquale Pillitteri · Oct 12, 2026, 12:24 PM · 8/10
10. Linus Torvalds rewrote Linux cache reading with Claude CodeStartup Fortune · Oct 12, 2026, 11:21 AM · 8/10
11. Linus Torvalds Developing Major Linux Kernel Update with Claude CodePhoronix · Oct 12, 2026, 2:16 AM · 8/10
12. Linus Torvalds Works on Linux Kernel Improvement with Claude CodePhoronix · Oct 12, 2026, 2:16 AM · 7/10

Sources from the last 72 hours

1. [1]Linus Torvalds wrote a Linux kernel speedup with Claude CodeOct 13, 2026, 2:00 PM
2. [2]Linux-Kernel Archive: Improve page refcount scalabilityOct 13, 2026, 11:26 PM
3. [3]Linus Torvalds's first LLM-assisted patch seriesOct 14, 2026, 3:50 PM
4. [4]Linux-Kernel Archive: Re: Improve page refcount scalabilityOct 14, 2026, 12:08 AM
5. [5]Linux-Kernel Archive: Re: Improve page refcount scalabilityOct 14, 2026, 2:53 PM

AI-generated article based on recent web research, then preserved as a dated editorial snapshot.