当我启动两个具有不同良好级别的 CPU 消耗进程时，例如
流程一：
nice -19 sh -c 'while true; do :; done'
流程2：
sh -c 'while :; do true; done'
:（我更改了和的顺序只是为了在或 的true输出中区分进程），pstop
好级别似乎被忽略，并且两者使用相同数量的 CPU。
的输出top就像
PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND
8187 <user> 39 19 21.9m 3.6m 45.8 0.0 0:20.62 R sh -c while true; do :; done
8188 <user> 20 0 21.9m 3.5m 45.6 0.0 0:20.23 R sh -c while :; do true; done
[...]
（当然，各个%CPU样本的 值略有不同，但平均而言它们似乎相等）。
top显示两个进程都以不同的 Nice 值运行，但它们似乎仍然获得相同的 CPU 时间。
这两个命令都是由同一用户从不同的终端运行的（都是登录 shell）。
如果它们从同一个终端运行，它们的行为将按预期进行：更好的进程让位于不太好的进程。
是什么原因？如何在整机全局上做好工作？
不久前在那台机器上情况有所不同，良好的价值观似乎受到尊重。
它是单处理器/单核机器。
欲了解更多信息：
- 内核：版本 4.4.5（Arch Linux 原生内核）；
uname -r:4.4.5-1-ARCH, /proc/cpuinfo是：processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Solo CPU U3500 @ 1.40GHz stepping : 10 microcode : 0xa0c cpu MHz : 1400.000 cache size : 3072 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority bugs : bogomips : 2794.46 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
答案1
啊，这不是每个用户都有自己的 cgroup 的 systemd-logind 功能。我认为这里负责的变化是较旧的；它们只是令人困惑地相似。 （我搜索了“进程组公平调度”，认为这可能是基于我从未真正理解的unix“进程组”的东西）。维基百科：
Linux 内核于 2010 年 11 月收到了针对 2.6.38 内核的 CFS 补丁，该补丁使调度程序更适合在桌面和工作站上使用。
当任务调用 __proc_set_tty() 时，对默认组的进程范围引用将被删除，创建一个新任务组，并将进程移动到新任务组中。此后，孩子们继承该任务组，并增加其重新计数。退出时，当删除对每个信号结构的最后一个引用时，对当前任务组的引用也将被删除。当引用任务组的最后一个信号结构被释放时，任务组将被销毁。在运行队列选择时，如果任务没有 cgroup 分配，则使用其当前的自动组。
如果选择 CONFIG_SCHED_AUTOGROUP，则默认情况下从启动时启用该功能，但可以通过启动选项 noautogroup 禁用，也可以动态打开/关闭[via
/proc/sys/kernel/sched_autogroup_enabled：0在那里写入会禁用新创建的任务，写入1会启用它。]由此解决的主要问题是多核以及多 CPU (SMP) 系统在执行在这些任务中使用许多线程的其他任务时遇到交互响应时间增加的问题。一个简单的解释是，在编译 Linux 内核或编码视频等类似过程时，人们仍然能够观看视频、阅读电子邮件和执行其他典型的桌面活动，而不会出现故障或不稳定。不过，这一说法也有人反对。