Re: [RFC PATCH 00/12] FUTEX_PING: A stealable futex using Proxy Execution.

[Suleiman Souhlal]

On Fri, Sep 18, 2026 at 3:51 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Thu, 17 Sep 2026 10:53:47 -0700
> John Stultz <jstultz@xxxxxxxxxx> wrote:
>
> > Indeed, moving rt_mutexes to proxy is a goal.  Though the performance
> > concerns from FUTEX_*_PI have to do with the semantics it (and
> > rt_mutex) promises: strict RT prio order handoff - esentially FIFO for
> > SCHED_NORMAL.  Not so much the mechanism it uses for boosting.
>
> I started working on this while still at Google on the
> ChromeOS/Android-on-chrome team. The biggest issue we found with
> FUTEX_PI was that it forced all users of it to be fair. Even
> SCHED_OTHER which did not even benefit from the PI code. The result, it
> killed performance, and nobody wanted to use it.
>
> What I recommended was to have a new futex to allow SCHED_OTHER tasks
> to be unfair (just like rt_mutex is in PREEMPT_RT), and also to allow
> more to be done in user space and not require every contention to go
> into the kernel.
>
> We had a test (Suleiman, can you share that test) which emulated the
> code in Chrome and by switching to FUTEX_PI the performance dropped by
> a large percentage (I don't recall the actual numbers but I posted them
> internally at Google). By switching SCHED_OTHER to be non fair (that
> is, when the lock was released, if the next waiting task was
> SCHED_OTHER, and the new SCHED_OTHER task coming in could steal the
> lock), and the performance almost went back to what normal FUTEX had (I
> was assuming that going into the kernel on all contention was the cause
> of not getting closer to normal FUTEX). That alone was a big
> improvement over FUTEX_PI.

Your test is here: https://rostedt.org/private/lock-test.c
Your PING implementation is here:
https://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git/log/?h=ping/test

>
> There was talk about changing FUTEX_PI to allow SCHED_OTHER to be
> unfair and to steal, but that would change the semantics of it and
> there may be some application that requires FUTEX_PI to be fair for all
> tasks, even SCHED_OTHER. This is when we decided that we need a new
> FUTEX_PI (new generation, which I coined FUTEX_PING, but kinda of a
> joke so feel free to change), so that we could change the semantics
> without breaking backward compatibility of applications requiring the
> current behavior of FUTEX_PI.
>
> But FUTEX_PI requires all contention to be handled in the kernel, where
> as we can get even more performance if we could change it to allow the
> SCHED_OTHER case (which can steal the lock) to be handled in user space.
>
> I haven't looked at Suleiman's code yet (I'm currently traveling and
> don't have time until after Oct 10th). But I would expect this new
> futex to keep RT tasks being fair. Otherwise no RT task will use it.

Currently, my implementation allows a fair task to steal from an RT
blocking task.
However, I think that we could easily change it.

I suspect that for our use case, we are ok with fair tasks
occasionally stealing from RT tasks.

>
> In summary, the motivation of this patch was that we had a few RT tasks
> suffering from priority inversion from hundreds of SCHED_OTHER tasks
> over a shared mutex. The problem was, if we switched it to FUTEX_PI,
> the few RT tasks would perform correctly, but the slowdown from the
> hundreds of SCHED_OTHER tasks made it a show stopper. The goal was to
> have a futex that allowed nice PI with RT tasks, but still allowed
> SCHED_OTHER being unfair and stealing from each other.

I agree with everything you've said, but I should also add that we
would also like PI behavior between fair tasks, not just when RT tasks
are present, because priority inversions can still occur between fair
tasks. For example when using sched group shares.
The existing rtmutex based PI futexes can't address those, as far as I can tell.
This is why I opted for a whole new implementation rather than your
initial prototype that still used rtmutexes.

-- Suleiman