Re: [PATCH 2/2] workqueue: defer wake_up_process() outside pool->lock on hot paths

[Breno Leitao <leitao@debian.org>]

Hello Sebastian,

On Wed, May 27, 2026 at 05:22:05PM +0000, Sebastian Andrzej Siewior wrote:
> On 2026-05-26 14:08:06 [-0400], Breno Leitao wrote:
> > --- a/kernel/workqueue.c
> > +++ b/kernel/workqueue.c
> > @@ -2423,6 +2424,15 @@ static void __queue_work(int cpu, struct workqueue_struct *wq,
> >  
> >  out:
> >  	raw_spin_unlock(&pool->lock);
> > +	/*
> > +	 * Issue the wakeup after dropping pool->lock to shorten the
> > +	 * locked region on this hot enqueue path.  kick_pool_pick() did all
> > +	 * of the work that required the lock (worker selection and
> > +	 * wake_cpu setup); the wake_up_process() itself only needs to
> > +	 * take the target rq->lock.
> > +	 */
> > +	if (wake_p)
> > +		wake_up_process(wake_p);
> 
> What about using wake_q_add() to grab a worker(s) and then wake_up_q()
> to wake the worker outside of the lock?

Thanks, this is a good recommendation.

Looking at the API, I understand the intended pattern is to call
wake_q_add() while still holding pool->lock and then wake_up_q() after
dropping it -- wake_q_add() only does a cmpxchg on task->wake_q.next
plus get_task_struct(), so it's safe under the spinlock, while
wake_up_q() is the part that takes rq->lock and is what we want
outside.

Will switch to that in v2.
--breno