¿Procesaría más hilos en Linux tener más tiempo de CPU que procesar con un hilo?

Question

¿Un proceso con más subprocesos en Linux tendrá más tiempo de CPU que un proceso con un solo subproceso?

En Linux, los procesos y subprocesos se describen mediante una estructura de tareas, y scheduling is based on tasks. He encontrado también this:

Cuando se crea un nuevo proceso do_fork(), establece el campo contador de ambos actual (el padre) y los procesos de la siguiente forma p (el niño):

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

En en otras palabras, el número de tics que deja el 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 núcleo, pero tal vez es mi culpa, tal vez vi una versión incorrecta del kernel.

Pero, ¿qué pasará más tarde, cada thread 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 subprocesos tendrí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.

Pero, el programador de Linux actual no solo tiene en cuenta las tareas, sino que también tiene en cuenta los grupos de control en la jerarquía de grupos de 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 automáticamente las taks en diferentes grupos de cpu en función de sus identificadores de sesión. Esto significa que, por ejemplo, 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 la versión 2.6.38 llegara a la mayoría de los sistemas, Lennart Poettering mostró cómo hacerlo manualmente en un script de shell al this LKML message.

De hecho, tengo un sistema en el corro Eclipse y experto compila, y el cambio de pre-2.6.38 a 2.6.38 + pre-vinculante cgroup de Lennart (que me puse /etc/bashrcy en mi script lanzador Eclipse) fue simplemente 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.