Re: [PATCH v6 3/3] mm: implement page refcount locking via dedicated bit

[Ilya Gladyshev <ilya.gladyshev@linux.dev>]

On 9/25/26 22:00, Linus Torvalds wrote:
 > On Fri, 25 Sept 2026 at 00:03, Ilya Gladyshev 
<ilya.gladyshev@linux.dev> wrote:
 >>
 >> Hmmm, I’m afraid that since you need CAS for a safe 1->FR transition,
 >> it will result in a CAS loop for the decrement itself (like in
 >> atomic_sub_unless). And this will introduce scalability issues just like
 >> in folio_try_get(), but this time for everyone...
 >
 > Note that we could make that CAS case be the thing that only the
 > special cases do.
 >
 > IOW, maybe only do that slow sequence in compaction_free() and the
 > memory offlining.
 >
 > So we'd have two different cases:
 >
 >   - the high-performance case is ready and willing to accept the "sees
 > zero" window and the extra 0->FR state that can race with somebody
 > else taking an optimistic ref
 >
 >   - the unusual slow cases that are *not* willing to deal with
 > optimistic ref takers do the "CAS 1 -> FR" state atomically and always
 > use compare-and-exchange for their freeing path
 >
 > That actually sounds like a good approach to me.

Cool idea, thanks!

This, however, will still require converting all page_frag_free()
callers to use the generic dispatching dtor (which is __folio_put()
for now), right?

---

Beyond that, I see two trade-offs with my patchset. Neither seems
important for the current kernel code, but I'd like to outline them
anyway.

1. We lose the "high-performance + custom deallocation" scenario

For example, in cases where the current refcount allows you to write
the following:

if (!put_page_testzero()) {
   /* We failed to steal the last refcount. However, our refcount is
    * already decremented, and therefore we can move forward -- the one
    * who stole our page will free it via the generic dispatching dtor.
    */
}

The proposed refcount impl will require either a slow decrement or a
proper (slow) deallocation when put_page_testzero() succeeds. So,
basically, the compaction_free() scenario but with a performance
requirement.

2. Page deallocation becomes unpredictable

With the current refcount impl, if you work with a page of "type X",
you can be sure that folio_put() will perform X-specific actions on
it, and you can make implicit assumptions based on that. This is no
longer true for fast decrements.

---
Ilya Gladyshev // foxido.dev