Many uses for Core scheduling
By Jonathan Corbet
LPC
kernel开发社区中对一些新的功能是持非常欢迎的态度，而对另一些可能就不太欢迎了。很明显，core scheduling就是争议颇大的一个功能。它会对某个CPU上同时运行哪些进程带来不少限制，导致CPU scheduling（调度）更加麻烦。Core scheduling在2019 Linux Plumbers Conference会议上至少有三个议题都提到了它。其中主要的收获，可能就是在最早的“防止side-channel attack”的目标之外，又找到了其他一些应用场景。
Current status
最开始的讨论来自Julien Desfossez和Vineeth Remanan Pillai。Desfossez先指出core scheduling已经开发了有一年时间了，主要目的是为了让SMT（simultaneous multi-threading，或者"hyperthreading"，超线程）能更加安全，不受speculative-execution类型的攻击。一个SMT 核包含两个或者更多的CPU（有时候也被称为“hardware threads”）都共享很多底层硬件。这里共享的包括一部分cache，这样导致SMT可能会受基于cache进行的side-channel攻击。对于担心这类攻击的服务器来说，最好现在就把SMT关掉，当然这会让一些workload（负载）的性能有不少下降。core scheduling如果能合入的话，就不会有这么大的性能损失了，因为它可以让互不信任的进程不会同时执行在同一个core核心上。
Pillai接着说明，core scheduling group会信赖运行在同一个core上的任务。它会把SMT core内部的多个CPU作为同一个实体，在其内部的所有CPU上寻找最高优先级的任务，然后决定下一步调度哪个任务。如果这时候看到另一个任务能跟这个高优先级任务兼容（互信）的话，就让兄弟CPU来执行这个任务，否则只好让兄弟CPU空闲了。
第一版本的core scheduling是针对KVM实现的，只允许同一个虚拟机里的virtual CPU thread共享同一个core。后来有了更通用的实现，是依靠系统管理员来定义trust boundaries（信任边界）。最开始的实现方法是利用cgroup，然后系统管理员来标记哪些任务是互相兼容（信赖）的，从而放到同一个group里去，或者对多个group设置相同的cpu.tag值。第三版的patch set现在正在讨论中，主要关注bug fix以及性能问题。
这里还是有一些问题。调度器的vruntime值是用来在多个task之间进行比较，做出调度决定的依据。对单CPU场景来说很容易使用，不过设计的时候没有考虑过要在多个CPU之间来比较。这样就可能导致一些task会被饿死。目前的考虑是把这类比较当做load-balance的问题，估计会创建一个归一化的vruntime，确保一个core上面都可以直接比较。
在core scheduling实现里，兄弟CPU无法避免会有时被迫空闲，不过情况其实比想象的更加严重。具体来说，一个计算密集型的进程可能会导致它的兄弟CPU在很长一段时间都是空闲的，导致一些进程饿死。调度器还是必须要有办法来统计这种被迫空闲的时长，才能选择时机相应的做出一些对策（换去执行饿得不行了的进程）。或者想办法创造一种特殊的idle task，来在被迫空闲的CPU上运行，能是不是的提醒调度器做出一些动作。
Desfossez接着介绍了一些针对目前patch set所做的很多测试工作。这些会影响性能的patch通常都会需要展示给大家明显的性能提升数据。不过core scheduler的测试结果看起来比起关闭SMT来说互有胜负。他们的测试方法也利用了trace来确保行为正常，确实没有互不相容的task同时在一个core上运行。
测试里暴露出上面提到的公平性问题，以及有些workload下关闭SMT性能其实更好。具体来说，I/O密集型的workload并没有从core scheduling得到什么好处，MySQL benchmark会变得更差。
今后，还需要仔细想一下如何选择各个进程。这里也有个小问题，就是core scheduling尽管能在进程之间互相做隔离，但是它没法保证kernel和user space不在同一个core上执行。如果要修复这个问题，就得在系统调用的位置以及退出虚拟机的位置加上一些同步操作，可能会很耗时。并且没有什么其他方法能避免MDS（Microarchitecture Data Sampling，是Intel处理器上特有的一组side channel攻击方式）攻击。总之，如何管理进程的接口还是需要重新思考一下。
介绍结束之后，Len Brown问这部分代码是否能支持一个SMT core里面有超过2个CPU的情况？目前并没有这种系统，不过相信肯定有CPU设计者在考虑这类设计。回答是说这个代码很通用，能支持这类场景，不过还是要经过测试才能给出确定回答。
Other uses
在Scheduling Microconference里，还有其他一些session讨论提到了core scheduling，主要是关注一些实现细节以及是否有其他的应用场景。Subhra Mazumdar先介绍了Oracle的一类数据库应用场景，其中有Oracle自由的虚拟化配置，希望利用core scheduling来把task比较优化的分布开。不过他们使用core scheduling的时候发现性能下降非常大（17~30%），主要都是来自那些被迫空闲的CPU，经常看到有个CPU明明可以执行另一个core上的task，结果却呆在idle状态。Mazumdar建议在调度器的wakeup路径上做些改动，允许它能查找系统中其他core上兼容task来运行。
讨论中同样指出core scheduling并没有让所有的workload都表现更好。例如Mel Gorman运行的这些benchmark（https://lwn.net/ml/linux-kernel/20190425144619.GX18914@techsingularity.net/ ）就说明打开SMT（哪怕不开core scheduling）也会导致性能下降。
Aubrey Li介绍了core scheduling的另一类应用场景：深度学习的training workload。这类workload通常会用到很多AVX-512指令来改善性能，不过使用这类指令需要整个core的CPU频率降低。如果在同一个core上运行一个不相干的task的话，就可能会导致这个task的性能下降。也就是说用一个CPU来执行AVX-512相关进程，还不如直接用整个core的两个CPU来执行两个AVX-512进程。
既然需要让同一个core中的两个CPU都运行这类AVX-512密集计算进程，那么core scheduling就可以起作用了。这时观察到10%的throughput提升，以及30%的延迟降低。因此他认为把core scheduling合入mainline是很有好处的。
Jan Schönherr有另一种应用场景：隔离一些进程，并且强迫其他进程同时运行。他的patch set名字有点容易让人混淆，叫做coscheduling，允许系统管理员设置策略来要求相关的进程可以在同一个core上运行，并且排除其他进程。因此core scheduling不仅会改善安全性，同时也能通过让相关进程公用CPU资源来获得性能提升。
有人问他现有的cpuset功能是否能满足他的需求，他回答到是可以用，不过在系统负载过重的时候就无法仍然保证效果了。
Realtime
第二天，Peter Zijlstra在Realtime Microconference里也有一个session讨论到core scheduling。他称之为是近来的焦点。太多人要求合入了，他基本上已经没法拒绝了，哪怕这个patch set无法完全解决side-channel问题。
看起来realtime（实时）开发者也觉得这个功能很有吸引力。从实时性角度来考虑，SMT有个问题在于它导致的非确定性。或者按Zijlstra说的“deterministically awful（非常确定的不爽）”。实时调度用户都希望能关闭SMT来避免它引入的延迟问题。不过core scheduling能够在某个CPU运行实时进程的时候强制兄弟CPU进入idle，这样就能避免SMT引入的干扰了。这样，如果某个core没有实时工作的话，就可以打开SMT；而当有实时性要求的时候利用强制idle的方式来事实上关闭了SMT。这样能让两种情况都得到最好的结果。
不过这么使用core scheduling的话就带来很多有趣的问题。会议中讨论到一个，就是deadline scheduler要求的admission control带来的影响。Admission control会要求调度器在CPU资源不够满足某个deadline task需求的时候，不可以接受这个task。强制让CPU空闲，会影响系统中可用的计算能力（总CPU time）。如果admission control不考虑这部分影响，系统可能就会接受了一些无法在deadline内完成的task。
一个可行方案是让某个deadline process的最坏情况下执行时间（也就是它被允许运行的时长）乘以一个core内部的CPU数量，因为这个进程运行时事实上会占住全部这些CPU。这里还是有不少细节需要处理，例如怎么给这样的task标记tag，如果在cgroup或者prctl()里设置tag的话会有点太晚了，可能这时admission-control决策已经完成了。也许可以改进sched_setattr()来达到这个目的。不过这样就会要创建两种不同的方式来对task针对core scheduling进行标记（tag）。Zijlstra说，开发者们还是需要找到一个接口来能涵盖所有可能的应用场景。
Getting it merged
回到Scheduler Microconference，Pillai总结session的时候说，core scheduling对某些应用场景是非常有好处的（big win），应该合入mainline让想用的人尽快用起来。不过这个功能缺省需要关闭，因为并不是对所有人都有好处的。还有个小问题就是core scheduling没有保护kernel。Pillai认为在虚拟机退出的地方加一个security boundary就能解决这个问题了。对系统调用和中断进行隔离并不是那么重要。Thomas Gleixner非常不同意这个看法，他认为所有调入kernel的接口都是同等的，不管使用哪种机制。
Paul Turner说，保护硬件漏洞并不是一个调度器的责任，并且core scheduling并无法完全避免硬件风险。他认为Coscheduling也是必须的，也可能是类似于address-space isolation patch一样很难合入的patch。所有这些都需要我们仔细思考，找出一个方法来把他们结合起来。Gleixner表示赞同，不过认为首先需要了解这个问题的全貌，否则无法把拼图拼完整。
[Your editor thanks the Linux Foundation, LWN's travel sponsor, for supporting his travel to this event.]
全文完
LWN文章遵循CC BY-SA 4.0许可协议。
热烈欢迎转载以及基于现有协议修改再创作～
长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～
1494
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
