Linus Torvalds Uses AI for Linux Kernel Code
Linus Torvalds used Claude Code to help build a Linux kernel patch. See what it changes, what benchmarks show, and why the work is not ready to merge yet.
Linus Torvalds Used AI to Help Write a Linux Kernel Patch. What Happens Next?
Linus Torvalds says he used an AI coding assistant while working on a Linux kernel patch. That's a real shift in how code gets drafted - but it's not a sign that "AI is taking over" Linux development. This patch is an experiment aimed at a specific performance bottleneck. It's still outside the mainline kernel, and key engineering questions remain open.
Torvalds developed the work largely with Anthropic's Claude Code. The target is contention in Linux's page cache. In one small-read test, the proposed changes produced a large throughput boost. But it also introduces trade-offs around memory reclamation and a regression in another read scenario. Those details matter more than the headline benchmark.
This article breaks down what the patch changes, how to interpret the results, and why its current status shouldn't be confused with an approved kernel feature. It also looks at what Torvalds' use of Claude Code really signals for software development: a change in tools for drafting and reviewing code, not a change in who's responsible for whether it's safe to ship.
What the Linux kernel patch is trying to fix
The patch is aimed at contention in the Linux page cache - the part of the kernel that keeps file data in memory so reads don't have to keep going back to storage. Because it's shared by many processes and threads, small inefficiencies can show up quickly when you hit the right kind of workload.
In Torvalds' submission, the bottleneck shows up when several threads repeatedly read small amounts of data from the same cached file. To manage the memory safely, the existing code updates a reference count tied to the relevant folio (a kernel-managed memory unit). Those updates require atomic operations on shared state.
Atomic operations are needed so the code stays correct when multiple CPU cores touch the same value at the same time. But atomic updates aren't free. When many cores keep modifying the same cache line, the hardware has to coordinate access, and that coordination can outweigh the "real work" done on a hot read path.
Why a small read can cause a large slowdown
Torvalds reports a test where eight threads run 16-byte pread() calls against the same page on a four-core, eight-thread Intel Core i7-8565U laptop. In that run, the shared cache line made up 99.92% of measured cross-core loads, based on Hit in Modified cache-line events (HITMs).
That number doesn't generalize to "Linux performance" overall. It describes a particular workload on a particular machine. Still, it matches the underlying story: the per-thread work is tiny, so the overhead from coordinating shared state dominates.
Also, this isn't a brand-new discovery. Torvalds notes the issue had been known since 2024, and earlier attempts hadn't produced a fix. In kernel development, finding a bottleneck is only half the job. A correct fix also has to hold up across different workloads and architectures, without swapping one problem for a worse one somewhere else.
The proposed change: defer reuse instead of taking a reference
The patch changes when memory removed from the page cache can be reused. Instead of handing that memory back to the allocator right away, the patch defers reuse until an RCU grace period completes.
RCU (read-copy-update) is a synchronization approach that lets readers access data while writers update it, typically avoiding a lock on every read.
With this approach, a reader in an RCU read-side section can copy data into a user buffer without taking a folio reference the same way the existing path does. The goal is simple: stop repeatedly updating a shared reference counter on a hot read path.
The trade-off is also straightforward. Deferring reuse means memory that might otherwise become available sooner stays tied up until the grace period ends. So this isn't "free speed." It changes the timing of memory reclamation and shifts work into the RCU lifecycle. Whether that's a good deal depends on the real workload and how it behaves under memory pressure - so it has to be tested before anyone treats the benchmark as a general win.
What the performance results do - and don't - show
The reported numbers look strong for the specific test that triggered the problem. With eight threads, throughput goes from about 9.9-10.4 million reads per second to 30-33 million. Kernel cycles per read drop from roughly 2,950 to 725.
Single-thread gains look smaller. The reported cost drops from about 452-454 cycles per read to 408-409. That gap matters: the improvement isn't uniform. The biggest wins show up in the multithreaded scenario where contention over shared state is the main suspect.
Torvalds also suggests that systems with more CPUs - or multiple sockets - could benefit more. But that's still a hypothesis. The submission doesn't come with broader measurements across many servers or production environments.
Read the benchmark in its proper scope
A benchmark always answers a specific question under specific conditions. Here, the question was whether this approach can cut overhead for repeated small reads from shared cached data on the tested laptop.
So no, these results don't mean "Linux runs three times faster." They don't prove that desktop systems, cloud workloads, databases, file servers, or other real uses will see the same improvement. A production evaluation would need to account for CPU design, core counts, storage patterns, memory pressure, and application behavior.
That said, the reported figures aren't useless. They suggest the patch may address a real cost in a workload engineered to stress this particular path. The next step isn't to celebrate the biggest number - it's to test whether the gain holds across more representative workloads and whether the memory-management costs stay reasonable.
One practical way to keep the claims straight is to separate them into three buckets:
- Observed: The proposed code improved throughput and reduced kernel cycles in the reported multithreaded test.
- Plausible but unproven: Machines with more CPUs or multiple sockets could benefit more, since the contention pattern might scale.
- Not established: Linux overall (and typical applications) will become substantially faster.
That framing matters when kernel benchmarks start getting attention. Narrow performance results aren't automatically misleading. They become misleading when the conditions behind the numbers get left out.
Why the patch is not ready to merge
The performance improvement is only part of whether the patch is a good change. The series still has unresolved costs, and Torvalds points to memory reclamation as the least-solved part. That's a warning not to treat the test result as the end of the story.
Deferring reuse until an RCU grace period passes means pages can stay unavailable longer. How that plays out depends on how often the situation occurs, how much memory gets retained, and what the system does under pressure. A change that's fast in a controlled test can still be a bad general-purpose kernel change if it creates unwanted memory behavior elsewhere.
There's also a reported regression when a read targets a user page that hasn't been mapped yet. In that case, the new path hits an extra failed exception before falling back to the existing behavior. Whether that's acceptable depends on both frequency and impact. A rare case might be fine; a common one could erase some of the gains or make the path harder to maintain.
Mainline status is a separate question from benchmark results
As of October 13, the branch is still outside mainline Linux 7.3-rc6. Whether it gets merged - and when - wasn't decided. A proposed patch is not a released kernel feature. It still has to survive review, testing, and the normal process of resolving concerns about correctness, performance, and maintainability.
This distinction matters even more in a project used across laptops, phones, servers, embedded devices, and cloud infrastructure. The kernel can't optimize only for the machine that produced the most encouraging microbenchmark result. Maintainers have to account for different hardware and workloads, including the edge cases you can't easily capture in a short test run.
A quick status checklist for this patch looks like this:
- A performance problem has been measured: yes, for a specific small-read workload.
- A proposed mechanism has shown promising results: yes, in the reported test.
- The memory-reclamation approach is fully resolved: no.
- All relevant regressions have been ruled out: no.
- The patch is in the mainline release: no, as of the reported status.
That doesn't make it a failure. It's exactly what kernel development is supposed to do: make a hypothesis testable, measure it, expose the costs, and decide whether the trade-off is acceptable in practice.
What Torvalds' use of Claude Code tells us
Torvalds' use of Claude Code is notable because it brings AI assistance into a real, high-stakes development workflow. In his Git submission, he describes the code, test programs, review work, and the first draft of the accompanying text as being produced with an LLM coding assistant under his direction.
The phrase under my direction matters. It's assistance, not delegation. The patch still needs to be understood, evaluated, and defended by the people submitting it. In systems software, a plausible-looking implementation isn't enough - you need correctness under concurrency, memory pressure, and the kinds of edge cases that are hard to capture in a short benchmark.
Torvalds' public stance on AI seems to have evolved gradually rather than switching overnight. He previously talked about AI as a tool to help developers, including finding bugs. Later, he discussed it more openly in the context of maintenance and patch review. He also experimented with AI-assisted coding on a hobby project before using it for this kernel work.
The tool is new; the engineering burden is not
The important point isn't that Claude Code can generate code. Tools like this have been used to draft patches, tests, and explanations in many development setups. The harder question is whether those outputs can fit into a workflow that catches mistakes and keeps responsibility clear.
For maintainers, that means asking familiar questions:
- Can the author explain why the change is correct?
- Do tests cover the important behaviors and failure cases?
- Are the performance claims reproducible and scoped properly?
- Are the trade-offs clear to reviewers?
- Can someone maintain the code if the original contributor isn't around?
AI can help with parts of that work. It can draft code, suggest tests, summarize a patch, or explore an implementation path. But it doesn't replace the need to check what it produces. In fact, getting a coherent-looking first draft can make careful review even more important - reviewers still have to separate real design correctness from code that merely sounds right.
That's why this case is more useful than broad hand-wringing about whether AI is "ready" or "not ready" for professional software development. It's a bounded example: a human directs the work, the results are measurable, and the limitations are still visible alongside the gains. The standard doesn't change depending on where the first draft came from. The patch still has to earn its place on technical merit.
Conclusion
Torvalds' patch is a real milestone in how AI is being used in systems programming - but the more important story isn't that AI helped write kernel code. It's that the work is being judged through the same hard process as any other kernel change: measure the benefit, expose the costs, test edge cases, and decide whether the result is maintainable.
The benchmark suggests that avoiding shared reference-count updates can help in a specific, highly contended read workload. It doesn't settle the memory-reclamation question, remove the reported regression, or guarantee a mainline place. Those aren't small footnotes - they're part of the engineering decision.
If you're tracking AI-assisted development, keep the distinction clear between a generated patch, a reviewed proposal, and production-ready code. Read the original ZDNET report for the submission details, then watch what happens during the kernel's review and merge process. The key question isn't whether AI wrote some of the code. It's whether the final system is correct, measurable, and maintainable.