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

[Linus Torvalds <torvalds@linuxfoundation.org>]

On Sun, 1 Mar 2026 at 13:16, Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
>
> Ho humm. Maybe that "locked" flag is the best we can do.

Coming back to this after having spent a few days mulling it all.

End result: I do think that the locked bit is the right solution, and
you can add my "Acked-by" to the series.

I do have a couple of requests (the ack is not conditional on these,
but having looked at the patch it's what my reactions were):

 (a) please rename "page_ref_add_unless_zero()" and friends, since
that's not what they do any more. Now it is
"page_ref_add_unless_locked()"

 (b) verify and add a comment somewhere that the PAGEREF_LOCKED_BIT on
a free'd folio is never removed until the page ref is set to 1 by the
next allocation by set_pages_refcounted()

I'm asking for that (b) because if it is ever set back to zero, this
all fails, because the fixup for the atomic_add_return() might do a
atomic_dec() - if it never saw the PAGEREF_LOCKED_BIT - and free a
page twice after all.

(And if I missed some reason why (b) isn't true, please holler).

Anyway, I like it. My initial reaction was that it was complicated,
but in the end I think that was just because it was done a bit
differently from what I was used to in how we did the DEAD flag for
dentries, but I think this is actually the better model (*).

                   Linus

(*) For dentries we use that lockref thing which has its own
complications with the spinlock acting as the lock bit for the
refcount, and it uses the cmpxchg loop to synchronize things because
it wants that lock to be absolute. But I think the page count approach
is actually better in being more flexible.