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

[Ilya Gladyshev]

On 9/25/26 22:00, Linus Torvalds wrote:
> On Fri, 25 Sept 2026 at 00:03, Ilya Gladyshev 
<ilya.gladyshev@xxxxxxxxx> 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