Cuando inicio dos procesos que consumen CPU con diferentes niveles de Niza, por ejemplo,
Proceso 1:
nice -19 sh -c 'while true; do :; done'
Proceso 2:
sh -c 'while :; do true; done'
(Cambié el orden de : y true solo para diferenciar los procesos en las salidas de ps o top ),
el nivel agradable parece ignorarse y ambos usan la misma cantidad de CPU.
La salida de top es 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
[...]
(por supuesto, el %CPU -los valores varían ligeramente de una muestra a otra, pero en promedio parecen iguales).
top muestra que ambos procesos se ejecutan con diferentes valores agradables, pero aun así parecen obtener la misma cantidad de tiempo de CPU.
Ambos comandos fueron ejecutados por el mismo usuario desde diferentes terminales (ambos son shells de inicio de sesión).
Si se ejecutan desde el mismo terminal, se comportan como se esperaba:el mejor proceso deja paso al no tan bueno.
¿Cuál es la razón? ¿Cómo hacer un buen trabajo globalmente en toda la máquina?
Era diferente en esa misma máquina hace un tiempo, donde parecían respetarse los buenos valores.
Es una máquina de un solo procesador/un solo núcleo.
Para información:
- Kernel:Versión 4.4.5 (kernel estándar de Arch Linux);
uname -r:4.4.5-1-ARCH, -
/proc/cpuinfoes: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:
Respuesta aceptada:
Ah, no es la función systemd-logind donde cada usuario obtiene su propio cgroup. Creo que el cambio responsable aquí es más antiguo; simplemente son confusamente similares. (Busqué "programación justa de grupos de procesos", pensando que podría ser algo basado en los "grupos de procesos" de Unix que realmente nunca entiendo). Wikipedia:
El kernel de Linux recibió un parche para CFS en noviembre de 2010 para el kernel 2.6.38 que ha hecho que el programador sea más justo para usar en escritorios y estaciones de trabajo.
Cuando una tarea llama a __proc_set_tty(), se elimina la referencia amplia del proceso al grupo predeterminado, se crea un nuevo grupo de tareas y el proceso se mueve al nuevo grupo de tareas. A partir de entonces, los hijos heredan este grupo de tareas y aumentan su refcount. Al salir, se descarta una referencia al grupo de tareas actual cuando se elimina la última referencia a cada estructura de señal. El grupo de tareas se destruye cuando se libera la última estructura de señal que hace referencia a él. En el momento de la selección de la cola de ejecución, si una tarea no tiene asignación de cgroup, se utiliza su grupo automático actual.
La función está habilitada desde el arranque de forma predeterminada si se selecciona CONFIG_SCHED_AUTOGROUP, pero se puede desactivar a través de la opción de arranque noautogroup, y también se puede activar/desactivar sobre la marcha [a través de /proc/sys/kernel/sched_autogroup_enabled :Escribiendo allí lo deshabilita para tareas de nueva creación, escribiendo 1 lo habilita.]
Los principales problemas resueltos por esto son para sistemas multi-core y multi-cpu (SMP) que experimentan mayores tiempos de respuesta interactivos mientras realizan otras tareas que usan muchos subprocesos en esas tareas. Una explicación simple es que uno podrá ver un video, leer un correo electrónico y realizar otras actividades típicas de escritorio sin fallas ni interrupciones mientras compila el kernel de Linux o un proceso similar, como la codificación de video. Sin embargo, hay objeciones a esta declaración.