进程友善度（优先级）设置对 Linux 没有影响

我编写了一个测试程序，其中仅包含一个无限循环，其中包含一些 内部计算，并且不执行 I/O 操作。我尝试启动该程序的两个实例，其中一个具有高 尼斯值，另一个具有低尼斯值：

sudo nice -n 19 taskset 1 ./test
sudo nice -n -20 taskset 1 ./test

taskset 命令确保两个程序在同一内核上执行。 与我的预期相反，顶级报告称这两个项目都获得了大约 50% 的收益 计算时间。这是为什么？好的命令有效果吗？

您所看到的行为几乎肯定是由于 Linux 2.6.38（2010 年）中添加的自动分组功能造成的。大概当您描述运行这两个命令时，它们是在不同的终端窗口。如果你在same终端窗口，那么您应该已经看到了nice值的效果。这个答案的其余部分详细阐述了这个故事。

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

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

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

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

不错的价值和团体安排

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

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

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

相反，对于（例如）唯一的两个进程 不同会话中的 CPU 密集进程（例如，不同的终端 windows，每个作业都与不同的自动组相关联）， 修改其中一个会话中进程的好值 对调度程序的决策没有影响 另一个会话中的进程。这可能是您看到的场景，尽管您没有明确提到使用两个终端窗口。

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

echo 0 > /proc/sys/kernel/sched_autogroup_enabled

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

自动组不错的价值

可以通过以下方式查看进程的自动组成员资格 文件/proc/[pid]/autogroup:

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

该文件还可用于修改分配的CPU带宽 到自动组。这是通过在“nice”中写一个数字来完成的 range 到文件以设置自动组的好值。允许的 范围从+19（低优先级）到-20（高优先级）。

autogroup的nice设置与进程含义相同 不错的值，但适用于 CPU 周期的分配 自动分组作为一个整体，基于其他的相对好值 自动组。对于自动组内的进程，它所占用的 CPU 周期 收到的将是自动组的好值的乘积（比较 到其他自动组）以及该过程的良好价值（与 同一自动组中的其他进程）。