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

[Suleiman Souhlal]

On Thu, Sep 17, 2026 at 5:58 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Thu, Sep 17, 2026 at 04:33:24AM +0000, Suleiman Souhlal wrote:
> > Hello,
> >
> > 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

I was not aware of this, thanks!
It actually seems very similar to this patchset (but much better written).
The main functional differences that I can see from a cursory look are
that on unlock it doesn't preserve the waiters bit, while PING does,
and that TP futex also supports userspace rwlocks, unlike PING.
And of course the fact that PING also uses Proxy Execution.
So now I know that I'm not completely crazy for wanting this. :-)

>
> 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.

I considered using a mutex but I was under the impression that some RT
workloads really want strict RT handling such that the highest
priority RT task always has to take the lock before any other
contender, which mutex doesn't currently allow. For these workloads,
the existing rtmutex behavior of handing off the lock to the top
waiter is desirable.

Other workloads still have RT tasks, but are ok with slightly less
strict handling, as long as RT tasks still get serviced reasonably
fast (so they still want priority inheritance, but are ok with the
occasional case where a fair task steals the lock from the RT top
waiter).
I suspect Android is in this later bucket, so for them using a mutex
as it's currently implemented would be ok. But others might not be.
On the other hand, the current rtmutex behavior would not be desirable
for users like Android, due to the performance with fair tasks that
Steven brings up in his reply.

These different needs are why I wanted to add a new futex type.
But maybe the different needs could be selected through a CONFIG
option, but with the same user API (FUTEX_*_PI)?

I also had some other probably not insurmountable minor issues, like
the fact that we probably wouldn't want to get kernel lockdep warnings
for userspace deadlocks.

-- Suleiman