linux-kernel - Re: [RFC PATCH 0/2] mm: improve folio refcount scalability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cb821f39-ce0c-44fd-aec1-9ad19e6355f5@h-partners.com>
Date: Tue, 13 Jan 2026 10:31:55 +0300
From: Gladyshev Ilya <gladyshev.ilya1@...artners.com>
To: Kiryl Shutsemau <kirill@...temov.name>
CC: <guohanjun@...wei.com>, <wangkefeng.wang@...wei.com>,
	<weiyongjun1@...wei.com>, <yusongping@...wei.com>, <leijitang@...wei.com>,
	<artem.kuzin@...wei.com>, <stepanov.anatoly@...wei.com>,
	<alexander.grubnikov@...wei.com>, <gorbunov.ivan@...artners.com>,
	<akpm@...ux-foundation.org>, <david@...nel.org>,
	<lorenzo.stoakes@...cle.com>, <Liam.Howlett@...cle.com>, <vbabka@...e.cz>,
	<rppt@...nel.org>, <surenb@...gle.com>, <mhocko@...e.com>, <ziy@...dia.com>,
	<harry.yoo@...cle.com>, <willy@...radead.org>, <yuzhao@...gle.com>,
	<baolin.wang@...ux.alibaba.com>, <muchun.song@...ux.dev>,
	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
	<gladyshev.ilya1@...artners.com>
Subject: Re: [RFC PATCH 0/2] mm: improve folio refcount scalability

On 1/12/2026 7:17 PM, Kiryl Shutsemau wrote:
> On Mon, Jan 12, 2026 at 05:32:10PM +0300, Gladyshev Ilya wrote:
>> On 1/12/2026 2:49 PM, Kiryl Shutsemau wrote:
>>> On Mon, Jan 12, 2026 at 11:30:38AM +0300, Gladyshev Ilya wrote:
>>>> Gentle ping on this proposal
>>>
>>> I generally like the idea, but I would like to hear from folks who
>>> actually understand serialization.
>>>
>>> Also, do you have number for "a full CAS loop when the counter is
>>> approaching overflow" thing?
>>>
>> I am not sure that overflow is a real problem because you need a very
>> specific race condition over a long time to achieve it...
> 
> Yes. But if the page is popular for pinning, GUP_PIN_COUNTING_BIAS can
> cut the "very long time" substantially.
> 
>> But as a safeguard, everything lower than 2^31 - #max concurrent
>> accesses (~#num cpu) should work, so let's say 2^30
> 
> What I meant is when we put a branch/loop in the hot path, your
> performance numbers will likely not look as attractive. Am I wrong?
> 
It would be under the same branch as the single CAS that already exists 
in this patch:

   if (page_count_writable(page)) {
     val = atomic_add_return(nr, &page->_refcount);
     ret = !(val & PAGEREF_LOCKED_BIT);

     if (unlikely(!ret)) {
       atomic_cmpxchg_relaxed(&page->_refcount, val, PAGEREF_LOCKED_BIT);
       /* [Proposed] if (failed && big enough) { CAS loop } */
     }		
   }

Unless the "failed try_lock()" is the hot path somewhere[1], this added 
branch will be hidden under the already existing [unlikely taken] branch

[1]: Which I doubt, because failed try_lock() usually includes heavy 
re-lookup