Re: Improve page refcount scalability

["David Hildenbrand (Arm)" <david@kernel.org>]

On 10/14/26 12:36, Kiryl Shutsemau wrote:
> On Tue, Oct 13, 2026 at 10:03:12PM +0100, Matthew Wilcox wrote:
>> On Tue, Oct 13, 2026 at 11:43:14AM -0700, Linus Torvalds wrote:
>>> The fairly short series of ten patches basically enhances folio lookup
>>> by noticing when folios are hot, and setting a "delay relasing this
>>> folio until after a RCU period", and then using that RCU delay it does
>>> not just the folio lookup itself under RCU (which we've done forever),
>>> but also the actual folio data accesses themselves under RCU. No
>>> refcount taking needed for the fastpath where we can just read the
>>> data from the folio entirely in an RCU-protected region when the user
>>> copy doesn't cause page faults.
>>>
>>> Unlike my original approach - because it now actually delays the
>>> freeing of the underlying folio data - there's no need for any double
>>> buffering, and a lot of the original limitations of my original patch
>>> go away too. That improves performance quite a lot. And by "quite a
>>> lot"  I mean "I see a 23x performance increase on my Ryzen
>>> threadripper". Admittedly that is a very artificial case of reading
>>> the same small part of a page over and over in a threaded loop on all
>>> CPUs, so any real life impact will be much much less.
>>>
>>> Anyway, I wasn't planning on posting the individual patches, I think
>>> we all use git by now and probably find it easier than fetching
>>> patches from the list. So it's all at
>>>
>>>     git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux rcu-free-v3
>>>
>>> and the commit messages are a bit more verbose than I would have done
>>> it myself without tool use, but maybe it's better that way.
>>
>> Obviously the numbers are compelling.  And thanks to Kiryl for figuring
>> out a workload that confirmed my fears, then remedying the problem.
>>
>> I don't like the PG_rcu_free flag.
> 
> I wonder if you would be okay with a 64-bit-only flag? Those are less
> scarce. That's the direction I was looking at:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?id=59b23fdc4bb0d008e2a30d24156177eeede8a577
> 
> I don't think we care about the scalability of 32-bit machines here.

I think limiting this functionality to 64bit makes a lot of sense.

-- 
Cheers,

David