Linus Torvalds Let Claude Code Touch the Linux Kernel: Copy His Workflow, Not His Headline

Last week, the cover letter of a Linux kernel patch series contained a sentence nobody expected to read this year: "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 is Linus Torvalds, the developer who publicly mocked engineers for claiming AI writes 99 percent of their code, crediting an AI agent for code targeting the Linux page cache. The internet did what the internet does: it turned the story into "AI writes kernel code now."

That framing misses the actual lesson. The patch series, an experimental branch called noref-filemap-read-with-llm that Phoronix spotted on October 12, is not merged, and the headline numbers come from one synthetic benchmark on one laptop. What is genuinely interesting is the workflow wrapped around the agent. Torvalds did not ask an AI to "optimize my kernel." He ran a disciplined, measurement-first process that any developer can copy on any codebase, and the process explains why his result is credible while most "AI rewrote our app" stories are not.

Full disclosure before we start: the benchmark numbers below are Torvalds' own, as reported by Phoronix, ZDNET, and The New Stack. I have not benchmarked the branch myself, and the branch is not merged into mainline Linux. This piece is about the workflow, not a verdict on the code.

What the patches actually do

The problem is narrow and old. When many threads read small chunks from the same cached file, every read bumps an atomic reference count on the folio, the kernel's unit for cached pages. All those cores are writing to the same cache line, so they spend their time fighting each other instead of copying data. On Torvalds' 4-core, 8-thread laptop, that one shared cache line accounted for 99.92 percent of cross-core load HITMs in his eight-thread test.

His fix removes the reference-counting from the read path. Reads happen inside an RCU read-side critical section, and the folio's memory is freed only after an RCU grace period passes. In his benchmark, eight threads issuing 16-byte pread() calls against one page went from roughly 10 million reads per second to 30 to 33 million. Kernel cycles per read fell from about 2,950 to about 725.

Three caveats that the hot takes skipped. First, that workload is a contention pathology, not normal file reading, so nobody's app just got 3x faster. Second, an earlier version had a race that reviewers caught, and Torvalds followed up with a revised 10-patch series using a new PG_rcu_free flag and RCU-delayed reclamation. Third, there is a regression: reads into unmapped user pages now take an extra fault before falling back, pushing a single-thread 16-byte read from about 4,150 to 6,550 cycles. The revised series showed much bigger gains under heavy contention on his 64-thread Threadripper, from 13.3 million to 304 million reads per second, but the review is still ongoing.

Keep those caveats in mind, because the workflow below is exactly what produced them.

The workflow: benchmark first, agent second

Here is the process distilled from the branch, the cover letter, and the mailing list thread that followed. Six steps, and none of them start with "open the AI tool."

Step 1: Prove the bottleneck exists before touching code. Torvalds did not guess that folio reference counts were the problem. The 99.92 percent HITM figure came from profiling. On Linux, the tool for this is perf c2c (cache-to-cache):

perf c2c record -a -- sleep 10
perf c2c report --stdio

The report ranks cache lines by HITM events, meaning loads that had to fetch the line from another core's cache. If one line dominates, you have a contention problem worth solving. If nothing dominates, an AI agent will happily rewrite code that was never slow. This step alone kills most wasted agent time.

Step 2: Write the benchmark before the fix. Torvalds' benchmark is a tight loop: eight threads, 16-byte pread() calls against one cached page. A simplified version of the harness takes about thirty lines of C:

#define _GNU_SOURCE
#include <fcntl.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define THREADS 8
#define READS   2000000L

static const char *path;

static void *worker(void *arg) {
    char buf[16];
    int fd = open(path, O_RDONLY);
    for (long i = 0; i < READS; i++)
        pread(fd, buf, sizeof buf, 0);
    close(fd);
    return NULL;
}

