Claude Code and Linus Torvalds: the Linux patch tradeoffs

Claude Code helped Linus Torvalds explore a Linux memory-management change, write test programs and draft its explanation. The interesting part is in the cover letter: an experimental patch series reduces the cost of a particular shared-file workload, makes another read path slower and leaves memory accounting unresolved. The work gives reviewers something concrete to examine. It also gives the headline some substantial footnotes. This edition follows the sources reviewed for October 12, 2026.

TL;DR

• Linus credits Claude Code for the code, test programs, review behind his problem list and the first text draft, all under his direction.
• The experimental branch changes how page-cache memory waits before reuse, allowing a read path to avoid shared reference-count updates.
• His laptop test shows about a quarter of the original processor cost for one tiny, contended read workload. No whole-system speedup is established.
• A missing destination user page makes a read more expensive. Waiting memory remains invisible to important allocator accounting.
• The evidence selected here establishes an experiment and a request for review. It establishes no completed mainline merge or shipped kernel change.

What Claude Code did for Linus Torvalds

The primary cover letter is unusually explicit about the assistant's role:

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 supplies both attribution and a boundary. Linus directed the work and ran the measurements. The attribution includes the assistant's review behind the listed problems; that remains part of this author's account. It supplies no separate independent validation of the series.

Anthropic's Claude Code overview describes a tool that can read projects, edit files and run commands. In this case, those capabilities were applied to a specific kernel problem with testable behavior. The assistant also helped produce the prose explaining it. Even the cover letter brought a coding bot to review.

The commit is dated Saturday, October 10. Phoronix's report appeared Sunday evening in America, already Monday in GMT+7. The experimental branch and its eight patches belong to that context. Reading the branch name is a useful first step before treating the headline as a kernel release note.

Why reading cached data can create contention

The cover letter describes many threads making small reads from one file. The file data can already be in the page cache, yet the read still has bookkeeping work around its use of memory.

The existing path takes a reference to the folio and drops it afterwards. A folio is the unit of memory involved in this description. Those operations update its reference count, writing the same struct page line twice per read. Threads sharing the file can therefore compete over the bookkeeping even while their useful work is reading bytes.

In the selected test, several readers repeatedly ask for a tiny piece of one page. The analogy is a library where every reader must update the same sign-out sheet. Reading gets crowded around the sheet before it gets crowded around the book.

The proposed change targets that particular shared cost. That framing matters: identifying a contended counter gives the experiment a mechanism reviewers can inspect. It does not imply that every expensive read in every Linux workload has the same bottleneck.

Linux RCU and the memory-reuse guarantee

The idea is to delay the final freeing of a folio removed from the page cache until an RCU grace period. RCU stands for read-copy-update. In the letter's proposed read path, read-side protection allows the cached data to be copied without acquiring the folio reference for that read.

The lifetime guarantee is about preventing memory reuse during the protected period. The letter explicitly distinguishes that from keeping the reference count above zero. Reclaim, migration and splitting have their own interactions with the count, so replacing that guarantee with a vague promise that the page remains referenced would lose an important detail.

Removal from the cache and recycling the underlying memory are separate events in this design. A removed page can wait before its memory is handed back to the allocator. The read path gets less shared bookkeeping in exchange for obligations elsewhere in memory management.

There are additional constraints. The primary letter describes an existing-path fallback when the new path cannot continue, exclusions from deferral and changes needed around reuse without a free. The episode's two-reader diagram is a conceptual simplification. It represents the relationship; the cover letter supplies the implementation-specific review work.

The benchmark measures one workload on one laptop

The headline comparison uses eight threads reading sixteen bytes from a one-page file. Linus reports kernel cycles per read, explaining that his laptop throttles with temperature and that this cost is more useful for the comparison than reads per second.

Those ranges come directly from the letter. Comparing their midpoints gives about a quarter of the baseline processor cost in this test. The measured result supports that narrow statement. Turning it into a claim that Linux as a whole became four times faster would change the claim's subject, workload and metric all at once.

The machine was an i7-8565U laptop. The letter explicitly says nothing bigger had been measured.

The setup also has a conspicuous scope line:

My laptop only, ext4, mitigations off, CONFIG_HARDENED_USERCOPY off.

This is a reformatted source excerpt from the primary letter. Those settings belong beside the result whenever it is shared. The selected sources provide no independent replication. The experiment is useful evidence about a particular path under stated conditions; broader deployment requires broader evidence.

A missing destination page makes the read slower

The letter supplies a counterexample in the same set of numbers. When the destination user page is absent, the fast path takes a failed exception before the existing path handles the real fault and finishes the read.

