Re: [PATCH 6.12.y 2/2] sched/wake_q: Add helper to call wake_up_q after unlock with preemption disabled

[Sasha Levin <sashal@kernel.org>]

On Thu, Aug 06, 2026 at 09:32:59AM +0000, Simon Liebold wrote:
> [ Upstream commit abfdccd6af2b071951633e57d6322c46a1ea791f ]
>
> A common pattern seen when wake_qs are used to defer a wakeup
> until after a lock is released is something like:
>   preempt_disable();
>   raw_spin_unlock(lock);
>   wake_up_q(wake_q);
>   preempt_enable();
>
> So create some raw_spin_unlock*_wake() helper functions to clean
> this up.

Both patches apply cleanly to 6.12.y and are byte-identical to their
upstream counterparts, so mechanically there is nothing wrong here. But
the rationale in the cover letter does not hold up:

> Even though it looks like a refactor, it adds an if (wake_q), gating the
> wake queue drain.

That "if (wake_q)" is a NULL pointer check, not an "is the queue empty"
check. On 6.12.y every call site of the new helpers passes the address of
an on-stack DEFINE_WAKE_Q - __mutex_unlock_slowpath() and
task_blocks_on_rt_mutex() both pass &wake_q unconditionally - so it is
never false, and the preempt_disable() plus wake_up_q() drain stays
exactly as unconditional as it is today. The only site that can pass NULL
is rt_mutex_slowlock_block() via rt_mutex_wait_proxy_lock(), and that
already carries the identical guard in 6.12.y from the 4a0779145781
("locking/rtmutex: Make sure we wake anything on the wake_q when we
release the lock->wait_lock") backport.

Patch 1/2 additionally converts mutex::wait_lock to irqsave/irqrestore,
which adds a small cost to the slow path rather than removing one. And
the unconditional drain in the plain mutex release path arrived with
894d1b3db41c ("locking/mutex: Remove wakeups from under
mutex::wait_lock") in v6.12.95, not with 4a0779145781 in v6.12.96.

Also note that "wake_q is only ever populated on the ww_mutex path" is
not right either: __mutex_unlock_slowpath() does wake_q_add() for the
ordinary contended waiter.

Neither commit has a Fixes: or Cc: stable tag and both are proxy-exec
prep/cleanup work, so before I queue them for 6.12.y I would like to see
before/after fio numbers with each patch applied separately, so we know
which change actually recovers the throughput you measured.

-- 
Thanks,
Sasha