The father of Linux has also started using AI to write kernel code. He once ridiculed AI as being "90% marketing", and now he has written 8 patches with Claude Code, bringing a threefold surge in performance.

"I used to think AI was nothing special, but now, I really love using it." — The person who said this is not a young coder who just entered the industry and is obsessed with Vibe Coding, but Linus Torvalds, the father of Linux.

Recently, a rather unusual branch named noref-filemap-read-with-llm appeared in the Linux kernel code repository.

For those familiar with Linux development, the emergence of a new branch in the code repository of Linus Torvalds, the father of Linux, is noteworthy in itself; and this time, the end of the branch name is directly marked with llm — Large Language Model.

On October 10, Linus Torvalds submitted a change titled "mm: read from the page cache without folio references" in his own Linux kernel repository. The related patch soon attracted the attention of the developer community: this experimental scheme consisting of 8 patches not only targets a long-standing performance bottleneck in the Linux kernel, but also explicitly and publicly discloses the participation of the AI programming tool Claude Code.

Interestingly, the test results given by this set of patches are also quite impressive: in a specific 8-thread file reading test, the throughput increased from about 10 million times per second to a maximum of about 33 million times, with an improvement of more than 3 times — however, don't rush to think that AI can independently develop operating systems yet. This patch is still in the experimental stage at present, and the performance improvement has a clear scope of application.

8 Patches Target a Problem That Has Plagued Linux for More Than Two Years

This optimization targets the page cache of Linux.

Simply put, Linux caches the read file data in memory. When the program accesses these data again, the operating system can read directly from the memory, reducing the overhead of accessing storage devices. However, when multiple threads read a small amount of data from the same file at the same time, an unexpected bottleneck may appear in the page cache: memory reference count competition.

To ensure that the data will not be released in advance when it is in use, the kernel needs to track the memory object that carries the file data, that is, folio. The traditional reading path will increment the reference count of folio, and decrement it after the reading is completed. The problem is that these operations involve atomic instructions: when multiple threads repeatedly modify the same counter, the processor cores need to continuously coordinate the consistency of cached data, resulting in additional overhead.

If the amount of data read each time is large, these additional overheads may not be so obvious; but if only 16 bytes are read each time, the overhead spent maintaining the reference count will far exceed the cost of actually reading the data.

This is not a small problem that Linus discovered temporarily. As early as 2024, kernel developer Matthew Wilcox had proposed this performance bottleneck — only this time, Linus decided to solve this problem with the help of Claude Code.

Let AI Help Modify Code, Multi-threaded Read Performance is Directly Increased by 3 Times

To verify the optimization effect, Linus conducted tests on his own laptop:

The device is equipped with an Intel Core i7-8565U processor, with 4 physical cores and 8 threads; when 8 threads simultaneously issue 16-byte pread() read requests to the same file page, the performance analysis results show that among the HITM (hit modified cache line) events related to cross-core load, 99.92% are concentrated on the relevant shared cache line.

That means, a large amount of cross-core coordination overhead in the test is related to this shared cache line.

To solve this problem, Linus and Claude Code tried a different processing method — the key to the new solution is to use the RCU (Read-Copy-Update) mechanism to adjust when the kernel can reuse the memory removed from the page cache.

Originally, the read path needs to frequently acquire and release the reference of folio. The new solution allows the relevant memory to be returned to the allocator with a delay until the end of the RCU grace period. In this way, in the code segment protected by the RCU read side, the reading thread can directly copy the data to the user space buffer without repeatedly updating the shared reference count.

In layman's terms, it is to avoid the process of multiple threads repeatedly competing for the same counter as much as possible to reduce unnecessary coordination overhead. With such optimization, the test data shows obvious differences:

In the 8-thread concurrent reading scenario, the throughput increased from about 9.9 million to 10.4 million times per second to about 30 million to 33 million times per second.

The kernel CPU cycles required for each read also dropped from about 2950 to 725.

In the single-threaded scenario, the benefit is not that dramatic: the CPU cycles required for each read dropped from about 452 to 454 to 408 to 409.