For the sixteen-byte, one-thread case, reported cost rises from 4117–4188 to 6543–6593 kernel cycles per read. That is a different workload from the contended eight-thread comparison. It deserves its own row in a review, rather than disappearing behind the favorable chart.

The proposal changes how the paths divide the work. A path that benefits from avoiding reference-count updates can coexist with a path that pays for an unsuccessful attempt first. Reviewers need to understand when each occurs and what the additional cost means for the workloads they care about.

The waiting-memory bill remains unresolved

The open loop in the episode is what happens after a page is removed. Deferring reuse produces memory that is waiting for a grace period. The primary letter lists a remaining problem:

The allocator cannot see the waiting pages. They have refcount 0, are not PageBuddy, are on no pcp list and in no counter.

That accounting gap matters to decisions about available memory. The waiting pages appear in neither the relevant LRU counters nor free-page accounting. A subsystem trying to decide whether reclaim can make progress consequently lacks part of the picture.

The series includes mitigation patches to keep the waiting lists shorter. The letter says they do not make the allocator see the memory on those lists. Shortening a queue and accounting for its contents answer different questions.

There is an important version boundary here. The cited VM reproducer triggers the OOM killer with the earlier first six patches; the eight-patch series runs it to completion. Claiming that the final series simply reproduces that earlier failure would erase the improvement. Claiming that completion resolves the accounting problem would erase the author's remaining warning.

The author also asks for measurements outside the read path. Deferred freeing moves work to another place, including worker execution and locking around queues. Reclaim-heavy and truncate-heavy loads need their own numbers. The bookkeeping has found a new desk; somebody still has to examine the desk.

What a reviewer still needs to prove

The letter records testing that was performed and testing that remains absent. It names other machines, memory-pressure cases, lockdep, KASAN, hardened usercopy and other configurations among the gaps. An assistant generating tests does not establish that every relevant test has been run.

For this experiment, the useful review starts with the lifetime guarantee. Trace the places where cache memory can be removed or reused, then check that the required waiting behavior covers them. Follow the fallback conditions too: a fast path's correctness includes what happens when it stops.

Performance review should keep the favorable shared-read case, the faulting case and the deferred-free cost together. Each answers a different question. A benchmark can demonstrate that an intended optimization is real while leaving its system-wide tradeoff unfinished.

Also in this episode: capability gaps and job decisions

Andrej Karpathy's fresh post revisits an April observation about people having very different experiences of AI capability. He emphasizes access, task scale and verifiable work. His population counts are labelled “napkin math”; the selected post supplies no survey methodology. They should retain that estimate label when quoted.

That argument provides context for the contrast between a chatbot request and a supervised kernel experiment. A task with measurable behavior gives a reviewer different checks to perform. It supplies no guarantee that every ambitious coding task will succeed.

Cendyne's account concerns a different decision. The author says they were the last engineer at an unnamed company, and that cheaper AI assistance gave leadership confidence to coast toward a merger or acquisition. This is an attributed firsthand account of management's bet. It establishes no economy-wide replacement count or independent assessment of that employer's needs. The author says they have found something else.

A staffing decision can happen while arguments about a model's judgment remain unresolved. The consequences land on a person. My joke about the spreadsheet is aimed at the decision-making, never at somebody dealing with a layoff.

Verdict: NEEDS REVIEW

I'd keep the assistant in the workflow and require broader testing before shipping these lifetime changes. The experiment has a mechanism, measurements, a regression and an explicit list of unfinished work. That gives reviewers a starting point. Responsibility stays with the engineer, including responsibility for reading the less exciting section underneath the chart.

FAQ

Did Linus Torvalds use Claude Code to ship a new Linux kernel?

The reviewed sources describe experimental patches and their explanation. They establish no completed mainline merge or production release.

What got about four times cheaper?

Kernel cycles per read in the selected eight-thread, sixteen-byte shared-file test on Linus's laptop. The claim does not describe whole-system performance.

Why does the missing destination-page case matter?

The proposed fast path fails before the existing path takes the real fault, adding work. The letter measures a regression in that case.

Did the final patches solve the waiting-memory problem?

The mitigation patches improve the cited reproducer and shorten waiting lists. The cover letter still lists the allocator's inability to account for waiting memory as unresolved.

Sources

• Linus Torvalds's primary cover letter and measurements
• Experimental noref-filemap-read-with-llm branch
• Phoronix report
• Anthropic's Claude Code overview
• Karpathy's capability-gap post
• Cendyne's firsthand account

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Video transcript and primary sources