En el pasado, cuando Linux era solo una idea en la mente de Linus Torvalds, las CPU eran entidades de un solo núcleo que requerían una inmensa cantidad de energía con poca potencia. El primer procesador disponible comercialmente, el Intel 4004, funcionaba a una velocidad de reloj de 740 kHz en un solo núcleo. En ese entonces, no había necesidad de un programador de carga. La programación de carga estaba reservada para los "gigantes" de doble núcleo, como el IBM Power 4, que salió algunas décadas después. Estos funcionaban a una velocidad bestial de 1,1 GHz a 1,9 GHz y requerían que los programas y el sistema utilizaran estos núcleos correctamente. ¿Cómo pasamos de estas máquinas a los algoritmos de software que hacen uso de múltiples núcleos? Es posible que haya oído hablar de Energy Aware Scheduling (EAS) en nuestros foros antes. Es parte de la razón por la que los teléfonos inteligentes Google Pixel funcionan tan bien. ¿Qué tiene de bueno EAS y cómo llegamos a este punto? Antes de poder explicarlo, debemos hablar de los programadores de carga de Linux.

La evolución de los programadores de carga de Linux

Programación por turnos

El procesamiento por turnos es un concepto sencillo de explicar y comprender, y aún más sencillo de captar sus desventajas. El procesamiento por turnos utiliza la división del tiempo para asignar tiempo a cada proceso. Supongamos que tenemos cuatro procesos ejecutándose en nuestra computadora.

• Proceso A
• Proceso B
• Proceso C
• Proceso D

Ahora, hagamos el trabajo del planificador round-robin. Asignaremos 100 milisegundos (fragmentación de tiempo) a cada proceso antes de pasar al siguiente. Esto significa que el proceso A puede tardar 100 milisegundos en realizar su procesamiento, luego pasa al proceso B y así sucesivamente. Si el trabajo de una aplicación tarda 250 milisegundos en realizarse, ¡tendrá que pasar por este proceso 3 veces solo para terminar su trabajo! Ahora escale esto entre diferentes núcleos, de modo que el proceso A y el proceso B se asignen al núcleo 1, y el proceso C y el proceso D se asignen al núcleo 2. Esto fue reemplazado por la programación O(n) (que era como round-robin, pero usando épocas y permitiendo la asignación dinámica de tiempo), luego la programación O(1) (sobrecarga minimizada, soporte de proceso ilimitado) y, finalmente, el planificador completamente justo (CFS). CFS se fusionó con la versión 2.6.23 del kernel de Linux en octubre de 2007. Se ha revisado desde entonces y sigue siendo el programador predeterminado en los sistemas Linux.

Programador completamente justo

El Completely Fair Scheduler existe en Android desde sus inicios y se utiliza en dispositivos que no son big.LITTLE. Utiliza un algoritmo inteligente para determinar el orden de procesamiento, el tiempo asignado, etc. Es un ejemplo de una implementación funcional del algoritmo de programación bien estudiado llamado "cola justa ponderada". Básicamente, se centra en dar prioridad a los procesos del sistema y otros procesos de alta prioridad que se ejecutan en la máquina. Si se ejecutara en un dispositivo big.LITTLE, todos los núcleos se percibirían como iguales. Esto es malo, ya que los núcleos de bajo consumo pueden verse obligados a ejecutar aplicaciones intensivas o, peor aún, puede ocurrir lo contrario. La decodificación para escuchar música puede realizarse en el núcleo grande, por ejemplo, lo que aumenta el consumo de energía innecesariamente. Es por eso que necesitamos un nuevo programador para big.LITTLE, uno que pueda realmente reconocer y utilizar la diferencia en los núcleos de una manera energéticamente eficiente. Ahí es donde entra en juego el multiprocesamiento heterogéneo (HMP), el programador de carga estándar que la mayoría de los teléfonos Android están ejecutando actualmente.

Multiprocesamiento heterogéneo

Este es el programador de carga estándar para cualquier dispositivo big.LITTLE lanzado en los últimos años, excepto el Google Pixel. HMP hace uso de la arquitectura big.LITTLE, delegando trabajo de baja prioridad y menos intensivo a los núcleos pequeños que consumen menos energía. HMP es "seguro" porque sabe qué debe ir a los núcleos grandes y qué debe ir a los núcleos pequeños, sin cometer errores. Simplemente funciona y requiere mucho menos esfuerzo de configuración en el lado del desarrollo que algo como EAS, que veremos en un momento. HMP es solo una extensión de CFS para que sea consciente del consumo de energía.

