[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f495fc2a-00e1-4c76-a562-1e7f42a5fbea@suse.cz>
Date: Wed, 12 Mar 2025 19:23:24 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Harry Yoo <harry.yoo@...cle.com>
Cc: Suren Baghdasaryan <surenb@...gle.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>, Christoph Lameter
<cl@...ux.com>, David Rientjes <rientjes@...gle.com>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>, Uladzislau Rezki <urezki@...il.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
maple-tree@...ts.infradead.org
Subject: Re: [PATCH RFC v2 07/10] slab: determine barn status racily outside
of lock
On 2/25/25 09:54, Harry Yoo wrote:
> On Fri, Feb 14, 2025 at 05:27:43PM +0100, Vlastimil Babka wrote:
>> The possibility of many barn operations is determined by the current
>> number of full or empty sheaves. Taking the barn->lock just to find out
>> that e.g. there are no empty sheaves results in unnecessary overhead and
>> lock contention. Thus perform these checks outside of the lock with a
>> data_race() annotated variable read and fail quickly without taking the
>> lock.
>>
>> Checks for sheaf availability that racily succeed have to be obviously
>> repeated under the lock for correctness, but we can skip repeating
>> checks if there are too many sheaves on the given list as the limits
>> don't need to be strict.
>>
>> Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
>
> Looks good to me,
> Reviewed-by: Harry Yoo <harry.yoo@...cle.com>
>
> in kmem_cache_return_sheaf:
>> if (!pcs->spare) {
>> pcs->spare = sheaf;
>> sheaf = NULL;
>> } else if (pcs->barn->nr_full >= MAX_FULL_SHEAVES) {
>> /* racy check */
>> barn = pcs->barn;
>> keep = true;
>> }
>
> By the way this code also needs data_race()?
Right, will add, thanks.
Powered by blists - more mailing lists