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

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

On 9/14/26 03:06, Andrew Morton wrote:
> On Sat, 12 Sep 2026 22:50:07 +0300 Ilya Gladyshev <ilya.gladyshev@linux.dev> wrote:
> >> From: Gladyshev Ilya <ilya.gladyshev@linux.dev>
>>
>> Recap
>> -----
>>
>> This patchset addresses a scalability issue of a folio's add_unless() operation,
>> noticeable during contended IO reads from the same page [folio_try_get()]. The
>> main idea is to replace CAS loop with optimistic increment (and deal with
>> failure later). This requires splitting refcount into counter and separate
>> "dead/frozen" bit.
>>
>> To allow for such modification, this patchset also slightly refactors page_ref
>> API, consolidating all implementation logic inside mm headers. For more
>> information, check individual commit messages. The original performance issue
>> and previous attempts by other people can be found in [1][2].
>>
>> Performance
>> -----------
>>
>> To my regret, I don't have any access to high-core CPUs that I can
>> benchmark on, and a 12 vcpu laptop isn't really a scalability test. So,
>> here I can only paste my previous measurements on Linux 6.15. To be fair,
>> none of the related code paths really changed, so I don't expect any changes in the
>> numbers here.
>
> From a quick eyeballing, this patchset seems to provide performance
> gains which are similar to Kiryl's ill-fated "mm/filemap: Implement
> fast short reads" [2].  Is that accurate?

Yes, since both patches aim to optimize the same refcount CAS contention, just in
different ways. This patch is probably less scalable than Kiryl's seqlock because
there is still refcount cache-line bouncing. That said, I haven't analyzed the code
deeply, and the benchmark numbers are very simular.

>> [1]: https://lore.kernel.org/linux-mm/CAHk-=wj00-nGmXEkxY=-=Z_qP6kiGUziSFvxHJ9N-cLWry5zpA@mail.gmail.com/
>> [2]: https://lore.kernel.org/linux-mm/20251017141536.577466-1-kirill@shutemov.name/
>> [3]: https://lore.kernel.org/all/aqAIFV4nOGPbWiDS@thinkstation/
>