From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 17804382285 for ; Wed, 4 Mar 2026 10:14:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772619296; cv=none; b=gNnGZmQoSANinavAITwgMyMGtbZZdyQJP2EHgpT6N1LNZsuNaMKCTvX33tk+OiQF0Jj9YeXXjeEtDUwADR+RLSJvflwU4Nj6mXbZerCC3AgQ7r9slFATrZ2tgur+ZLpfiffhxQpymQ8DoMF0zauMRYFyKKwav/66DwyhY2bmaWw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772619296; c=relaxed/simple; bh=f4x5Ge09xSX0WhI/oZyLC3lQIV7bEAJU87hp3mFCPQg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lsYrdCbqI4BOLKns3LCTj6uMS4yMCpFN0TUoZvGf0xO5wW9f46Sxo7qZXuTMeqpYC67a0VzG48l9JeGGU9AAj2dwhK0O3p0lVcg18IrhdHVgexfUsIat9TUJOqxuFo66Kz2BNSf5sOwKe4HAG8qeg1N1Y0tbR/dWN0whLoLYW5Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rE4OXscT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rE4OXscT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC7A9C2BC87; Wed, 4 Mar 2026 10:14:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772619295; bh=f4x5Ge09xSX0WhI/oZyLC3lQIV7bEAJU87hp3mFCPQg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rE4OXscTNYbnNi9ELKgfREMotQQC5NyjiHov9DdYxz9cL5iaukV3wWASBt9cgSMs3 Vqx+iDkBkCXOzl5qy40hA+67NsRTUfhCwCQXI5gQR/yrraafpTXk8S+N4smFxYgSt8 Io8ogr9IviUP3tH6+O3yRPl3SWg5wROicFKM3Ewk3szNnOQD7kmy6ICtIm0GYhpeFU 4hYLhLyeuj3AJ9ZVET36shyQ8cxVH3JosWhrKqHPz3VZTh2SCiULE8d7rnpxCiFSBl T288fqD8VmBlgd8l/v9mxAAj2q0fCDRZTxBQou1j1BSygg71gntwcQdX7UvT3cNJUn ZwE7+aN5dgXeA== Message-ID: <3952b84e-9342-4628-9778-92ae155e9727@kernel.org> Date: Wed, 4 Mar 2026 11:14:51 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH slab/for-next-fixes] mm/slab: allow sheaf refill if blocking is not allowed To: Hao Li Cc: Harry Yoo , Andrew Morton , Christoph Lameter , David Rientjes , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ming Lei References: <20260302095536.34062-2-vbabka@kernel.org> <3at546the4zbun7g7aoeqrirh46iwsw3vj5ncc4fjhz26gfbb2@tsgplt5o2ybu> From: "Vlastimil Babka (SUSE)" Content-Language: en-US In-Reply-To: <3at546the4zbun7g7aoeqrirh46iwsw3vj5ncc4fjhz26gfbb2@tsgplt5o2ybu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/4/26 8:44 AM, Hao Li wrote: > On Mon, Mar 02, 2026 at 10:55:37AM +0100, Vlastimil Babka (SUSE) wrote: >> @@ -4632,11 +4631,8 @@ __pcs_replace_empty_main(struct kmem_cache *s, struct slub_percpu_sheaves *pcs, >> if (!full) >> return NULL; >> >> - /* >> - * we can reach here only when gfpflags_allow_blocking >> - * so this must not be an irq >> - */ >> - local_lock(&s->cpu_sheaves->lock); >> + if (!local_trylock(&s->cpu_sheaves->lock)) >> + goto barn_put; > > A quick question to make sure I understand this correctly. > > My understanding is that after this patch, there is now a new case where > allocations with __GFP_KSWAPD_RECLAIM set (e.g GFP_ATOMIC) can also reach this > lock-reacquire path. > > If we were to keep using local_lock here: > > 1. On non-RT kernels it seems fine, since alloc_from_pcs() already does a > local_trylock(&s->cpu_sheaves->lock) check. > > 2. But on PREEMPT_RT, local_lock could potentially schedule away, which may add > latency. So the idea of using local_trylock here is to fail fast and return > without incurring that latency - is that the intent behind this change? Great question, thanks! So the main intent is that lockdep would complain if it saw this local_lock() happening in e.g. an irq handler. It doesn't know that it's safe from deadlocks because we already succeeded a trylock before and thus the irq handler didn't interrupt anyone holding the lock. Trying to teach lockdep such things leads to the complicated initial design of kmalloc_nolock() before it could be simplified by sheaves. On !RT it makes no difference as the trylock will succeed always. On RT it may not, but indeed they may prefer avoiding the latency as you say.