Re: [PATCH slab/for-next-fixes] mm/slab: allow sheaf refill if blocking is not allowed

[Vlastimil Babka (SUSE)]

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.