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

[Thomas Gleixner]

On Fri, Sep 04 2026 at 13:53, Dmitry Ilvokhin wrote:
> On Fri, Sep 04, 2026 at 07:21:37AM +0200, Thomas Gleixner wrote:
>> On Mon, Aug 31 2026 at 12:57, Alice Ryhl wrote:
>> > 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?

Eventually :)

> 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.

Correct. The main incentive for time slice extensions are user space
spinlocks. The DB folks wanted to have a way to disable preemption from
user space forever exactly for that problem and after twenty years of
horrible hacks we finally have something workable.

I'm not surprised that you want to exploit that for your use case, but
that's not a good fit.

> 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.

Once hb->lock is held preemption is disabled except for RT enabled
kernels. And no, we are not going to add a cond_resched() into that code
right at the point where we are trying to get rid of this ill defined
insanity alltogether.

> 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.

That depends on your POV. The scheduler already granted some leeway and
now your special case wants some more which is pretty much guaranteed to
exceed the grant.

And special casing X is a slippery slope because everyone has an
argument why their Y and Z use cases are equally important and need an
exemption too. You can figure out where that ends up ...

The real question is whether you have exhausted all possibilities to
solve the underlying user space problem. Alice mumbled something vague
about double linked lists, but that's handwaving at best.

What is the actual problem you are trying to solve?

Thanks,

        tglx