Torvalds' page-cache patches hit 23x on a Threadripper before reviewers found a race

The patches remove folio reference-count operations from a common buffered-read path ^[18]. That path was the cost. In eight-thread tests on Torvalds' laptop, Hardware Busters reports, folio reference-count contention made up 99.92% of cross-core load HITMs ^[13]. Matthew Wilcox, an Oracle engineer, flagged the bottleneck in 2024 after it surfaced in a customer workload ^[6].

Dropping the reference count creates its own problem. Something else has to keep the folio from being freed or replaced during the copy. Earlier approaches copied data without holding a reference and checked validity afterward, which left races involving reclamation and replacement ^[8]. The rcu-free-v3 series sets a PG_rcu_free flag and delays reclamation with RCU, so the folio survives the userspace copy, provided the copy does not fault ^[9].

The fault case is the seam. In the first implementation, reads into unmapped user pages took an extra fault before falling back to the existing path ^[21]. Whether that cost persists in rcu-free-v3 is unclear ^[22].

Divide 304 million by 13.3 million and the factor is 22.9 ^[19]. Both numbers come from one 64-thread Threadripper under heavy contention ^[10]. The laptop's first branch went from 10 million to a peak of 33 million, or 3.3x ^[20]. The machines, thread counts and patch revisions differ, so the pair is not a scaling curve. For 23x to transfer, a workload would need many cores reading the same cached files at once through this path, with destination pages already mapped. The report does not include a measurement from the customer workload that started the work.

The reclamation design drew objections. Wilcox questioned the flag and proposed a page type instead, plus reclaiming inactive-list folios after an RCU grace period ^[14]. Torvalds rejected both. He argued that the flag has to be in place for as long as userspace can still map the folio, and that truncate and hole-punch operations fall outside what inactive-list reclamation would handle ^[15]. Hildenbrand, an Arm engineer and memory-management maintainer, supported Shutsemau's suggestion to restrict the flag to 64-bit systems ^[16].

In our view the evidence supports a narrow reading of the human-review point. The human baseline is not clean: Torvalds spent 18 months running a broken version of his own fix, and other developers hit problems with theirs ^[5]. Reclamation and replacement races, the class that defeated those attempts, also reached review in this series ^[3]. The evidence does not show that AI-written code fails more often than human-written code. The report's description of the race breaks off mid-sentence, so how it triggers is not established here.