Re: [PATCH v4 0/2] mm: improve folio refcount scalability

[David Hildenbrand (Arm)]

On 6/23/26 23:23, Ilya Gladyshev wrote:
>>
>> On Sun, Jun 21, 2026 at 09:34:47PM +0000, Gladyshev Ilya wrote:
>>
>>>
>>> June 21, 2026 at 7:46 AM, Linus Torvalds wrote:
>>>  
>>>  On Sat, 20 Jun 2026 at 11:19, <ilya.gladyshev@xxxxxxxxx> wrote:
>>>  
>>>  > 
>>>  > T2: optimistic get() [0 -> 1]
>>>  > T2: put page back [1 -> 0]
>>>  > T2: calls dtor for type X, returns into the allocator
>>>  > 
>>>  Which optimistic getter does this?
>>>  
>>>  If I understood you correctly, you are talking about the scenario where
>>>  an optimistic getter took a refcount on the stolen page, so the validity
>>>  check in the XArray will fail. And this scenario does indeed work normally.
>>>  
>>>  This "ABA" happens if the optimistic getter successfully gets a refcount
>>>  on a valid page, so the full T2 execution looks like this:
>>>  
>>>  T2: optimistic get() [0 -> 1]
>>>  T2: re-checks page [OK]
>>>
>> I don't think that can happen. Or maybe it can and we need to add
>> some barriers. The page is always removed from visibility (whether
>> we're talking about a page cache lookup or a page table lookup), then
>> the refcount is decremented. I hope we have enough barriers in place
>> to ensure that the refcount decrement is observed after the removal of
>> the PTE entry or the XArray entry.
>>
>> But I'm not sure why the folio_put() after a speculative get avoids this
>> problem; why do we need the recheck to be successful to hit this race?
> 
> After additional thought, this race doesn't require speculative gets at all
> and is more about two parallel `folio_puts()`: one successfully deallocates
> the page, and one sleeps for a long time and then calls __folio_put() on a
> "logically new" page.
> 
> And as everybody pointed out, this race isn't something specific to this patch.
> So folio_put() was always ready to be called on non-folio objects due to
> optimistic try_get() + put() in the filecache. We only care about calling
> folio_put() once, and nothing breaks with this patch.
> 
> So thanks to you, Linus, and David, for helping to clarify this :) I'll post
> v5 with more or less cosmetic fixes from the AI review then.

Note that I found an example where I think it might indeed be problematic (the
deconstructor thingy) that might require another look.

-- 
Cheers,

David