【翻译】 代理执行

朱里-莱利（Juri Lelli）冒着防守的风险，在演讲一开始就说他要速战速决，因为与他去年在Linux 管道工大会上的演讲以及在 Linux 内核邮件列表上发布的第一份 RFC相比，他实际上没有任何更新。他这次会议的主要目的是想了解人们对这项工作是否还有兴趣。

代理执行可以简单地理解为一种 "更好的 "优先级继承机制，互斥体所有者可以使用（继承）阻塞在同一互斥体上的其他任务的调度上下文（属性）来运行（避免优先级倒置）。对于SCHED_DEADLINE调度策略来说，这意味着互斥体所有者可以 "在 "捐赠者（互斥体等待者）的带宽内运行，从而解决了一个长期存在的策略问题：目前允许优先级提升的任务在运行时执行之外运行，因为它们只能继承捐赠者的截止日期。

Lelli 举例说明了为什么没有任何优先级继承机制是不好的（优先级倒置），以及为什么当前的机制实际上更糟（可能导致甚至不使用相同互斥器的任务错过截止时间）。最后，他详细介绍了如何实现代理执行：分离调度和执行上下文，动态构建代理链。

他指出，代理执行的想法具有足够的通用性，有可能应用于其他几种同步机制（例如条件变量、绑定调用、yield_to 语义类型的调用），随后他向听众征求意见，并表示所有这些仍然具有现实意义。Peter Zijlstra 立即表示，这仍然是我们希望拥有的东西，尽管可能需要一段时间才能做好。Dhaval Giani 提到，控制组感知的非绑定工作队列可能会发现这种机制很有用，因为它可以让代理任务临时承担另一个任务的控制组特征，这样它就可以使用另一个任务的控制组相关信息来运行，但这个想法的可行性最终并不明确。

Zijlstra 和 Paul Turner 随后讨论了代理执行如何与 futexes 配合使用。他们还讨论了在考虑任务亲和性时可能出现的问题。目前的实现方法是将潜在的捐献者迁移到互斥任务持有者的 CPU 上（这样持有者就可以继续在同一 CPU 上运行，从而尊重其亲和性），但这对于SCHED_DEADLINE可能效果不佳，因为自由移动捐献者的带宽可能会破坏接纳控制保证；由于这个问题似乎不容易解决，因此讨论继续在线下进行。