Re: [PATCH v4 4/4] slub: apply new pw_queue_on() interface

On 2026-07-13 18:40:57 [-0300], Leonardo Bras wrote:
> On Mon, Jul 13, 2026 at 09:36:34AM +0200, Sebastian Andrzej Siewior wrote:
> > On 2026-07-12 19:35:28 [-0300], Leonardo Bras wrote:
> > > On Wed, May 20, 2026 at 04:53:08PM +0200, Sebastian Andrzej Siewior wrote:
> > > > On 2026-05-18 22:27:50 [-0300], Leonardo Bras wrote:
> > > > > @@ -4733,121 +4735,121 @@ void *alloc_from_pcs(struct kmem_cache *s, gfp_t gfp, int node)
> > > > >  
> > > > >  	/*
> > > > >  	 * We assume the percpu sheaves contain only local objects although it's
> > > > >  	 * not completely guaranteed, so we verify later.
> > > > >  	 */
> > > > >  	if (unlikely(node_requested && node != numa_mem_id())) {
> > > > >  		stat(s, ALLOC_NODE_MISMATCH);
> > > > >  		return NULL;
> > > > >  	}
> > > > >  
> > > > > -	if (!local_trylock(&s->cpu_sheaves->lock))
> > > > > +	if (!pw_trylock_local(&s->cpu_sheaves->lock))
> > > > >  		return NULL;
> > > > 
> > > > alloc_from_pcs() can be called from kmalloc_nolock()/ NMI context.
> > > > I don't remember why exactly local_trylock_t was introduced here instead
> > > > of a per-CPU spinlock_t. 
> > > 
> > > Probably to save the cost of using atomic operations on locking, and having 
> > > about the same restrictions that would allow using local_locks
> > > 
> > > > But there should be nothing wrong with a
> > > > trylock on it from NMI as you do here.
> > > 
> > > Awesome!
> > 
> > The problem is always the unlock which requires full locking and is
> > usually the problem from NMI.
> >
> 
> You mean, like, the trylock succeeds in the NMI handle, does the per-cpu 
> operations, and then unlock()s? 

Yes.

I'm not sure what I was thinking when I wrote it back then. Try lock
with local_trylock() might work under RT from NMI. However the unlock
path (which needs to follow) requires an unconditional lock of the
inner-lock plus a potential wakeup of the waiter. 
:
…

> Thanks!
> Leo

Sebastian