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

[Alice Ryhl]

On Tue, Sep 01, 2026 at 11:49:43AM +0000, Dmitry Ilvokhin wrote:
> On Mon, Aug 31, 2026 at 12:57:26PM +0000, 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.
> 
> Just out of curiosity, is there any publicly available implementation of
> a mutex that combines rseq time-slice extensions and futexes?
> 
> I'm interested in learning more about how these two mechanisms interact
> with each other.

This came up while I was looking into implementing one for use in Tokio.
There, we have quite a few cases where we have a doubly linked list
protected by a mutex, and I really really want to avoid preemption while
that lock is held. Some of those locks are known problems for contention
in Tokio.

But that implementation is still WIP.

Some pseudocode:

struct rseq_futex {
    // 0 = unlocked, 1 = locked, 2 = contended
    int futex;
};

void mutex_lock(struct rseq_futex *mutex) {
    for (;;) {
        __rseq_abi.slice_ctrl.request = 1;
        int expected = 0;
        // Change state from 0 -> 1 to lock.
        if (compare_exchange(&mutex->futex, &expected, 1))
            return;

        // lock is taken, use slow-path
        bool was_granted = __rseq_abi.slice_ctrl.granted;
        __rseq_abi.slice_ctrl.request = 0;

        // If the state is not already 2, then change it so that
        // mutex_unlock() knows to wake us up.
        if (expected == 2 || compare_exchange(&mutex->futex, &expected, 2)) {
            // State is 2, we can sleep until that changes.
            futex_wait(&mutex->futex, 2);
        } else if (was_granted) {
            rseq_slice_yield();
        }
    }
}

void mutex_unlock(struct rseq_futex *mutex) {
    // Unlock the mutex and return whether it was contended.
    int prev = atomic_swap(&mutex->futex, 0);

    // End the time slice extension for the critical region
    bool was_granted = __rseq_abi.slice_ctrl.granted;
    __rseq_abi.slice_ctrl.request = 0;

    if (prev == 2) {
        futex_wake(&mutex->futex);
    } else if (was_granted) {
        rseq_slice_yield();
    }
}

Though now that I think more about it, perhaps unlock should look like
this, to avoid a preemption point just immediately before futex_wake().

void mutex_unlock(struct rseq_futex *mutex) {
    // Unlock the mutex and return whether it was contended.
    int prev = atomic_exchange(&mutex->futex, 0);

    // Wake up contended waiters
    if (prev == 2)
        futex_wake(&mutex->futex);

    // End the time slice extension for the critical region
    bool was_granted = __rseq_abi.slice_ctrl.granted;
    __rseq_abi.slice_ctrl.request = 0;

    if (was_granted)
        rseq_slice_yield();
}