Linux 6.13 Poised To Land Prep Patches Working Toward Proxy Execution
([Linux Kernel] 34 Minutes Ago
Linux Proxy Execution)
- Reference: 0001499085
- News link: https://www.phoronix.com/news/Linux-6.13-Prep-For-Proxy-Exec
- Source link:
Years in the making has been the idea of Proxy Execution for the Linux kernel as a means of implementing priority inheritance by leveraging information from a task's scheduler context and its execution context. While the Proxy Execution patches themselves aren't yet queued for merging upstream, some prep patches look like they'll make it for the upcoming Linux 6.13 merge window.
The Linux Proxy Execution functionality has been described in earlier [1]patches as:
"Proxy execution is an approach to implementing priority inheritance based on distinguishing between a task's scheduler context (information required in order to make scheduling decisions about when the task gets to run, such as its scheduler class and priority) and its execution context (information required to actually run the task, such as CPU affinity). With proxy execution enabled, a task p1 that blocks on a mutex remains on the runqueue, but its "blocked" status and the mutex on which it blocks are recorded. If p1 is selected to run while still blocked, the lock owner p2 can run "on its behalf", inheriting p1's scheduler context. Execution context is not inherited, meaning that e.g. the CPUs where p2 can run are still determined by its own affinity and not p1's.
In practice a number of more complicated situations can arise: the mutex owner might itself be blocked on another mutex, or it could be sleeping, running on a different CPU, in the process of migrating between CPUs, etc."
The prep work likely to be merged for Linux 6.13 is [2]this patch series of changes needed before this Proxy Execution priority inheritance can be introduced. John Stultz of Google commented in that patch message:
"I wanted to re-send (again) v12 of the preparatory patches for Proxy Execution - an approach for a generalized form of priority inheritance. Here again, I’m only submitting the early / preparatory changes for review, in the hope that we can move these more straightforward patches along and then iteratively move through the more interesting patches in the Proxy Execution series."
As of this week those prep changes have been merged into [3]tip/tip.git's sched/core branch .
With those prep patches now merged into the TIP code ahead of the upcoming Linux 6.13 merge window, these patches in turn should be upstreamed at that point barring any last minute problems or criticism raised by Linus Torvalds... After years of being discussed, hopefully it won't be too much longer before seeing the actual Proxy Execution support mainlined in the Linux kernel.
More background information on the Linux Proxy Execution work can be found in the LPC 2023 presentation embedded above by Google's John Stultz.
[1] https://lore.kernel.org/lkml/20221003214501.2050087-1-connoro@google.com/
[2] https://lore.kernel.org/all/20241009235352.1614323-1-jstultz@google.com/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=sched/core
The Linux Proxy Execution functionality has been described in earlier [1]patches as:
"Proxy execution is an approach to implementing priority inheritance based on distinguishing between a task's scheduler context (information required in order to make scheduling decisions about when the task gets to run, such as its scheduler class and priority) and its execution context (information required to actually run the task, such as CPU affinity). With proxy execution enabled, a task p1 that blocks on a mutex remains on the runqueue, but its "blocked" status and the mutex on which it blocks are recorded. If p1 is selected to run while still blocked, the lock owner p2 can run "on its behalf", inheriting p1's scheduler context. Execution context is not inherited, meaning that e.g. the CPUs where p2 can run are still determined by its own affinity and not p1's.
In practice a number of more complicated situations can arise: the mutex owner might itself be blocked on another mutex, or it could be sleeping, running on a different CPU, in the process of migrating between CPUs, etc."
The prep work likely to be merged for Linux 6.13 is [2]this patch series of changes needed before this Proxy Execution priority inheritance can be introduced. John Stultz of Google commented in that patch message:
"I wanted to re-send (again) v12 of the preparatory patches for Proxy Execution - an approach for a generalized form of priority inheritance. Here again, I’m only submitting the early / preparatory changes for review, in the hope that we can move these more straightforward patches along and then iteratively move through the more interesting patches in the Proxy Execution series."
As of this week those prep changes have been merged into [3]tip/tip.git's sched/core branch .
With those prep patches now merged into the TIP code ahead of the upcoming Linux 6.13 merge window, these patches in turn should be upstreamed at that point barring any last minute problems or criticism raised by Linus Torvalds... After years of being discussed, hopefully it won't be too much longer before seeing the actual Proxy Execution support mainlined in the Linux kernel.
More background information on the Linux Proxy Execution work can be found in the LPC 2023 presentation embedded above by Google's John Stultz.
[1] https://lore.kernel.org/lkml/20221003214501.2050087-1-connoro@google.com/
[2] https://lore.kernel.org/all/20241009235352.1614323-1-jstultz@google.com/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=sched/core
phoronix