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

[John Stultz]

On Thu, Sep 17, 2026 at 1:58 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> On Thu, Sep 17, 2026 at 04:33:24AM +0000, Suleiman Souhlal wrote:
> >
> > This patch series adds a new type of PI futexes, PI Next Generation,
> > or PING (name coined by Steven Rostedt) (but other name suggestions
> > are welcome!), that differs from classic PI futexes in that they can
> > be stolen from the top waiter, and use Proxy Execution instead of
> > rtmutexes internally.
> >
> > The reason to allow the futexes to be stolen is that with classic PI
> > futex's strict handoff to the top waiter, new contending lockers are
> > now forced to wait in queue, which means that any locking operation
> > now becomes a scheduling event. With stealing, a contending locker has
> > the chance of taking the lock without blocking. The longer wait time
> > of blocked tasks can be mitigated by forcing the lock to be handed
> > off to them in a way that can't be stolen, when they've been stolen
> > from too much, to ensure they don't get starved.
> >
> > The use of Proxy Execution lets us also get Priority Inheritance for
> > for fair tasks, which PI futexes don't really allow.
>
> https://patch.msgid.link/1490204338-1856-1-git-send-email-longman%40redhat.com

Thanks for that reference! I'm sure we can learn a lot from that series.
(I do like the straightforward FUTEX_LOCK/UNLOCK over the PING name here :)

> Also, the goal is to eventually delete rt_mutex and have it be the
> normal mutex, in which case the existing FUTEX_*_PI things will
> automagically work.

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.

That's why it seems a new FUTEX op is needed. Since we 1) need to
communicate the owner to the kernel 2) want different semantics for
lock-handoff and stealing.

Even when we get to moving rt_mutexes to proxy, it seems to me we're
likely going to have to keep the rt_mutex itself (even if the PI
boosting is proxy based) as a distinguisher, since the users likely
desire the strict semantics (or at least we will need to add some
behavior flags to the mutex struct so it can still satisfy those
semantics).

> So I'm thinking all of this is way premature.

So it is just an initial RFC, and we are looking for input.

But there is a strong appetite to solve this, as we're already seeing
vendors doing less ideal things, like passing who the waiter thinks
the owner is (racy) in via unused fields of FUTEX_WAIT, so that
out-of-tree custom scheduler boosting can (temporarily - as again it
can be wrong) try to get that owner to release the lock. The longer we
go without a usable upstream solution, the more entrenched these less
ideal solutions become.

thanks
-john