Speakers
Description
More and more we’re seeing issues around priority (sometimes called performance) inversion of SCHED_NORMAL/BATCH tasks. Particularly if any sort of constraints are put on “background” deprioritized tasks. These background tasks will eventually grab an important lock, and then won’t be constrained and prevented from running for some extended period of time, resulting in all the important tasks becoming blocked waiting for them to release the lock. Since the tasks are fair tasks, the delays are not indefinite, but they still can be substantial and user visible.
PI Futexes seem like a good solution here, but the underlying rt_mutex behavior doesn’t help SCHED_NORMAL tasks as rt_mutex priority inheritance isn’t used between SCHED_NORMAL tasks since ~v5.10 or so. Further, even on systems where kernels patch rt_mutexes do “nice inheritance” (as imperfect as that is) for NORMAL tasks, the strict rt_mutex handoff behavior results in pi-futex not performing as well as normal futexes.
Thus, there is a desire to preserve the performance characteristics of normal futexes, while also providing priority inheritance to avoid priority/performance inversions.
Proxy Execution has been a feature in development for many years now, which provides semantics similar to what is desired in this case. Proxy Execution works for in-kernel mutexes (and rw_sems), and provides priority-inheritance without the strict handoff ordering and performance overhead that rt_mutexes can cause. For RT tasks, rt_mutexes and their strict behavior is still important, but for other sched-classes Proxy Execution provides much of the benefits without the costs.
So it would be nice to similarly enable futexes to benefit from Proxy Execution’s generalized form of priority inheritance and avoid the negative performance impact of PI futexes.
Unfortunately, the existing normal futex API is insufficient to be used with Proxy Execution, as when a task is blocked on a futex lock, Proxy Execution has to understand who the owner of that lock is, so they can be run to release the needed lock. Thus we need to find a way to extend the normal futex API so that the lock owner is communicated to the kernel.
Proxy Execution is not yet fully upstream, so this discussion is a little premature, but since uAPI is important to get right, we wanted to start the discussion early so we can plan and work toward an acceptable solution.