Por que o bom nível é ignorado? (Entre sessões de login diferentes - honrado se iniciado a partir da mesma sessão.)

Question

Quando inicio dois processos de consumo de CPU com diferentes níveis, por exemplo

Processo 1:

nice -19 sh -c 'while true; do :; done'

Processo 2:

sh -c 'while :; do true; done'

(Eu mudei a ordem de : e true apenas para diferenciar os processos em saídas de ps ou top ),

o nível bom parece ser ignorado e ambos usam a mesma quantidade de CPU.

A saída de top é como

  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
 [...]

(obviamente, os valores %CPU variam ligeiramente de amostra para amostra, mas em média parecem iguais).

top mostra que ambos os processos são executados com valores diferentes, mas ainda assim eles parecem obter a mesma quantidade de tempo de CPU.

Ambos os comandos foram executados pelo mesmo usuário a partir de terminais diferentes (ambos são shells de login).

Se eles são executados no mesmo terminal, eles se comportam como o esperado: o processo mais agradável abre caminho para o não tão bom.

Qual é o motivo? Como fazer um bom trabalho globalmente em toda a máquina?

Era diferente naquela mesma máquina algum tempo antes, onde valores legais pareciam ser honrados.

É uma máquina de processador único / núcleo único.

Para informações:

• Kernel: Versão 4.4.5 (kernel de estoque do 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:
  

Answer 1

Ah, não é o recurso systemd-logind em que cada usuário recebe seu próprio cgroup. Eu acho que a mudança responsável aqui é mais antiga; eles são apenas confusamente semelhantes. (Eu procurei por "process group fair scheduling", pensando que poderia ser algo baseado nos "grupos de processos" do unix que eu realmente nunca entendi). Wikipédia:

The Linux kernel received a patch for CFS in November 2010 for the 2.6.38 kernel that has made the scheduler fairer for use on desktops and workstations.

When a task calls __proc_set_tty(), the process wide reference to the default group is dropped, a new task group is created, and the process is moved into the new task group. Children thereafter inherit this task group, and increase its refcount. On exit, a reference to the current task group is dropped when the last reference to each signal struct is dropped. The task group is destroyed when the last signal struct referencing it is freed. At runqueue selection time, IFF a task has no cgroup assignment, its current autogroup is used.

The feature is enabled from boot by default if CONFIG_SCHED_AUTOGROUP is selected, but can be disabled via the boot option noautogroup, and can be also be turned on/off on the fly [via /proc/sys/kernel/sched_autogroup_enabled: Writing 0 there disables it for newly created tasks, writing 1 enables it.]

The primary issues solved by this are for multi-core as well as multi-cpu (SMP) systems experiencing increased interactive response times while performing other tasks that use many threads in those tasks. A simple explanation is that one will be able to still watch a video, read email and perform other typical desktop activities without glitches or choppiness while compiling the Linux kernel or a similar process such as encoding video. However, there are objections to this statement.