Torvalds’ AI-assisted Linux experiment has a second bill: memory

A Linux experiment targets a surprisingly small bottleneck: many threads reading the same file keep contending over reference-counting bookkeeping. Phoronix reported on October 11 that it had discovered a newly appeared branch in Linus Torvalds’ repository. Torvalds says he used Claude Code under his direction for the work. [1] [2]

For a business whose software really hits this bottleneck, the prize could be more work from existing hardware. Less computing time spent on bookkeeping might free capacity for useful tasks. But a faster read is only one part of the bill. If the change leaves memory waiting longer to be reused or creates extra work elsewhere, an apparent saving could become a different operating cost.

The proposal reads from the page cache—file data kept in memory—without taking the usual references. Instead, removed memory returns to the allocator only after an RCU grace period, a waiting interval intended to protect ongoing readers. The trade-off is repeated bookkeeping during reads versus delayed memory reuse. [1] [2]

In Torvalds’ eight-thread test of tiny, 16-byte reads from one cached file, the reported kernel CPU cycles per read fell from 2,937–2,975 to 725–726. These were his laptop measurements, not an independent replication. He used the ext4 filesystem with CPU mitigations and hardened user-copy protection disabled. [2]

That result makes the mechanism worth examining; it does not price a production service. Read-path cycles are not total workload time, energy use or cloud spending. A hypothetical operator would need to compare completed application work on the same hardware, including memory management and background workers. Otherwise, moving work out of the measured path could look like removing it.

Torvalds’ cover message identifies costs and failures alongside the gains. The allocator cannot see pages waiting to be reused. He describes a regression affecting contiguous memory allocation and says costs outside the read path have not been measured. Reads into missing destination pages also incur an extra failed exception. [2]

The AI-assisted workflow is interesting for engineering teams, but the record does not measure hours saved. Producing code, tests and a review under an experienced developer’s direction is different from proving that an assistant reduces the total work of maintenance. Debugging, broader testing and deciding whether a risky change belongs in a release still matter.

The cover-message commit is dated October 10. Phoronix’s discovery report appeared on October 11. Its account describes an experimental branch and a possible future merge, not a released improvement. The earlier authorship date and the later discovery report describe different stages of the same work. [2] [1]

The strongest rival explanation is that this is a genuine narrow optimization, but its benefit disappears once deferred freeing, memory pressure and less favorable reads are included. The positive interpretation would strengthen if independent, representative tests showed more completed work with acceptable memory use. It would weaken if the whole workload slowed, failures increased or extra memory erased the capacity gain.

Watch the next revision’s treatment of waiting-page accounting and contiguous allocation, then independent whole-workload tests with protections enabled. Useful measurements would pair computing time per completed job with peak waiting memory and failures under pressure. Those tests could distinguish a smaller bill from one shifted between reads, memory and background work. A merge would be a separate adoption milestone, not proof of savings.