HMP no hace conjeturas ni predice procesos futuros. Esto es bueno, pero es por eso que el dispositivo no puede ser tan fluido como los que ejecutan EAS y también por eso consume un poco más de batería. Esto, finalmente, nos lleva a Energy Aware Scheduling (EAS), que creo firmemente que es el futuro en el desarrollo de ROM y kernel a medida que más OEM lo adopten.

Programación consciente de la energía

Energy Aware Scheduling (EAS) es el próximo gran avance del que hablan los usuarios de nuestros foros. Si utilizas un OnePlus 3 (o un Google Pixel, obviamente), seguramente habrás oído hablar de él en los foros. Se lanzó al mercado con el Qualcomm Snapdragon 845, así que si tienes uno de estos dispositivos ya tienes un smartphone con EAS habilitado. EAS en forma de núcleos comoRenderZenithy ROM comoVertexOSyPureFusionarrasaron en los foros de OnePlus 3 en su mejor momento. Por supuesto, el Google Pixel también viene con EAS. Con las promesas de una mayor duración de la batería y un mejor rendimiento, ¿cuál es el truco?

Energy Aware Scheduling no es tan simple como tampoco es universal para todos los dispositivos como CFS o HMP. EAS requiere una comprensión del procesador en el que se ejecuta, en función de un modelo de energía. Estos modelos de energía son creados por equipos de ingenieros que prueban y trabajan constantemente para brindar un rendimiento óptimo. Como el Snapdragon 820 y el 821 son básicamente iguales, los núcleos personalizados en el OnePlus 3 utilizan el modelo de energía de Google Pixel. Los dispositivos con el Snapdragon 845 pueden utilizar EAS, y el OnePlus 6 lo hace hasta cierto punto. No está tan optimizado como lo estaría un dispositivo Google Pixel, pero hace el trabajo. Aquí hay un ejemplo de cómo, a pesar de que el OnePlus 6 tiene un mejor procesador con EAS, el Pixel 2 XL aún lo supera en fluidez. Ambas imágenes fueron tomadas de nuestrarevisión orientada a la velocidaddel OnePlus 6.

Si tiene problemas para comprender los gráficos, puede echar un vistazo a la imagen a continuación para obtener orientación. Todo lo que supere la línea verde indica pérdida de fotogramas y, en el peor de los casos, un parpadeo notable.

La implementación de EAS en el OnePlus 6 es interesante, ya que no parece ser una implementación completa como la que encontrarías en un Google Pixel con el mismo SoC. Los ajustes del programador tampoco tienen mucho sentido, por lo que probablemente eso explique por qué no es tan eficiente en términos de rendimiento como esperarías. Es extremadamente conservador en cuanto al consumo de energía, y el sistema prioriza los núcleos de bajo consumo para la mayor parte del trabajo.

Los parámetros ajustables son simplemente un conjunto de parámetros que se pasan al regulador de la CPU, que cambia la forma en que el regulador reacciona a ciertas situaciones en términos de frecuencia. El programador luego decide dónde colocar las tareas en diferentes procesadores. Los parámetros ajustables del OnePlus 6 están configurados para priorizar el trabajo en núcleos de baja potencia. Tampoco ayuda que el Google Pixel 2 tenga una gran cantidad de refuerzo de entrada, manteniendo los 8 núcleos en línea todo el tiempo. Google también usa unbalanceador de interrupcionesque ayuda a eliminar las caídas de cuadros y mejorar el rendimiento.

¿Cómo funciona el EAS? ¿Por qué es tan eficaz sólo en determinadas condiciones?

La programación consciente de la energía introduce la necesidad de utilizar un modelo de energía y, como se mencionó anteriormente, requiere muchas pruebas y trabajo para perfeccionarlo. La programación consciente de la energía intenta unificar tres partes principales diferentes del núcleo que actúan de forma independiente, y el modelo de energía ayuda a unificarlas.

• Programador de Linux (CFS, mencionado anteriormente)
• CPU inactiva de Linux
• Frecuencia de CPU de Linux

