LWN: OSPM会议讨论多态多核系统里的SCHED_DEADLINE行为

点击上方蓝色字关注我们~

 

 

SCHED_DEADLINE on heterogeneous multicores

July 12, 2019

 

---

OSPM

译者注：OSPM是刚刚结束的第三届Operating-System-Directed Power-Management summit会议。近期LWN发布了一部分会议议题的讨论。本文正是其中一篇。

 

此前在其他文章里面也提到过，SCHED_DEADLINE类型的调度决策过程中并没有考虑各个CPU的当前正在运行的频率。这样主要带来两方面的影响：admission control(准入控制，此处是指在已经创建多个SCHED_DEADLINE的tasks之后必须要拒绝后续的这种类型task的创建)和task placement。

 

SCHED_DEADLINE的admission control设计中主要考虑两个目标：避免过载（overload，也就是说要避免让那些non-deadline的task长时间无法获取执行机会）；对deadline task要提供足够的资源让它们能及时完成。可惜的是，目前代码里面有个假设是所有CPU的最大计算能力都是一致的（也就是说所有CPU的计算能力都是跟系统里最快的那个CPU看齐的），但是这个假设其实会导致admission-control机制出错。如果在big.LITTLE架构系统上运行这个简单的例子（创建多个SCHED_DEADLINE task，直到admission control失败），就很有可能会导致non-deadline tasks长期无法得到执行。Linux kernel mailing list上已经有了一个patch修复了这个问题，是通过在admission control的时候考虑每个CPU自己的最大能力来解决的。再做上述例子程序的时候，看起来patch很有效（直到温度控制把CPU拖慢才出现错误，不过这是另一个问题了）。

 

Linux kernel mailing list上还有其他一些patch，也在会议中得到了讨论。主要关注如何修正SCHED_DEADLINE的迁移机制，从而确保deadline task都能根据每个CPU的能力来确保放到合适的CPU上去。具体来说，这个patch会确保让deadline task避免在那些太慢或者太快的CPU core上执行。太慢，scheduler会在迁移task之前先考虑这个task如果迁移过去的话会不会错过deadline；太快，是因为scheduler希望能在满足task需求的多个CPU core中间选择那个最慢的。前者是为了确保scheduler的行为正确，而后者则是有利于节省功耗，或者能让最快速度的CPU core能预留一些空闲，以备其他更耗时的task之用。

 

在讲解过程中，大家也探讨了这些patch set的一些可能问题，以及一些可能可行的其他实现方案，最主要的就是关于如何确保一个CPU core是足够能满足一个task的deadline需求：

• 对某个task而言，我们需要考虑它的static runtime（预计运行时间）和period（执行周期），还是current runtime and scheduling deadline？

• 对某个core而言，我们是应该考虑它在当前运行频率下的计算能力，还是依据它在它的最大可执行频率下的计算能力？

最终，作者也发布了一些试验结果，看起来这些patch确实能让scheduler行为更加合理（也就是说以前一些因为task放错CPU而导致错过deadline的示例都消失了），并且节省了系统功耗。

 

 

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作～

 

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～