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

[Hao Li]

On Wed, Mar 04, 2026 at 11:14:51AM +0100, Vlastimil Babka (SUSE) wrote:
> 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.

Oh, yes - I hadn't considered the impact of lockdep. This is a good point!

> 
> 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.

Yes, make sense, thanks!

-- 
Thanks,
Hao