Unificar las tres partes bajo el planificador y calcularlas juntas brinda un potencial de ahorro de energía, ya que calcularlas juntas les permite ser lo más eficientes posible. CPUIdle intenta decidir cuándo la CPU debe pasar a un modo inactivo, mientras que CPUFreq intenta decidir cuándo aumentar o disminuir la CPU. Ambos módulos tienen el objetivo principal de ahorrar energía. No solo eso, luego clasifica los procesos en cuatro grupos de control: aplicación principal, segundo plano del sistema, primer plano y segundo plano. Las tareas que deben procesarse se colocan en una de estas categorías y luego se le otorga potencia de CPU a la categoría y el trabajo se delega en diferentes núcleos de CPU. La aplicación principal es la prioridad más alta de finalización, seguida de primer plano, segundo plano y luego segundo plano del sistema. Segundo plano técnicamente tiene la misma prioridad que segundo plano del sistema, pero segundo plano del sistema generalmente también tiene acceso a más núcleos pequeños. En efecto, Energy Aware Scheduling toma partes centrales del núcleo de Linux y las unifica en un solo proceso.

Al activar el dispositivo, EAS elegirá el núcleo en el estado inactivo más superficial, lo que minimiza la energía necesaria para activar el dispositivo. Esto ayuda a reducir la energía requerida para usar el dispositivo, ya que no activará el clúster grande si no es necesario. El seguimiento de carga también es una parte extremadamente crucial de EAS, y hay dos opciones. El "seguimiento de carga por entidad" (PELT) se usa generalmente para el seguimiento de carga, la información se usa luego para decidir frecuencias y cómo delegar tareas en la CPU. El "seguimiento de carga asistido por ventana" (WALT) también se puede usar y es lo que se usa en Google Pixel. Muchas ROM de EAS en nuestros foros, como VertexOS, optan por usar WALT. Muchas ROM lanzarán dos versiones del kernel con WALT o PELT, por lo que depende del usuario decidir. WALT es más intermitente, con picos altos en la frecuencia de la CPU, mientras que PELT intenta permanecer más constante. El rastreador de carga en realidad no afecta la frecuencia de la CPU, solo le dice al sistema cuál es el uso de la CPU. Un mayor uso de la CPU requiere una mayor frecuencia y, por lo tanto, una característica constante de PELT es que hace que la frecuencia de la CPU aumente o disminuya lentamente. PELT tiende a inclinarse hacia un mayor informe de carga de la CPU, por lo que puede proporcionar un mayor rendimiento con un mayor costo de batería. Sin embargo, nadie puede decir realmente en este momento qué sistema de rastreo de carga es mejor, ya que ambos métodos de rastreo de carga se están parcheando y refinando continuamente.

De cualquier manera, es obvio que, independientemente del método de seguimiento de carga utilizado, hay un aumento en la eficiencia. En lugar de simplemente procesar tareas en cualquier procesador, se analiza la tarea y se estima la cantidad de energía necesaria para ejecutarla. Esta inteligente ubicación de las tareas significa que las tareas se completan de una manera mucho más eficiente y, al mismo tiempo, hace que el sistema sea más rápido en su conjunto. EAS tiene como objetivo lograr la interfaz de usuario más fluida posible con un consumo mínimo de energía. Aquí es donde entran en juego otros componentes externos como schedtune.

Schedtune se define en cada cgroup mediante dos parámetros ajustables que garantizan un control más preciso de las tareas que se deben completar. No solo controla la distribución de las tareas en varias CPU, sino también si la carga percibida debe aumentarse para garantizar que las tareas urgentes se completen más rápido. De esta manera, las aplicaciones y los servicios en primer plano que utiliza el usuario no se ralentizarán ni causarán problemas de rendimiento innecesarios.

Si bien Energy Aware Scheduling es el gran futuro, también se puede decir que ya está aquí y que lo está desde hace tiempo. Con cada vez más dispositivos que se están popularizando con Energy Aware Scheduling, estamos ante una nueva era de eficiencia en el procesamiento móvil.

Pros y contras de Round-Robin, CFS, HMP y EAS

Si bien mis habilidades gráficas son inferiores, he creado una imagen que debería resumir los pros y los contras de cada uno de estos programadores.

Me gustaría agradecer especialmente al colaborador reconocido de XDAMostafa Wael,  cuyas explicaciones sobre los distintos aspectos de EAS ayudaron mucho a que este artículo fuera posible. También me gustaría agradecer al desarrollador reconocido de XDAjoshuous, al desarrollador reconocido de XDARenderBroken ya Mostafa Wael por su artículo sobre EAS. Para aquellos de ustedes que se interesaron por las piezas relacionadas con EAS, Linaro tiene mucha documentación sobre EAS que pueden leer.