Linus Torvalds submits AI-assisted Linux patches, but review catches a race condition

Linus Torvalds has submitted ten AI-assisted Linux kernel patches for review, turning a longstanding performance problem into a concrete test of AI-supported development. The proposal speeds up a path used when reading file data. Torvalds reports a large synthetic benchmark gain, but warns against expecting that result in real workloads—and reviewers have already found a race condition.

An old problem gets another attempt

The problem arises when many CPUs read the same file and compete over cached data. Tom’s Hardware identifies shared libraries, databases and web servers as places where that pattern can occur. The proposed change targets that contention, rather than claiming to make every Linux operation faster.

This was not a problem Torvalds handed to an AI tool without prior work. He posted an earlier draft in early 2024 and has used it on his own laptop since then, according to Tom’s Hardware. Other developers had also tried different approaches over the years, without arriving at an ideal general solution.

At the recently concluded Maintainers Summit, Torvalds said he had been using a large language model to work on the issue. LWN reported on October 14 that he had now posted the resulting series for review. That submission is a proposed kernel change, not a completed production release.

Changing how reads keep data available

The ten patches change how the kernel handles frequently accessed folios, the objects holding the data involved in these reads. The approach identifies these “hot” folios and delays their release until after an RCU period—a waiting interval used here to keep the data available while it is being accessed.

Linux already uses RCU protection to look up folios. This proposal extends that protection to reading the data itself. On the fast path, it avoids taking a reference count, a step used to track the folio’s use. The change therefore reaches beyond finding the data and into accessing its contents.

That faster route has a specific condition: copying the data to the user must not cause a page fault. LWN describes the benefit as applying when the read can happen entirely inside the RCU-protected region. It is a conditional shortcut, not the removal of reference counting from every read.

23×Torvalds’s reported synthetic benchmark gain

Tom’s Hardware reports a 23× improvement in a dedicated synthetic benchmark. Torvalds cautioned that real-world gains would be much smaller.

LWN characterized the result as an order-of-magnitude speedup on a read-heavy benchmark. Tom’s Hardware’s October 16 account supplied the more specific figure above. Both descriptions concern a targeted test; Torvalds explicitly cautioned that no real workload would see the synthetic result. The number should not be read as a forecast for an entire database or web server.

Review leaves correctness unfinished

The immediate obstacle is the race condition identified during review. LWN reported that the code needs further work. That finding leaves the series at the proposal stage: the performance result does not settle whether the implementation is ready. The identified flaw is in an AI-assisted submission, but its discovery does not establish that AI caused it.

Torvalds’s stated standard for using LLMs remains human responsibility. He has compared them with compilers and editors, saying contributors should do their best and understand what they submit. For this series, the unfinished task is concrete: resolve the review finding before the proposed optimization can be treated as finished work.