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

[Gladyshev Ilya]

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]
T2: *normally works with this page*
T2: frees page [1 -> 0 -> FROZEN]
T2: calls dtor for type X, returns into the allocator

... T3 reuses the page, T1 wakes up and conflicts ...

T1 basically needs to sleep for a veeery long time to miss full T2 & T3
execution. 

> I didn't go back and look at the series, but isn't the rule that the code does:
> 
>  - optimistic get
> 
>  - then check that the folio is still valid (*not* using the page
> count, but by re-looking it up elsewhere, typically the address space
> mapping)
> 
>  - put the page if it wasn't valid
> 
>  - if it goes to zero, there's no destructor inherent in that
> 
>  - everybody who sees it go to zero - optimistic or not - does the
> "zero to frozen" cmpxchg

The problem is -- the zero you've seen and zero you are trying to CAS
can be different zeros if the page gets reused fast enough.
(Or couldn't and I am just confused :) )

>  - only *one* of those will succeed, and *THAT* triggers the destructor
>
>
> IOW, the transition to zero is not special per se and has no
> destructor. All it triggers is the "now we try to mark it frozen"
> phase.
> 
> At least that was my mental picture.
> 
> Was I wrong? Am I just confused? Wouldn't be the first time.
> 
>  Linus
>