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

[Linus Torvalds]

On Sun, 21 Jun 2026 at 14:34, Gladyshev Ilya <ilya.gladyshev@xxxxxxxxx> wrote:
>
> >  - 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.

I don't think re-using the page matters.

As mentioned, the only thing that matters is that only *one* entity
does the destructor, and does it using the data *from*the*page*.

IOW, for an optimistic failure case, you can't decide "I failed to get
this page for my use XYZ, so I'll use the destructor for XYZ".  You
need to go "I failed to get the page for my use XYZ, so I'll use the
destructor for this *page*".

I think we do that anyway, but yes, it's worth making explicit.

And if it wasn't an optimistic failure, but a success - then it
doesn't even matter.

Because even if it was released and re-used, the definition of a
success must involve having checked that the page matched your use
XYZ.

IOW, let's say that you *successfully* did the 0->1 transition, amnd
after doing that transition you checked "yes, that page is still in
the radix tree".

Then it simply is entirely immaterial if your success was because the
page was released and then immediately re-used for the same thing.

It doesn't matter that you didn't notice that it might have gone
through a FROZEN state, and then been re-allocated and put back in the
tree: the end result is 100% the same.

Yes, between you looked up the page optimistically the first time,
somebody could have done all the work to put it back in the page
allocator structures, and then somebody else would have re-allocated
it again and taken it off the page allocation structures and put it
back into the page cache radix tree and might be in the process of
being free'd *again*.

And then you come along later - after you were interrupted by a VM
delay or whatever - and now you check the radix tree and you see "ok,
same page, still there, optimistic lookup successful", and you don't
even *realize* that it was free'd and re-allocated in the meantime.
But none of that actually matters. Your lookup was a success, you
updated the count from 0->1, and that page is valid and all is fine.

So I think that yes, there's a kind of ABA thing there, but that just
doesn't matter. The whole point of "re-check after you got the
reference" is literally to check that the optimistic page that was
looked up is good to go. And it is, even if it might have had
something else going on just before.

             Linus