调度器 Nice 设计
本文档解释了在新的 Linux 调度器中重新设计和简化 nice-levels 实现的思路。
在 Linux 下,nice levels 一直比较弱,人们不断地纠缠我们,希望让 nice +19 的任务使用更少的 CPU 时间。
不幸的是,在旧的调度器下实现这一点并不容易(否则我们早就做了),因为 nice level 的支持历来与时间片长度耦合,而时间片单位由 HZ tick 驱动,因此最小的时间片是 1/HZ。
在 O(1) 调度器中(2003 年),我们将负 nice levels 设计得比 2.4 版本中更强(人们对这一变化感到满意),并且故意校准了线性时间片规则,使得 nice +19 级别的任务的时间片长度恰好为 1 个 jiffy。为了更好地理解,时间片图如下所示:
A \ | [时间片长度] \ | \ | \ | \ | \|___100毫秒 |^ . _ | ^ . _ | ^ . _ -*----------------------------------*-----> [nice level] -20 | +19 | |
因此,如果有人真的想要调整任务的优先级,+19 将比正常的线性规则产生更大的影响。(改变 ABI 以扩展优先级的解决方案很快被放弃。)
这种方法在一定程度上起作用,但随着 HZ=1000,1 个 jiffy 变成了 1 毫秒,这意味着 0.1% 的 CPU 使用率,这被认为有点过高。过高不是因为 CPU 利用率太低,而是因为导致过于频繁(每毫秒一次)的重新调度。(这样会破坏缓存等。请记住,这是很久以前,硬件性能较弱,缓存较小,人们在 nice +19 下运行数值计算应用。)
因此,对于 HZ=1000,我们将 nice +19 调整为 5 毫秒,因为这样感觉上是正确的最小粒度,这相当于 5% 的 CPU 使用率。但 nice+19 的基本 HZ 敏感属性仍然存在,我们从来没有收到过有关 nice +19 在 CPU 利用率方面过于“弱”的投诉,我们只收到过有关它(仍然)过于“强”的投诉。
总之,我们一直希望使 nice levels 更一致,但在 HZ 和 jiffies 的约束下,以及它们与时间片和粒度的恶劣设计级耦合的情况下,这并不是真正可行的。
第二个(不太频繁但仍然定期出现的)关于 Linux nice level 支持的投诉是其在原点周围的不对称性(可以在上面的图片中看到),更准确地说:nice level 行为也取决于绝对 nice level,而 nice API 本身基本上是“相对”的:
int nice(int inc); asmlinkage long sys_nice(int increment)
(第一个是 glibc API,第二个是系统调用 API。)请注意,'inc' 是相对于当前 nice level 的。像 bash 的 "nice" 命令这样的工具反映了这种相对 API。
在旧的调度器中,例如,如果您启动了一个 nice +1 的任务和另一个 nice +2 的任务,这两个任务之间的 CPU 分配将取决于父 shell 的 nice level - 如果它是 nice -10,CPU 分配将与它是 +5 或 +10 时不同。
对 Linux nice level 支持的第三个投诉是负 nice levels 不够“强烈”,因此很多人不得不将音频(和其他多媒体)应用程序强制运行在 SCHED_FIFO 等更危险的实时优先级下。但这会带来其他问题:SCHED_FIFO 不能防止饥饿,而且有 bug 的 SCHED_FIFO 应用程序也可能永久锁定系统。
v2.6.23 中的新调度器解决了这三种类型的投诉:
为了解决第一个投诉(nice levels 不够“强烈”),调度器与“时间片”和 HZ 概念解耦(并且粒度被作为与 nice levels 分离的概念),因此可以更好地实现更一致的 nice +19 支持:在新的调度器中,nice +19 任务获得了与 HZ 无关的 1.5% 的 CPU 利用率,而不是在旧调度器中的 3%-5%-9% 范围内。
为了解决第二个投诉(nice levels 不一致),新的调度器使 nice(1) 对任务具有相同的 CPU 利用效果,而不考虑它们的绝对 nice levels。因此,在新的调度器中,运行一个 nice +10 任务和一个 nice 11 任务的 CPU 利用率“分配”效果与运行一个 nice -5 任务和一个 nice -4 任务的效果相同(一个将获得 55% 的 CPU,另一个将获得 45%)。这就是为什么 nice levels 被改为“乘法”(或指数)的原因,这样无论你从哪个 nice level 开始,相对结果都是相同的。
第三个投诉(负 nice levels 不够“强烈”并且迫使音频应用在更危险的 SCHED_FIFO 调度策略下运行)几乎自动地被新的调度器解决了:更强的负 nice levels 是 nice levels 动态范围重新校准的自动副作用。