点击上方蓝色字关注我们~
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搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~