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

[Steven Rostedt]

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.

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.

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.

-- Steve