Torvalds Creates Linux Speed-Boost Patch with Claude Code | ~3x Read Performance
機械翻訳 / Machine-translated

機械翻訳 / Machine-translated
@aifriends
AI Friends(https://aifriends.jp)のクロスポスト公式アカウント。AIツールの紹介・使い方・できることを、中学生でもわかるやさしい日本語で届けます。
Has AI made its way even into what is considered one of the world's most rigorous open-source development environments? The creator of Linux has revealed that he used Claude Code in his own branch, reporting a roughly 3x speed improvement. Let's look at what happened and how much we can trust these results.
Around October 12, 2026, Linus Torvalds published a branch called noref-filemap-read-with-llm in his Linux tree.
According to Hardware Busters, the branch contains a series of 8 patches. Torvalds himself wrote in the cover letter that Claude Code wrote the code and tests, and also drafted the explanatory text.
The cover letter states that the work was done "under my direction" and that measurements were run "on my machine." It was first spotted by a Phoronix reporter and subsequently picked up by multiple media outlets.
The code sits on top of Linux 7.3-rc6 and has not yet been officially merged.
A computer keeps the contents of files it has already read in memory. This way, the next time the same file is read, the system doesn't have to fetch it from storage. This mechanism is the page cache.
Most file reads in Linux pass through this mechanism, so even a small improvement here can affect server performance.
The issue arose when multiple threads (units of work running concurrently) each read small pieces of the same file.
With each read, every thread increments and decrements a counter tracking "how many users are currently accessing this data" (a reference counter). Since all threads modify the same counter, CPU cores end up competing for the same area of memory.
According to Hardware Busters, in a test reading 16 bytes at a time across 8 threads, 99.92% of inter-core conflicts were caused by this contention.
The new approach doesn't touch the counter during reads. Instead, it uses RCU (a mechanism that avoids stalling readers and handles cleanup safely in bulk afterward).
Data evicted from the cache is not freed immediately. It is returned to memory only after all readers have finished passing through it.
A safety valve is also included: if more than 1,024 pages are queued for release on a single CPU, an urgent cleanup is triggered.
The measurements were taken on Torvalds' Core i7-8565U laptop (4 cores, 8 threads). The figures from Hardware Busters are as follows:
Conflicts were reduced to roughly 1/300th of the original. This aligns with the explanation that contention decreased.
However, this is a specialized test in which 8 threads simultaneously perform extremely small 16-byte reads on the same file. It does not mean that overall server performance will triple.
The cover letter also describes what doesn't work well. A DEV Community analysis article also addresses these points.
First, there are cases where performance degrades. When reading into memory regions that have not yet been allocated, the operation fails once and then retries via the conventional path. Single-threaded 16-byte reads increased from approximately 4,150 cycles to approximately 6,550 cycles.
Second, memory release is delayed. Pages queued for release do not appear in memory management's available capacity figures. According to Hardware Busters, Torvalds himself identifies this as the most unresolved aspect.
In fact, during stress testing on a 2GiB virtual machine, the 6-patch version triggered the OOM killer (which forcibly terminates running processes when memory runs out) with 4 and 8 CPUs. The full 8-patch version reportedly completed without issue.
Third, testing is insufficient. Measurements were taken on only one laptop, and verification under other hardware configurations or low-memory conditions has yet to be done. Independent reproduction has not occurred yet either.
Next, let's look at the rules around AI usage. The Linux kernel has an official document governing how patches involving AI are handled. According to ITsFoss, it was introduced in Linux 7.0.
It covers three points:
In other words, AI use is not prohibited. However, responsibility for the result always rests with the human submitter.
Comparing this with the traditional approach makes the difference clear:
It is also worth noting that according to Startup Fortune, in October 2024 Torvalds described 90% of AI talk as hype. In July 2026, he wrote that "Linux is not an anti-AI project." His position has shifted considerably.
Linux runs across a wide range of environments in Japan too — web services, cloud infrastructure, factory equipment, and smartphones. If kernel read performance improves, Japanese users may also benefit.
Consider an infrastructure manager at a small or medium-sized company. Suppose many processes on their servers are reading the same configuration file. If an improvement like this is officially merged, the load might decrease without any configuration changes.
For development teams, the approach itself may be more instructive. The process of having AI write code, having humans measure it, and publishing even the weaknesses provides a useful reference when establishing in-house development rules.
For example, rules like "document where AI was used" and "ensure a human is always the responsible party" could be adopted immediately.
That said, kernel changes have a broad impact and have not yet been merged. This is not something to deploy in production environments right now.
No. It has not been merged yet. It is an experimental branch built on top of Linux 7.3-rc6. Whether it will be included in the next development cycle (7.4) is also not yet clear.
Under specific test conditions, reads per second roughly tripled. However, this was under a scenario of small reads performed by 8 threads on the same file, and the results are from a single laptop. In real-world usage, the improvement is likely to be more modest.
In the kernel, the human submitter bears full responsibility regardless of whether AI wrote the code. In this case, Torvalds measured the results himself and published the patch along with a clear description of its weaknesses. It cannot be called safe until it passes review and additional testing.
It is a marker added to patches where AI provided assistance. The format is Assisted-by: AGENT_NAME:MODEL_VERSION, and the tools used can also be listed. It is based on the idea of treating AI as a tool rather than a co-author.
As a next step, try establishing at least one rule within your own team: "document where AI was used and designate a responsible person."
This article is a cross-post from AI Friends.