The father of Linux has completely dived into the AI field, writing kernel code with Claude Code, leading to a 3-fold surge in performance.

I have never seen such a thing in my life!

Even the father of Linux is now using Claude to write kernel code.

Just recently, a developer refreshing Linus's official kernel repository stumbled upon a highly unusual new branch —

noref-filemap-read-with-llm

Yes, the suffix "-with-llm" of this branch clearly indicates that AI was involved in this project.

Who would have thought that Linus, who is always the harshest critic of bad code, would take the lead in using AI to write code this time!

In the latest patch notes, he openly admitted that:

From the core code, test cases, to change reviews and draft documentation, all of them were completed by him working directly with Claude Code.

The running results are indeed outstanding. In a specific test where 8 threads read the same file, the throughput reached approximately 3 times the original level.

The man who once said "90% of AI is marketing" has now been proven to have changed his stance.

Linus's brand new branch with "llm" directly in its name

This time, the part Linus directed Claude Code to modify is exactly the most core "memory management" mechanism of Linux.

The Linux kernel uses page cache to cache file data.

In daily multi-concurrency business scenarios, a common operation is that multiple threads simultaneously read the same file in small chunks.

According to the existing mechanism, each read operation must modify the atomic reference count on the corresponding memory block (folio).

This leads to frequent execution of lock cmpxchg and lock decl instructions between CPU cores, causing severe cache line thrashing at the hardware level.

Back in 2024, core kernel developer Matthew Wilcox pointed out this persistent problem from the production environment of real customers.

On Linus's own test machine, when 8 threads perform concurrent small read operations, this bottleneck accounts for 99.92% of all "Load HITMs" overhead, almost consuming the full bus bandwidth of the CPU.

The work assigned to Claude also goes far beyond the stage of "adding a few lines of code".

It participated in implementing the solution, writing programs to verify the scheme, and helping to sort out potential problems.

All these links connected together form a complete engineering attempt. The code written must be runnable, the running results must be measurable, and the measured performance improvement must be explainable.

The patch notes also have practical purposes. Other maintainers need to know why the changes are made, which paths are affected, and which scenarios the author has checked.

After AI writes the first draft, the notes still need to be consistent with the code and test data.

Only when the information is made public to this extent can subsequent discussions have a clear basis. That's the weight of Linus's phrase "under my guidance".

Throughput skyrockets from 10 million to 33 million

In the test, Linus used a laptop equipped with Core i7-8565U, 4 cores and 8 threads, with ext4 as the file system.

The test made multiple threads repeatedly read the same file with a size of one page, and only read 16 bytes each time.

The data given in the patch notes is as follows:

The 8-thread throughput is about 3 times the original level, and the single-thread performance improvement is about 10%.

Why is the gap so big? The key lies in the scenario where "everyone reads the same file".

Linux caches file data in memory, which is the page cache. Subsequent reads can directly fetch data from the cache, eliminating the time to access the storage device again.

However, the memory in the cache will also be reclaimed. The kernel must ensure that when a thread is still reading, this piece of memory is not released and allocated for other purposes.

The original read path will increment the reference count of the memory object carrying the cached data, and decrement it after the read is completed. This object is called folio, which can be understood as a set of memory pages managed by the kernel.

The problem is that when several threads read at the same time, they will repeatedly modify the same count.

To maintain data consistency, cache lines containing this count need to be passed back and forth between processor cores. Each read operation only takes 16 bytes, the read itself is very fast, but the overhead of maintaining the count becomes the bottleneck.

It's like eight people are all flipping through the same book, and before and after each page flip, they have to compete to modify the same registration form.

Linus's set of patches tries to eliminate this step on the read path.

The approach is: after the memory in the cache is removed, delay for a period of time before actually returning it to the memory allocator. With the help of the RCU mechanism, ongoing related read operations can complete successfully.

In this way, threads can directly copy data within the protected read interval, reducing contention for the shared reference count.

This also explains why the performance gain is particularly obvious in the test where multiple threads share the same file.

Following a bug, AI also dug up a decade-old problem

If you think Linus only asked Claude to write new code, you have underestimated the significance of this incident.

The day after the noref-filemap-read-with-llm branch appeared, another assoc-array-fixes library popped up in Linus's repository.

It is a data structure used to organize and find objects by keys. Its initial implementation can be traced back to 2013.

A few days ago, developer Nils Ollrogge submitted a bug report and also provided a fix patch.

After Linus reviewed it, he encountered a problem: this piece of code is too obscure to sort out the logic clearly.

Therefore, he used large language model to sort out the code, split some huge and hard-to-read functions, and make the boundaries of different operations clearer. Later, these codes were put into the user-mode test framework to run.

The test confirmed the problem reported by Nils, and also found 3 additional bugs.

All four bugs can be traced back to the commit in 2013 when this library was first merged into the kernel.

Who could have imagined that a bug report would uncover three more defects that have existed for more than ten years.

One specific example is: when a certain root node structure is split, the bit field used for indexing will be misaligned, resulting in the originally stored objects can no longer be found.

The patch notes give an example that can be triggered with only 18 keys.

After the operation is completed, 3 of the objects cannot be found; inserting the same key again will add a new object instead of correctly replacing the original one.

Another problem is hidden in the path of memory allocation failure.

When running normally, it may stay quiet. Once an allocation fails, the cleanup logic may follow the pointer to the old tree that is still in use, triggering the kernel error check.

The corresponding test makes each memory allocation in the operation fail in turn, and checks each abnormal branch one by one to expose this problem.

These findings give "AI helping to review code" a more specific meaning.

After old code is split and explained, it becomes easier to track; tests then force out those paths that are rarely executed in normal scenarios.

Thus, reproducible evidence of defects is obtained.

Even the top master has joined the trend, programmers should put away their sense of superiority

Linus Torvalds once said a very classic sentence: "Talk is cheap. Show me the code."

People who know him know that he is an extreme pragmatist, and he only cares about two things: is the cost worth it? Is the effect good enough?

This time, he used his actions to show another possibility —

When code can be written by AI, what is really valuable is knowing what code to write, and judging whether the written code is correct.

The man who once said "90% of AI is marketing" now hangs a branch with the "llm" suffix in his main repository.

Even the founding father is using AI to boost his work efficiency, who is still clinging to the vanity of manually writing every line of code?

References:

https://www.phoronix.com/news/Linus-Torvalds-Claude-Code

This article is from the WeChat official account AI Era, author: ASI Revelation, published with authorization from 36Kr.