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

[Alice Ryhl <aliceryhl@google.com>]

On Sat, Sep 05, 2026 at 10:01:59PM +0200, Thomas Gleixner wrote:
> 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?

Basically in Tokio we have a bunch of critical regions that look like
this:

	mutex_lock();
	list_add_tail(&my_list, new_item);
	mutex_unlock();

and this:

	mutex_lock();
	next_job = list_first_entry(&my_list);
	list_del(&next_job);
	mutex_unlock();

except in Rust.

People are reporting bugs to me saying that this particular list in
Tokio is causing significant contention for real-world workloads in
production. The context here is backend/web servers.

Thus, I am looking at various solutions to improving contention here.

I saw an article on LWN about this new time slice feature for rseq and
thought that I definitely do not want to get preempted during these
short critical regions, so applying rseq to them seems like an obviously
good idea.

I tried using them and realized that the interaction between rseq and
futexes is not ideal because of when cond_resched() is called. Hence
this patch.


I don't have real-world data on whether this would actually solve their
problem because, well, I'm pretty sure the servers do not have a recent
enough Linux kernel to use this feature. But just from a theoretical
perspective, to me, this seems like the "obvious" behavior you want for
a futex-based mutex if the critical region is short.

Alice