Torvalds’ first LLM-assisted patch series: 23 times faster, still with a bug

Summary

Linus Torvalds has published his first patch series created with the help of an AI coding assistant: ten patches meant to solve a scalability problem in reading from the page cache that has been known for years. In an artificial test with 64 threads, reads per second increase 23-fold, which according to Torvalds will be much less in real use. Just a few hours after publication, kernel developer Kiryl Shutsemau found a race condition in review and supplied the fix along with it.

What it is about

When many threads read the same file at the same time, the kernel raises and lowers the reference count of the affected memory page on every read(). These writes to a shared cache line slow down large machines: in Torvalds’ test, throughput plateaus at 13.3 million reads per second, and each read costs around 20,000 processor cycles. Matthew Wilcox had reported in 2024 that real-world applications were hitting this limit.

Several attempts have failed since then: an early draft by Torvalds, which Torvalds used locally for a year and a half until others showed how broken it was, an improved version by Kiryl Shutsemau from October 2025, and a very different approach by Ilya Gladyshev, now at version 6 and with known open problems.

The approach

The new series turns the logic around: a page that leaves the page cache only goes back to the memory allocator after an RCU grace period. As long as a reader is inside the RCU section, the data therefore stays valid, and the kernel can copy directly into the program’s buffer without a reference count. Instead of detecting invalid states afterwards, the series prevents them from arising at all.

The result on a Threadripper with 64 threads: 304 instead of 13.3 million reads per second and around 735 instead of 20,000 cycles per read. On a laptop with eight threads, throughput rose from about 10 to 30 to 33 million. Torvalds stresses that the test is artificial: the same few bytes, read over and over by all cores.

How the AI was used

The work was done for the 2026 Maintainers Summit, where the use of language models in kernel development was a major topic. Torvalds wanted to show that a real, unsolved problem could be tackled this way, and kept a simpler clean-up of the assoc-array library ready as a fallback.

The description of the first development branch states that the code, the test programs, the review behind the list of open problems and the first draft of the text were done with the coding assistant Claude Code under Torvalds’ direction, while the measurements ran on Torvalds’ own machine. Each of the ten commits carries the line “Assisted-by: LLM”, and two of them are by Kiryl Shutsemau. According to Torvalds, the commit messages turned out more verbose than Torvalds would have written them, but maybe that is better.

What the review shows

About four hours after Torvalds’ mail, Kiryl Shutsemau described a race condition: if a page is removed from the cache during a read, the cache is repopulated and the file is extended, a reader can get data from the old page that was never written. The fix consists of two lines that check, after reading the file size, whether the page is still in the cache.

The cover description also lists ten open points itself: the memory allocator cannot see the waiting pages, a test program by Kiryl Shutsemau drove a VM into the OOM killer this way, CMA allocations fail, and testing was done on a single machine only, without xfstests, KASAN or lockdep. The series is therefore a basis for discussion, not a finished patch for the next kernel.

Ideas

• Free pages only after an RCU grace period so that readers need no reference count.
• Prevent error cases instead of detecting them after the copy.
• Only “hot” pages that are read again and again take the fast path.
• Write known weaknesses honestly into the patch description so reviewers can search in a targeted way.
• Label AI-assisted commits openly with “Assisted-by”.

Insights

• A language model can help an experienced developer tackle a problem that has been open for years, but it does not replace review by experts.
• Especially with concurrency, people with deep knowledge of the code find bugs that both author and tool missed.
• Transparency about tool use makes AI contributions verifiable rather than suspicious.

Facts

• In the 64-thread test, reads rose from 13.3 to 304 million per second.
• The rcu-free-v3 series consists of ten patches; two of them are by Kiryl Shutsemau.
• From 1024 waiting pages per CPU, the series forces an expedited RCU grace period; according to the description, the limit is a guess.
• The fix for the race condition proposed by Kiryl Shutsemau comprises two lines in mm/filemap.c.

References

• LWN.net: Linus Torvalds's first LLM-assisted patch series
• Linus Torvalds: Improve page refcount scalability (LKML)
• Kiryl Shutsemau: race in filemap_read_rcu_batch() (LKML)
• Git branch rcu-free-v3 in Linus Torvalds’ kernel tree
• Hacker News: discussion of Torvalds’ first LLM-assisted patch series

Critique

• The figure of 23 comes from a deliberately artificial test; how much real workloads gain has not been measured.

Remarks

• This article was also created with Claude Code; the sources were read directly from the kernel mailing list and Torvalds’ Git tree.
• LWN’s report on the 2026 Maintainers Summit is only available to subscribers until 22 October 2026.

Recommendations

• Review AI-assisted changes as strictly as any other, especially where concurrency is involved.
• Label openly in your own projects where a language model was involved.
• Always read benchmark figures together with the test setup: artificial peak values say little about everyday use.

Read the original article →

Search the Web Archive

Links to the original source and the Web Archive open in a new tab.