Re: [RFC PATCH 2/2] mm: implement page refcount locking via dedicated bit

[Gregory Price]

On Fri, Dec 19, 2025 at 12:46:39PM +0000, Gladyshev Ilya wrote:
> The current atomic-based page refcount implementation treats zero
> counter as dead and requires a compare-and-swap loop in folio_try_get()
> to prevent incrementing a dead refcount. This CAS loop acts as a
> serialization point and can become a significant bottleneck during
> high-frequency file read operations.
> 
> This patch introduces FOLIO_LOCKED_BIT to distinguish between a
> (temporary) zero refcount and a locked (dead/frozen) state. Because now
> incrementing counter doesn't affect it's locked/unlocked state, it is
> possible to use an optimistic atomic_fetch_add() in
> page_ref_add_unless_zero() that operates independently of the locked bit.
> The locked state is handled after the increment attempt, eliminating the
> need for the CAS loop.
>

Such a fundamental change needs additional validation to show there's no
obvious failures.  Have you run this through a model checker to verify
the only failure condition is the 2^31 overflow condition you describe?

A single benchmark and a short changelog is leaves me very uneasy about
such a change.

~Gregory