Sería razonable suponer que para el núcleo sería bastante fácil no hacer nada, pero no lo es. En la conferencia
Kernel Recipes 2018 ,
Rafael Vysotsky habló sobre lo que hacen los procesadores, cuándo no tienen nada que hacer, cómo lo procesa el núcleo, cuál es su estrategia actual y cómo su trabajo reciente en el
ciclo inactivo ha mejorado la situación energética de los sistemas que no hacen nada. .
El ciclo de inactividad, uno de los subsistemas del núcleo que admite Vysotsky, controla lo que hace la CPU cuando no necesita ejecutar ningún proceso. Vysotsky dio todas las definiciones con mucha precisión: una CPU es una entidad que puede recibir instrucciones de la memoria y ejecutarlas simultáneamente con otras entidades del mismo sistema que se ocupan de lo mismo. En el sistema de procesador único más simple con un núcleo, este núcleo es la CPU. Si el procesador tiene varios núcleos, cada uno de estos núcleos es una CPU. Si cada uno de los núcleos tiene varias interfaces para ejecutar instrucciones simultáneamente, Intel llama a este sistema "
hyperthreading ", entonces cada uno de estos hilos será una CPU.
La CPU está inactiva cuando no tiene tareas que realizar. O, más precisamente, el kernel de Linux tiene varias clases internas para despachar, una de las cuales es una clase inactiva especial. Si no hay tareas en esta CPU en ninguna de las clases, excepto en la clase de inactividad, la CPU se considera inactiva. Si el equipo no permite esto, entonces la CPU tendrá que llevar a cabo instrucciones inútiles hasta que el trabajo real aparezca. Sin embargo, este es un uso extremadamente ineficiente de la electricidad, por lo que la mayoría de los procesadores admiten varios estados de baja energía en los que el núcleo los transfiere hasta que se necesitan para realizar un trabajo útil.
No puede simplemente entrar o salir de un estado de inacción. Toma tiempo ingresar y salir, y además, cuando ingresa a este estado, el consumo de energía del estado actual aumenta ligeramente, y cuando sale, consume el estado en el que entra el procesador. Y aunque cuanto más profundo es el estado de inactividad, menos energía consume el procesador, aumenta el costo de entrar y salir a tales estados. Esto significa que en el caso de períodos cortos de inactividad, el mejor uso de los recursos de la computadora será una inacción superficial; durante períodos más largos, el costo de pasar a un estado más profundo de inacción se justificará por un aumento en la cantidad de energía ahorrada. Por lo tanto, le interesa al kernel predecir cuánto tiempo estará inactivo el procesador antes de decidir qué tan profundo necesita el estado de inactividad. Esta es la tarea del ciclo de inacción.
En este ciclo, el planificador se da cuenta de que la CPU está inactiva, ya que no tiene ninguna tarea que se le pueda asignar. Luego, el programador llama al regulador, que intenta dar la mejor predicción del estado de inacción apropiado, en el que puede ingresar. Ahora en el kernel hay dos controles, menú y escalera. Se usan en diferentes casos, pero ambos intentan hacer aproximadamente lo mismo: monitorear el estado del sistema cuando la CPU pasa a estado inactivo y el tiempo que pasó inactivo. Esto se hace para predecir cuánto tiempo la CPU pasará a un estado inactivo y, por lo tanto, qué estado es el más adecuado para esta situación.
Este trabajo es especialmente complicado por el temporizador del planificador de la CPU. El programador inicia este temporizador para dividir el tiempo de acceso a la CPU: si es necesario realizar varias tareas en un procesador, cada una de ellas puede realizarse solo un poco y luego posponerse periódicamente en favor de otra tarea. No es necesario realizar este temporizador en una CPU inactiva, ya que no hay tareas entre las que deba dividirse la CPU. Además, si se permite que el temporizador se ejecute en una CPU inactiva, esto evitará que el controlador seleccione estados inactivos profundos, limitando los intervalos durante los cuales la CPU está inactiva. Por lo tanto, en núcleos hasta 4.16, el programador apagó el temporizador antes de llamar al regulador. Cuando la CPU se despertó tras la interrupción, el planificador decidió si había tareas necesarias para la ejecución y, si hubo alguna, reinició el temporizador.
Si el controlador predice un largo período de inactividad, y este período realmente resulta ser largo, entonces el controlador "gana": la CPU entra en un estado de inactividad profunda y se ahorra energía. Pero si el regulador predice un largo período de inactividad, y este período resulta corto, entonces el regulador "pierde", ya que el costo de entrar en una inacción profunda no vale la pena ahorrando energía por un corto período de inactividad. Peor aún, cuando el regulador predice un corto tiempo de inactividad, entonces "pierde" sin importar el tiempo de inactividad: si el período resultó ser largo, se perdió la oportunidad de ahorrar, y si fue corto, se desperdiciaron los costos de detener y reiniciar el temporizador. O, en otras palabras, dado que se gastan recursos para detener e iniciar el temporizador, no tiene sentido detenerlo cuando el controlador predice un breve tiempo de inactividad.
Vysotsky decidió intentar cambiar el funcionamiento del regulador, pero llegó a la conclusión de que el problema principal es que el temporizador se detiene antes de que se llame al regulador, es decir, antes de que se conozca el estado de inactividad recomendado. Regresó un ciclo inactivo en el kernel 4.17 para que la decisión de detener el temporizador se tomara después de que el regulador hiciera su recomendación. Si predijo un largo tiempo de inactividad, el temporizador se detiene para no despertar la CPU con anticipación. Si se supone que el tiempo de inactividad es corto, se deja el temporizador para no desperdiciar recursos en paradas. Esto significa que el temporizador también realiza una función de seguridad, despertando la CPU si el tiempo de inactividad resultó ser más largo de lo previsto, y le da al regulador una segunda oportunidad para la decisión correcta.
Cuando una CPU inactiva se activa a través de una interrupción, ya sea un temporizador imparable u otro evento, el programador decide inmediatamente si hay trabajo. Si hay trabajo, el temporizador se reinicia según sea necesario. Si no, se llama al controlador. Como esto significa que ahora se puede llamar al regulador tanto cuando el temporizador está funcionando como cuando no está funcionando, se debe llamar al regulador para tener esto en cuenta.
Después de estudiar la tabla de victorias y derrotas, Vysotsky cree que sus cambios mejorarán la imagen. En el caso de predecir un largo período de inactividad, el temporizador aún se detiene, por lo que aquí no cambia nada; ganamos si el tiempo de inactividad es largo y perdemos si es corto. Pero si se predice un corto período de inactividad, ganamos: si el período realmente resulta ser corto, ahorraremos en detener e iniciar el temporizador, y si es largo, el temporizador sin parar nos despertará y nos dará la oportunidad de hacer otra predicción.
Dado que la teoría de juegos no puede servir como un reemplazo completo para la situación real, Vysotsky probó este enfoque en muchos sistemas. El gráfico anterior es típico para todos los sistemas probados; muestra la dependencia del tiempo del consumo de energía en un sistema inactivo. La línea verde es el antiguo ciclo de inacción, la línea roja es el nuevo. Según el nuevo esquema, se consume menos energía, además, es más predecible. No todas las CPU probadas tuvieron una brecha tan grande entre las líneas, sin embargo, todas mostraron una línea roja plana debajo de un verde desigual. Como dijo Vysotsky, es menos probable que este nuevo esquema prediga períodos cortos de inactividad, pero a menudo resulta ser correcto acerca de su corta duración.
Respondiendo una pregunta de la audiencia, Vysotsky dijo que este trabajo depende de la arquitectura. En particular, los procesadores Intel se beneficiarán de él, ya que tienen una gran variedad de estados de inactividad de los cuales el regulador puede elegir el que le dará la mejor oportunidad de éxito si la predicción es correcta; pero los procesadores ARM también se beneficiarán de los nuevos circuitos.
Una caída del 20% en el consumo de energía cuando está inactivo puede parecer un logro insignificante, pero en realidad no lo es. Cualquier sistema que quiera hacer frente bastante bien a las cargas máximas debe tener una reserva de energía en modo normal, que se manifestará durante la inactividad. El gráfico anterior muestra el uso del procesador para el año en mi servidor, que se ocupa del correo, la transferencia de archivos, VPN, NTP, etc. Amarillo significa tiempo simple. A mi proveedor le gustaría ahorrar un 20% de esta energía, y para el planeta sería mejor.