From these data, the performance benefit is mainly concentrated in the multi-threaded concurrent reading scenario. Because the original maximum overhead comes from multiple threads competing for shared cache lines, after reducing such competition, the improvement in concurrent scenarios is naturally more obvious. Linus also pointed out in the submission note that if a machine with more CPU cores or a multi-socket architecture is used, greater benefits may theoretically be obtained.

In addition, "3 times performance improvement" does not mean that the overall running speed of Linux has increased by 3 times, which is only the test result under the specific hardware, file system and small block read load.

Not Only Writing Code, Claude Code Also Participates in Testing and Review Materials

Compared with the performance figures, what actually attracts more developers' attention is Linus's public statement on AI participating in development. He wrote in the Git commit:

"The above code, test programs, reviews around relevant content, and the first draft of this explanatory text were all completed under my guidance with the help of Claude Code, a large language model programming assistant."

That means, Claude Code is not only involved in the generation of a few lines of code, but covers multiple links such as implementation schemes, test programs, review materials, and the first draft of submission documents. However, this does not mean that Linus handed over the entire development task to AI and ignored it: relevant tests still need to be executed, performance data needs to be verified, and problems in the code also need further review.

In fact, there are still obvious unresolved problems in this set of patches:

First, delayed memory reuse means that some memory pages need to wait for the end of the RCU grace period before they can be reused, which may increase the pressure of memory reclamation. Linus himself also admitted that memory reclamation is the most poorly solved part of the whole set of patches.

Second, when the read target is a page that has not been mapped to the user space, the new path will additionally trigger a failed exception handling, and then fall back to the original implementation. In related tests, this situation can even lead to a significant drop in performance.

Therefore, although this set of patches has achieved significant benefits in specific scenarios, it cannot yet be regarded as a completed optimization. Up to now, this set of patches still stays in the experimental branch and has not been merged into the Linux mainline. Whether it can be accepted in the end requires further review and verification.

From Questioning That AI is "90% Marketing" to Personally Using AI to Write Kernel Code

The reason why this submission attracted attention this time is also because the person who used Claude Code is Linus Torvalds.

Looking back over the past few years, Linus's attitude towards AI has actually changed significantly:

At the end of 2024, he sharply criticized the AI industry, saying that "90% of it is marketing". At that time, his attitude towards AI was relatively cautious, and he paid more attention to whether it could help developers find bugs, rather than directly writing important software code.

By the end of 2025, he began to recognize the value of AI in code maintenance, patch review and other aspects.

In January this year, he tried AI-assisted programming in his amateur project, writing code for a Python audio visualization tool.

Last week, when he talked with his friend Dirk Hohndel at the European Open Source Summit, he even said that he had changed from thinking AI was "nothing special" in the past to "really loving using AI". He also mentioned that AI can help developers complete work that they are not good at. However, he also reminded that when facing really important software development, one must be extremely careful when using AI.

Now, this set of kernel patches has made Linus's attitude more concretely reflected: AI is no longer just a tool for assisting in troubleshooting bugs and reviewing patches, but has begun to participate in the implementation of new code for the Linux kernel.

Not only that, not long ago Linus also used LLM to help sort out another long-standing, hard-to-understand piece of kernel code: in the related assoc_array code sorting work, AI assisted him to disassemble complex functions and prepare user-mode tests, and finally found 3 bugs that can be traced back to 2013.

But whether it is discovering old bugs or optimizing page cache reading, it is ultimately inseparable from testing and manual review — after all, for basic software like Linux, whether the code can run is only the first step. Whether it is correct, whether it introduces regression, and whether it is applicable to different hardware and workloads must all be verified.

Reference links:

https://www.zdnet.com/innovation/linus-torvalds-uses-ai-to-write-linux-kernel-patch/

https://www.zdnet.com/tech/linus-torvalds-ai-coding-programming/

This article is from the WeChat official account "CSDN", author: Zheng Liyuan, authorized for release by 36Kr.