Si entro en dosdiferenteterminales raíz:
nice -n 19 burnK7 &
y
nice -n -19 burnK7 &
Entonces ambos procesos reciben aproximadamente el 50% del tiempo de CPU disponible, algo que no se esperaba y ciertamente no se desea.
Si corro en elmismoterminal raíz:
nice -n 19 burnK7 &
nice -n -19 burnK7 &
El primer proceso recibe aproximadamente el 0 % y el segundo recibe aproximadamente el 100 % del tiempo de CPU disponible, como se esperaba.
¿Es esto un error o una característica?
Estoy ejecutando Arch Linux con la versión 3.16 del kernel, en una máquina de un solo núcleo, por lo que vale.
Respuesta1
Entonces, mucho después del hecho, aquí hay algo de información. El comportamiento que está viendo se debe a la función de grupo automático que se agregó en Linux 2.6.38 (en 2010). Aquí hay una versión editada de un texto que estoy a punto de agregar alsched(7)pagina del manuallo que explica lo que estás viendo.
El kernel proporciona una característica conocida como autoagrupación para mejorar el rendimiento del escritorio interactivo frente a cargas de trabajo multiproceso que requieren un uso intensivo de la CPU, como la compilación del kernel de Linux con una gran cantidad de procesos de compilación paralelos (es decir, la make(1) -jbandera).
Se crea un nuevo grupo automático cuando se crea una nueva sesión mediante setsid(2); Esto sucede, por ejemplo, cuando se inicia una nueva ventana de terminal. Un nuevo proceso creado por fork(2)hereda la membresía del autogrupo de su padre. Por tanto, todos los procesos de una sesión son miembros del mismo autogrupo.
Cuando el autogrupo está habilitado, todos los miembros de un autogrupo se colocan en el mismo "grupo de tareas" del programador del núcleo. El programador del kernel de Linux emplea un algoritmo que ecualiza la distribución de los ciclos de la CPU entre los grupos de tareas. Los beneficios de esto para el rendimiento del escritorio interactivo se pueden describir mediante el siguiente ejemplo.
Supongamos que hay dos autogrupos compitiendo por la misma CPU (es decir, supongamos un solo sistema de CPU o el uso de taskset(1)
para limitar todos los procesos a la misma CPU en un sistema SMP). El primer grupo contiene diez procesos vinculados a la CPU de una compilación del kernel que comenzó con make -j10. El otro contiene un único proceso vinculado a la CPU: un reproductor de vídeo. El efecto del autoagrupamiento es que los dos grupos recibirán cada uno la mitad de los ciclos de CPU. Es decir, el reproductor de vídeo recibirá el 50% de los ciclos de la CPU, en lugar de sólo el 9% de los ciclos, lo que probablemente provocaría una reproducción de vídeo degradada. La situación en un sistema SMP es más compleja, pero el efecto general es el mismo: el programador distribuye los ciclos de la CPU entre grupos de tareas de manera que un autogrupo que contiene una gran cantidad de procesos vinculados a la CPU no termine acaparando los ciclos de la CPU a expensas. de los otros trabajos en el sistema.
El buen valor y la programación grupal.
Al programar procesos que no son en tiempo real (por ejemplo, aquellos programados según la SCHED_OTHERpolítica predeterminada), el programador emplea una técnica conocida como "programación de grupo", según la cual los subprocesos se programan en "grupos de tareas". Los grupos de tareas se forman en diversas circunstancias, siendo el caso relevante aquí el autoagrupamiento.
Si el agrupamiento automático está habilitado, entonces todos los subprocesos que se colocan (implícitamente) en un grupo automático (es decir, la misma sesión creada por setsid(2)) forman un grupo de tareas. Cada nuevo autogrupo es, por tanto, un grupo de tareas independiente.
En la programación grupal, el buen valor de un hilo tiene un efecto en las decisiones de programación.sólo en relación con otros hilos en el mismo grupo de tareas. Esto tiene algunas consecuencias sorprendentes en términos de la semántica tradicional del valor agradable en los sistemas UNIX. En particular, si el autoagrupamiento está habilitado (que es el valor predeterminado en varias distribuciones), entonces emplearlo nice(1)en un proceso tiene un efecto solo para la programación relativa a otros procesos ejecutados en la misma sesión (normalmente: la misma ventana de terminal).
Por el contrario, para dos procesos que son (por ejemplo) los únicos procesos vinculados a la CPU en diferentes sesiones (por ejemplo, diferentes ventanas de terminal, cada uno de cuyos trabajos están vinculados a diferentes grupos automáticos), modificar el valor agradable del proceso en una de las sesiones. no tiene ningún efecto en términos de las decisiones del planificador relativas al proceso en la otra sesión.
Si desea evitar que el agrupamiento automático interfiera con el nicecomportamiento tradicional como se describe aquí, puede desactivar la función
echo 0 > /proc/sys/kernel/sched_autogroup_enabled
Sin embargo, tenga en cuenta que esto también tendrá el efecto de deshabilitar los beneficios para la interactividad del escritorio que la función de grupo automático estaba destinada a proporcionar (ver arriba).
El autogrupo tiene un buen valor.
La membresía del autogrupo de un proceso se puede ver a través del archivo /proc/[pid]/autogroup:
$ cat /proc/1/autogroup
/autogroup-1 nice 0
Este archivo también se puede utilizar para modificar el ancho de banda de la CPU asignado a un grupo automático. Esto se hace escribiendo un número en el rango "agradable" en el archivo para establecer el valor agradable del autogrupo. El rango permitido es de +19 (prioridad baja) a -20 (prioridad alta).
La configuración agradable del autogrupo tiene el mismo significado que el valor agradable del proceso, pero se aplica a la distribución de ciclos de CPU al autogrupo en su conjunto, en función de los valores agradables relativos de otros autogrupos. Para un proceso dentro de un autogrupo, los ciclos de CPU que recibe serán un producto del valor agradable del autogrupo (en comparación con otros autogrupos) y del valor agradable del proceso (en comparación con otros procesos en el mismo grupo automático).