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 07:29:54 -0500
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> >>
> >> The above is very verbose. Are you starting to use AI? ;-)  
> 
> I definitely am, as stated in the cover letter. :-)

I skipped that part of the cover letter. The first patch touches my
code (it has my commit as fixes) so I just jumped straight to that one.

> 
> > 
> > He definitely is. I can't read the above, its word soup. Part of using
> > AI is making sure the Changelog is actually readable. This is not.  
> 
> Feedback on the commit message wording is welcome, I'll try to improve
> things for next iterations. Is the following easier to parse ? I fed
> Peter's and my own criticism to Claude and got it to rewrite the entire
> thing (and keep those learnings for next time):
> 
> 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:
> 
>    CPU 0 (waiter)                            CPU 1 (owner)
> 
>                                              pthread_mutex_lock()
>                                                takes the PI futex
>                                              spins in userspace
>    pthread_mutex_timedlock(1ms)
>      futex_lock_pi()
>        rt_mutex_wait_proxy_lock()
>          set_current_state(TASK_INTERRUPTIBLE)
>          rt_mutex_slowlock_block()
>            rtmutex_spin_on_owner()
>              <timeout> hrtimer_wakeup()
>                wake_up_process(waiter)
>                  __state = TASK_RUNNING
>              owner_on_cpu(owner): true
>              need_resched(): false
>              keeps spinning                  still spins in userspace
> 
> 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()
> returns up to 1.4s late. A signal to the waiter is delayed in the same
> way.
> 
> With PREEMPT_RT, a ww_mutex wound is missed too. Two contexts take two
> ww_mutexes in opposite order, on two CPUs. They spin on each other for
> up to a second.
> 
> Fix this by also stopping the spin when the waiter is TASK_RUNNING. The
> slowpath then handles the timeout, the signal or the wound, as it does
> after schedule().
> 
> rtlock waiters are not affected. Only the lock handoff wakes them from
> TASK_RTLOCK_WAIT.
> 
> With this patch, the 1ms timed lock returns after about 1ms. The
> ww_mutex ABBA resolves in microseconds. PI mutex throughput is
> unchanged. The futex and ww_mutex selftests added later in this series
> cover both cases.

Still way too verbose for the fix. It makes it sound more complicated
than it is.

  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 rtmutex_spin_on_owner() is just an optimization with the idea that
  if the owner is still running on a CPU, it will likely release it soon.
  If the owner gets preempted or schedules out on its own, the spinning
  will stop and the waiter will sleep. This came from PREEMPT_RT adaptive
  spinning for rt_spin_locks that allowed them to behave more like normal
  spin locks and speed up PREEMPT_RT performance.

  The problem is that when this was implemented for futex and normal
  mutexes it did not account for timeouts or other mechanisms where
  the owner releasing the lock wasn't the only way for the spinning
  task to exit the mutex acquire. The spinning currently does not
  account for anything else but the lock being released or the owner
  sleeping.

  Luckily, when the spinning task needs to exit the mutex lock code, it's
  state is set to TASK_RUNNING. By having the spin check the spinning
  task's state to see if it switches to running, it can exit the spin
  appropriately.

How about something like the above?

-- Steve


> 
> Fixes: 992caf7f1724 ("locking/rtmutex: Add adaptive spinwait mechanism")
> Cc: stable@vger.kernel.org
> Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>