调度器 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 动态范围重新校准的自动副作用。