El programador de procesos de Linux es un programador general, ya sea O (n) O (n)O ( n )，O (1) O (1)O ( 1 ) , o CFS, trata todos los procesos según un índice unificado. En otras palabras, el proceso ni siquiera puede ceder por sí solo.
Siempre que se determine la prioridad de un proceso, no importa qué algoritmo de programación sea, el estado del proceso nunca cambiará. Sería genial si se pudiera lograr la siguiente estrategia:
- Si hay más procesos en el sistema, se acelerará y cederá.
- Si hay menos procesos en el sistema, la preferencia se acelera.
- Cuando llegaron los trabajadores, se rindieron.
- Cuando llega el gerente, se adelanta.
- ...
Considere un proceso A que se ejecuta en un sistema específico, solo puede usar hasta el 40% de la CPU, en este momento, si hay otros procesos para ejecutar, entonces estos procesos compartirán naturalmente el otro 60% de la CPU, si viene otro proceso A ? Obviamente, el tiempo de CPU de los dos procesos A se reducirá.
¿Se puede garantizar que los dos procesos A todavía usan el 40% de la CPU, y luego otros procesos comparten el 20% restante de la CPU? ¡Difícil!
Puedes decir que puedes configurar un grupo, pero debe haber un proceso de configuración estático, que es difícil de adaptar dinámicamente.
En otras palabras, ¡el programador de Linux es inelástico!
El siguiente código muestra una programación sencilla y flexible:
#!/usr/local/bin/stap -g
probe kernel.function("__enqueue_entity")
{
task = _task_of($se)
pid = @cast(task, "struct task_struct")->pid
if ($1 == pid) {
_nr = $cfs_rq->nr_running
t = $se->vruntime;
$se->vruntime = t + 3000000*(_nr - 1)
}
}
Significa que el proceso especificado rinde según la cantidad de carga en el sistema:
- Cuanto mayor sea la carga del sistema, menor será la proporción de tiempo de CPU ocupado por el proceso especificado.
- Cuanto menor sea la carga del sistema, mayor será la proporción de tiempo de CPU ocupado por el proceso especificado.
Ven y mira el efecto:
puedes ver:
- Cuando solo hay un bucle, ocupa el 100% de la CPU.
- Al regenerar un bucle, divide casi por igual la CPU con el primer bucle.
- Cuando se ejecutan más y más bucles, la parte de CPU del primer bucle disminuye gradualmente.
- Esta es la misma raíz, solo el primer bucle es flexible.
Bueno, el efecto está bien, pero no lo suficientemente suave. ¿Prueba una curva cuadrática o una curva cúbica?
$se->vruntime = t + 200*(_nr - 1)*_nr*_nr
// or
// $se->vruntime = t + 20000*(_nr - 1)*_nr
¿De dónde viene 200? Es necesario ajustar bien los parámetros.
Además, mi estrategia flexible aquí es demasiado simple, de hecho, puede diseñarse para ser lo suficientemente compleja. Por ejemplo, una estrategia específica para un proceso específico, incluso un simple segmento de línea recta de doble pendiente, es mejor que la mía, correcto, no pretenda ser forzado, no mucho Decir.
Alguien preguntó cómo encontrar el código que se va a modificar. Mientras esté familiarizado con los principios de implementación del kernel de Linux, no es difícil. Para los artesanos, Archimedes, Luban, Pao Ding y Huang Daopo son dignos de estatus. Más que Euclides, Descartes.
Los zapatos de cuero en Wenzhou, Zhejiang están mojados, ¡así que no engordan con la lluvia!