Proxy execution

At the risk of playing defense, Juri Lelli started his talk by saying that he was going to be quick, as he didn't actually have any updates from what he presented last year at the Linux Plumbers Conference and from the first RFC posted on the Linux kernel mailing list. The main goal of his session was to understand if there is still interest in this line of work.

Proxy execution can be simply thought of as a "better" priority-inheritance mechanism, which a mutex owner can potentially run using (inheriting) the scheduling context (properties) of other tasks blocked on the same mutex (avoiding priority inversions). For the SCHED_DEADLINE scheduling policy, this translates to the possibility for a mutex owner to run "inside" donors' (mutex waiters) bandwidth, fixing a longstanding issue of policy: priority-boosted tasks are currently allowed to run outside of runtime enforcement, as they only inherit donors' deadline.

With examples, Lelli showed why not having any priority-inheritance mechanism is bad (priority inversions), and why the current one is actually worse (can cause deadline misses on tasks not even using the same mutex). He finally got into some details of how proxy execution is implemented: by separating scheduling and execution contexts and dynamically building the proxy chain.

After suggesting that the proxy execution idea is general enough that it could be potentially applied to several other synchronization mechanisms (e.g., condition variables, binder calls, yield_to semantic types of calls), he addressed the audience for comments and indications that all this is still relevant. Peter Zijlstra promptly stated that this is still something that we want to have, even though it might take a while to get it right. Dhaval Giani mentioned that control-group-aware unbound workqueues might find this mechanism useful, because it would allow a proxy task to temporarily assume the control group characteristics from another task so that it can use the other task's control-group-related information to run, but the feasibility of this idea wasn't clear in the end.

Zijlstra and Paul Turner then discussed how proxy execution would work with futexes. Potential problems that arise when taking into consideration task affinities were discussed as well. The current implementation migrates potential donors to the mutex-holder CPU (so that the holder can keep running on the same CPU and thus respect its affinity), but this might not work well for SCHED_DEADLINE since freely moving donors' bandwidth might break admission-control guarantees; discussion continued off-line, since the problem doesn't seem to be an easy one to solve.