Re: [PATCH 1/5] locking/rtmutex: Stop spinning on the owner when the waiter is woken

[Steven Rostedt <rostedt@goodmis.org>]

On Sat, 7 Nov 2026 14:34:12 -0500
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> > 
> > How about something like the above?  
> It drops important information, such as the user visible impact of the
> issue. How about this remix ?
> 
> locking/rtmutex: Stop spinning on the owner when the waiter is woken
> 
> The top waiter of an rt_mutex sets its sleep state. Then it spins in
> rtmutex_spin_on_owner() as long as the owner is running. A wakeup sets
> the waiter back to TASK_RUNNING. The spin loop does not check for this.
> So a timeout or a signal is only handled when the owner blocks, or when
> the waiter has to reschedule.
> 
> The spin is an optimization. A running owner will likely release the
> lock soon, so the waiter spins instead of going to sleep. It comes
> from the PREEMPT_RT adaptive spinning for rt_spin_locks. Only the
> lock handoff wakes an rt_spin_lock waiter, so the spin did not need to
> check for other wakeups there. The spin was then extended to all
> rtmutex based locks. Their waiters can also be woken by a timeout, a
> signal or a ww_mutex wound.
> 
> The owner of a PI futex is a user task. It can run for a long time.
> With an owner spinning in userspace, a 1ms pthread_mutex_timedlock()
> returned up to 1.4s late in testing. A signal to the waiter is delayed
> too.

The last sentence seems out of place. Perhaps be more specific?

 The timeout signal or any signal to the waiter will not stop it
 from spinning, and the signal will be delayed until it exits the spin.

> 
> With PREEMPT_RT, two contexts that take two ww_mutexes in opposite
> order spin on each other. Only something else that needs one of the two
> CPUs stops them. By default, the fair server does it after 950ms, to
> run SCHED_OTHER tasks.

Yeah, that is a big issue.

> 
> Fix this by also stopping the spin when the waiter is TASK_RUNNING. The
> slowpath then handles the wakeup, as it does after schedule().

The last sentence doesn't really make sense. I can figure it out
because I know what the slowpath does, but as you see in my version, I
go into a little more detail to why it's not an issue to break out of
that spin on TASK_RUNNING.


> PI mutex throughput is unchanged. The futex and ww_mutex selftests added
> later in this series test both cases.

I think you can drop the above. I don't see it adding anything for the
change log. That is more for cover letters.

Thanks,

-- Steve