int main(int argc, char **argv) {
    path = argv[1];
    pthread_t t[THREADS];
    for (int i = 0; i < THREADS; i++)
        pthread_create(&t[i], NULL, worker, NULL);
    for (int i = 0; i < THREADS; i++)
        pthread_join(t[i], NULL);
    return 0;
}

Run it under time, multiply threads times reads, divide by elapsed seconds, and you have a baseline. The point is not this exact program. The point is that the benchmark existed before the agent wrote a line, and it measured the specific pathology, not "general performance." An agent optimizing against a vague goal produces vague code. An agent optimizing against a number produces verifiable work.

Step 3: Direct with constraints, not solutions. The cover letter phrase "under my direction" is doing real work here. Torvalds gave the agent a problem with a fully mapped history: the bottleneck, the architecture, the approaches that had already failed. Reviewers on the mailing list, including David Hildenbrand, had spent years on this exact contention issue, and Torvalds had run his own broken version of a fix for 18 months before this. The agent was not exploring. It was executing inside tight rails. That is the difference between an agent that produces a patch series and an agent that produces a plausible-looking mess.

Step 4: Trust the number, not the diff. Torvalds did not read the generated code and decide it looked fast. He ran the measurements, and his quote says exactly that: "The measurements were run on my machine." When reviewers later found a race in the first series, the benchmark is what made the follow-up measurable too. The revised series' claim, 13.3 million to 304 million reads per second on a Threadripper under heavy contention, is falsifiable because the harness is fixed and public. Diff-reading is opinion. Benchmarking is evidence.

Step 5: Assume review will find something. The first series had a real race: the code had to guarantee it was reading a folio that had not been reused, and it did not. This is the part of the story that should deflate both AI hype and AI panic. The agent produced a fast patch with a correctness bug, the human review process caught it, and a corrected design followed within days. The AI did not replace review. It made review matter more, because more candidate code now exists to review.

Step 6: Publish the accounting. The cover letter itemizes what the agent did: the code, the test programs, the review work, and a first draft of the letter itself. Torvalds kept authorship responsibility with "under my direction." This is the opposite of the quiet pattern where teams ship AI-generated code and describe it as normal engineering. Precise accounting is what let the community evaluate the work honestly instead of guessing.

What this does not prove

Be honest about the limits, because the piece you write against this story matters as much as the story.

• The gains are benchmark-specific. Torvalds himself warned that real-world workloads would see considerably smaller improvements.
• The original numbers came from one laptop with mitigations disabled, which is a lab condition, not a deployment.
• The series is not merged. Whether it lands in the Linux 7.4 merge window is still open, and the unmapped-page regression needs a fix.
• "Written by Claude Code" does not mean "correct." The race proved that within a week.

What it does demonstrate is that a skeptical, measurement-obsessed engineer found an AI coding agent useful on the most reviewed codebase in the world, and the reason it worked has nothing to do with the model being clever. It has to do with the harness around it.

The checklist

Here is the whole workflow as a checklist you can apply to your own hot path, whether that is a database query, a message queue consumer, or a render loop:

• Profile first with a cache or flamegraph tool. Name the exact contention point and its percentage.
• Write a benchmark that reproduces the problem and record a baseline number.
• Write down the constraints and failed approaches before prompting the agent.
• Point the agent at the benchmark, not at the codebase.
• Run the benchmark yourself on your machine. Never accept the agent's own numbers.
• Expect a correctness bug. Budget review time as the main cost.
• Document exactly what the agent contributed before the work leaves your desk.

The tools will keep changing. The harness is the durable part. Torvalds spent two years failing at this fix by hand, then got a working candidate in days, but only because the benchmark, the profile, and the review discipline were already in place. Hand the same agent to a team with none of those, and you will get fast-looking code and slow software.

I write about AI engineering, developer tools, and the systems behind them every week. Subscribe, it's free, and you will get the next one the day it publishes.

Have you pointed an AI coding agent at a performance problem yet? Did the benchmark come first, or did the diff come first? Tell me what happened in the comments, especially if the numbers did not survive contact with production.