一直在关注Linux内核调度器的相关进展，最近的一个关于SCHED_IDLE的小优化特别有意思。详情参见下面的lwn：
https://lwn.net/Articles/805317/
下面是其包含的patchset：
https://lore.kernel.org/lkml/[email protected]/

简单来讲，就是说：

• 为一个进程选择一个仅有SCHED_IDLE排队的CPU要优于为其选择一个完全空闲的CPU。

Why？

因为完全idle的CPU往往是处在节能休眠状态，比如NOHZ那样的，唤醒它需要付出代价，然而，另一方面，如果此时有个CPU正在执行SCHED_IDLE的进程，只需要抢占它即可。

可能经理会不同意，也确实，这里必然存在一些争议。

Linux内核调度器在数据结构上是个分层的组织，首先是调度类链表，它们按照优先级从高到低排列，每个调度类内部又有自己的子数据结构，按照该调度类的内部策略来进行进程选择。

遗憾的是，SCHED_IDLE的进程也是CFS调度类的一员，CFS内部的家务事，意味着SCHED_IDLE进程也是需要按照权重来分配CPU时间的，只是权重很低而已。

另一方面，SCHED_IDLE是用户赋予的，这意味着这些进程是 不重要 的，现在的矛盾在于：

• 唤醒完全idle的CPU，保持SCHED_IDLE进程继续占有原来的CPU。
• 抢占SCHED_IDLE进程，保持完全idle的CPU继续idle。

都有道理，看你是为了节能，还是为了均衡。

其实，在我看来，专门为SCHED_IDLE进程新增一个调度类也不错，暂且称作background调度类，这样在选择idle的调度类之前，background可以兜底了。这样代码改动也不大，如果非要将SCHED_IDLE融入CFS调度类，那势必要在代码里多很多if-else。

不过，一切都是经理说了算。

Linux内核调度器关键概念：

• Linux初始的 $O(n)$调度器
• Linux 2.6.0～Linux 2.6.22的 $O(n)$调度器
• Linux 2.6.23后的CFS调度器
• 野调度器，电梯，BFS等
• 负载均衡
• 调度类
• 组调度
• 经理调度
• …

浙江温州皮鞋湿，下雨进水不会胖。