Re: [PATCH] rseq: defer time slice extension yield for sys_futex_wakey

[Dmitry Ilvokhin]

On Fri, Sep 04, 2026 at 07:21:37AM +0200, Thomas Gleixner wrote:
> On Mon, Aug 31 2026 at 12:57, Alice Ryhl wrote:
> > When a task is granted an rseq scheduler time slice extension, it is
> > expected to finish its critical section and relinquish the CPU via
> > rseq_slice_yield(2). If the task issues any other system call while a
> > grant is active, rseq_syscall_enter_work() forces an immediate
> > reschedule on syscall entry via cond_resched(). This may cause
> > significant latency penalty for userspace lock implementations that use
> > rseq time slice extensions when unlocking the futex.
> >
> > In a userspace mutex unlock sequence:
> > 1. The lock is released in userspace.
> > 2. If there are waiters, the unlocking thread calls sys_futex_wake()
> >    to wake a sleeping waiter.
> >
> > Because sys_futex_wake() is currently treated as an arbitrary syscall,
> > rseq_syscall_enter_work() schedules out the unlocking thread upon
> > syscall entry, which is before it has executed the wakeup. Consequently,
> > the lock is free in userspace, but the waiter remains blocked in the
> > kernel while the CPU switches to an unrelated task. The waiter is only
> > woken when the unlocking thread is eventually scheduled back in to
> > finish the syscall, causing lock handoff delays.
> >
> > Thus, update rseq_syscall_enter_work() for sys_futex_wake() so that it
> > does not reschedule during syscall entry. The thread will yield the CPU
> > on the syscall exit path instead.
> 
> That's undermining the design and takes control away from the scheduler.
> 
> It granted a short extension with well defined semantics and then you
> special case futex_wake() which can take arbitrary time to complete.

Thomas, do you think the problem is worth solving, though?

Currently, it seems like the rseq time slice extension is a good fit for
userspace spinlocks implementation, but userspace adaptive mutexes don't
fit quite as well.

One can argue that adopting the rseq time slice extension for adaptive
mutexes can never make things worse. The extension allows the lock to be
released, so other threads are free to grab it. The only problem is a
potentially delayed waiter, but this can happen now anyway, even without
the time slice extension applied. That said, it doesn't mean we can't do
better here.

One option that I can think of is a best-effort
rseq_slice_yield_wake(uaddr) that is allowed to fail with a userspace
falling back to futex_wake() in case of a failure.

rseq_slice_yield_wake(uaddr) could look like this:

- Works only for private futexes with nr=1.

- Bails out early on a contended hb->lock.

- Limits the hb->chain walk time by the same time slice extension, that
  is already set.

This way the scheduler is still very much in control and in case of the
success, scheduler might pick a better task, since the waiter is now
available to run.