The striking GUP result belongs to one memory configuration in a contributor benchmark. The adjacent control cases explain the mechanism more clearly than the largest multiplier alone.
Two optimizations with a shared baseline
Rik van Riel’s RFC v3 overview proposes walking multiple page-table entries per call, then batching reference handling for consecutive pages in the same folio. The distinction matters: walking several entries can help base pages, while same-folio batching needs a suitable larger folio.
The seventh patch reports 64 kB mTHP lookup time falling from 2,946 to 1,361 microseconds. The eighth patch reports 2,946 to 231 microseconds for the combined work. Both tables compare against the series’ original base; the second does not start from 1,361.
The author measured median get time over sixteen iterations for a 256 MB region in a four-CPU VM. The 2 MB THP control changes only from 72 to 71 microseconds in the final table. These are author measurements, not a reproduction by PeopleAreGeek.
Read the arithmetic without double counting
Using the published times, the total ratio is 2,946 ÷ 231, about 12.75×. The additional ratio after the first optimization is 1,361 ÷ 231, about 5.89×. Multiplying 2,946 ÷ 1,361 by 2,946 ÷ 231 would count the first improvement twice.
Our cover plots the three times on the same scale. The nearly unchanged 2 MB control is important: a path that does not encounter the same repeated work cannot be assumed to receive the same benefit.
Proposal status and application relevance
The v7.3-rc2 GUP source still has the single-page return signature for follow_page_mask. The discussed RFC transformation is not established in that mainline snapshot.
An application also spends time elsewhere. In a fictional ten-second setup with two seconds in this path and eight unchanged, applying the measured ratio only to those two seconds would produce about 8.16 seconds, not 0.78. This extrapolation is illustrative, not a workload forecast.
Measure the actual page configuration and share of time before predicting a benefit. A microbenchmark result is evidence for a specific mechanism and setup, not a universal ceiling or guaranteed speedup for memory registration.
Read exact RFC benchmark tables and source state; separate shared baseline, folio size and whole-application effects.