除非使用相同的 shell，否则 nice 在 Linux 中无效

Question

如果我输入两个不同的根终端：

nice -n 19 burnK7 &

和

nice -n -19 burnK7 &

然后两个进程都获得大约 50% 的可用 CPU 时间——这不是预期的，当然也不是所期望的。

如果我在同一个根终端中运行：

 nice -n 19 burnK7 &
 nice -n -19 burnK7 &

正如预期的那样，第一个进程收到大约 0% 的可用 CPU 时间，第二个进程收到大约 100% 的可用 CPU 时间。

这是错误还是功能？

我正在单核机器上运行带有 3.16 版内核的 Arch Linux，这是值得的。

Answer 1

所以，事后，这里有一些信息。您看到的行为是因为 Linux 2.6.38（2010 年）中添加的自动分组功能。这是我将要添加到sched(7)手册页的一些文本的编辑版本，它解释了您所看到的内容。

内核提供了一种称为自动分组的功能，以在面对多进程、CPU 密集型工作负载时提高交互式桌面性能，例如使用大量并行构建进程（即make(1) -j标志）构建 Linux 内核。

通过创建新会话时会创建一个新的自动组setsid(2)；例如，当一个新的终端窗口启动时，就会发生这种情况。创建的新进程fork(2)继承其父级的自动组成员资格。因此，会话中的所有进程都是同一个自动组的成员。

启用自动分组后，自动分组的所有成员都被放置在同一个内核调度程序“任务组”中。Linux 内核调度程序采用一种算法来均衡跨任务组的 CPU 周期分布​​。可以通过以下示例描述这对交互式桌面性能的好处。

假设有两个自动组竞争同一个 CPU（即，假定一个 CPU 系统或使用taskset(1) 将所有进程限制在 SMP 系统上的同一个 CPU）。第一组包含来自内核构建的十个 CPU 绑定进程make -j10. 另一个包含一个受 CPU 限制的进程：视频播放器。自动分组的效果是这两个组将各自接收一半的 CPU 周期。也就是说，视频播放器将接收 50% 的 CPU 周期，而不仅仅是 9% 的周期，这可能会导致视频播放质量下降。SMP 系统上的情况更复杂，但总体效果是相同的：调度程序在任务组之间分配 CPU 周期，这样包含大量 CPU 绑定进程的自动组最终不会以牺牲 CPU 周期为代价系统上的其他作业。

不错的价值和团体安排

在调度非实时进程（例如，在默认SCHED_OTHER策略下调度的进程）时，调度程序采用一种称为“组调度”的技术，在该技术下，线程在“任务组”中进行调度。任务组是在各种情况下形成的，这里的相关案例是自动分组。

如果启用setsid(2)了自动分组，则（隐式）放置在自动分组中的所有线程（即，由 所创建的相同会话）形成一个任务组。因此，每个新的自动组都是一个单独的任务组。

在组调度下，线程的 nice 值仅对与同一任务组中的其他线程相关的调度决策有影响。就 UNIX 系统上 nice 值的传统语义而言，这会产生一些令人惊讶的后果。特别是，如果启用了自动分组（这是各种发行版中的默认设置），那么nice(1)在进程上使用仅对相对于在同一会话中执行的其他进程（通常：同一终端窗口）的调度有影响。

相反，对于（例如）不同会话中唯一受 CPU 限制的进程的两个进程（例如，不同的终端窗口，其每个作业都绑定到不同的自动组），在其中一个会话中修改进程的 nice 值对调度程序相对于另一个会话中的进程的决定没有影响。

如果您想防止自动分组干扰nice此处描述的传统行为，您可以禁用该功能

echo 0 > /proc/sys/kernel/sched_autogroup_enabled

但请注意，这也会导致禁用自动分组功能旨在提供的桌面交互优势（见上文）。

自动分组好值

可以通过文件查看进程的自动组成员身份/proc/[pid]/autogroup：

$ cat /proc/1/autogroup
/autogroup-1 nice 0

此文件还可用于修改分配给自动组的 CPU 带宽。这是通过将“nice”范围内的数字写入文件来设置自动组的 nice 值来完成的。允许的范围是从 +19（低优先级）到 -20（高优先级）。

autogroup nice 设置与 process nice 值具有相同的含义，但适用于根据其他 autogroup 的相对 nice 值将 CPU 周期分配给整个 autogroup。对于自动组内的进程，它接收的 CPU 周期将是自动组的 nice 值（与其他自动组相比）和进程的 nice 值（与同一自动组中的其他进程相比）的乘积。