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

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Sep 17, 2026 at 10:53:47AM -0700, John Stultz wrote:

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

Yeah, mutex will probably need to grow a few feature when doing that.

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

So I'm not convinced. One could argue the strict requirements are
dependent on the scheduling class, not the lock type. It should be
feasible to make stealing behaviour depend on the lock owner or waiter
class for instance.

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

So this does sound a little like blackmail. If vendors want this, then
vendors had better help out upstream. If vendors don't give a toss about
upstream, then why should I give a flying fuck about them?

It is then on Google to tell vendors to put up or shut up. Just tell em
their hacks are no longer allowed once we have something upstream. Break
their toys and tell em to kindly go cry in the corner.

So no, we don't rush this.