multithreading - sistema - procesos e hilos en linux

¿El proceso con más hilos en Linux tendrá más tiempo de CPU que el proceso con un hilo?

Question

¿Un proceso con más hilos en Linux tendrá más tiempo de CPU que un proceso con un hilo?

En Linux, los procesos y subprocesos se describen mediante una estructura de tareas, y la programación se basa en tareas . Encontré también esto :

Cuando se crea un nuevo proceso, do_fork() establece el campo del contador de los procesos actuales (padre) y p (el hijo) de la siguiente manera:

current->counter >>= 1;
p->counter = current->counter;

En otras palabras, el número de tics que le quedan al padre se divide en dos mitades, una para el padre y otra para el hijo. Esto se hace para evitar que los usuarios obtengan una cantidad ilimitada de tiempo de CPU utilizando el siguiente método: el proceso principal crea un proceso secundario que ejecuta el mismo código y luego se auto mata; ajustando correctamente la tasa de creación, el proceso hijo siempre obtendría un nuevo quantum antes de que expire el quantum de su primario. Este truco de programación no funciona, ya que el kernel no recompensa a las horquillas. De manera similar, un usuario no puede acaparar una parte desleal del procesador iniciando muchos procesos en segundo plano en un shell o abriendo muchas ventanas en un escritorio gráfico. En términos más generales, un proceso no puede acaparar recursos (a menos que tenga privilegios para otorgarse una política en tiempo real) al bifurcar a varios descendientes.

En realidad, no encontré eso en las fuentes del kernel, pero tal vez es mi culpa, tal vez vi una versión incorrecta del kernel.

Pero, ¿qué pasará más tarde, cada hilo participará en la programación como un proceso separado? ¿Un proceso con diez hilos tendrá diez veces más tics que un proceso con un hilo? ¿Qué hay de IO en este sentido?

Answer 1

Sí, un proceso con más hilos obtendría más tiempo de CPU que sus competidores. Un caso bien conocido sería una compilación de maven, maven utiliza muchos hilos intensivos de CPU que acaparan el sistema.

Sin embargo, el programador actual de Linux no solo tiene en cuenta las tareas, sino que también tiene en cuenta los grupos de control en la jerarquía del grupo cpu. Por lo tanto, el tiempo de CPU se divide entre los grupos de control, y luego en cada grupo de control, el tiempo de CPU se divide entre las tareas.

Desde 2.6.38, Linux coloca taks automáticamente en diferentes grupos de CPU basados ​​en sus ID de sesión. Esto significa que, por ejemplo, las pestañas separadas en konsole / gnome-terminal obtienen su propio grupo de control. Así que ahora tu compilación maven está muy bien aislada, y ya no encierra el sistema. Vea las descripciones en kernelnewbies y lwn.net .

Antes de que 2.6.38 afectara a la mayoría de los sistemas, Lennart Poettering mostró cómo hacerlo manualmente en un script de shell en este mensaje LKML .

De hecho, tengo un sistema en el que ejecuto compilaciones de Eclipse y Maven, y el cambio de pre-2.6.38 a pre-2.6.38 + el enlace de cgroup de Lennart (que puse en /etc/bashrc y en mi script de iniciador de Eclipse) fue solo Perfecto. Maven ya no acapara el sistema (no sabría si hay una compilación de expertos si no fuera por el monitor de carga de la CPU), y Eclipse ahora se encierra solo, no el resto del sistema (me conformaré con eso con Eclipse). Ahora solo necesito actualizar el kernel a uno con una mejor escritura de página sucia y ese sistema será muy fácil de trabajar.