Los teléfonos inteligentes Google Pixel se encuentran entre los teléfonos Android más rápidos del mercado. La programación consciente de la energía (EAS) es en parte la razón por la que el teléfono es tan fluido.
En el pasado, cuando Linux era sólo 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 por poca energía. El primer procesador disponible comercialmente, el Intel 4004, funcionaba a una frecuencia de 740 kHz en un solo núcleo. En aquel 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 apareció 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 algoritmos de software que utilizan múltiples núcleos? Es posible que haya oído hablar de la Programación consciente de la energía (EAS) en nuestros foros anteriormente. Es parte de la razón por la cual los teléfonos inteligentes Google Pixel funcionan tan bien. ¿Qué tiene de bueno EAS y cómo llegamos a este punto? Antes de que podamos explicar eso, debemos hablar sobre 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 comprender sus desventajas. El round-robin 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 programador por turnos. Asignaremos 100 milisegundos (intervalo 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, deberá realizar este proceso 3 veces para finalizar su trabajo. Ahora escale esto en 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 una operación por turnos, pero usando épocas y permitiendo la asignación dinámica de tiempo), luego programación O(1) (gastos generales minimizados, soporte de proceso ilimitado), y finalmente el Programador completamente justo (SFC). CFS se fusionó con la versión 2.6.23 del kernel de Linux en octubre de 2007. Ha sido revisado desde entonces y sigue siendo el programador predeterminado en los sistemas Linux.
Programador completamente justo
El Programador completamente justo ha existido en Android desde sus inicios y se utiliza en aplicaciones no grandes. PEQUEÑOS dispositivos. 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". Esto básicamente se centra en dar prioridad a los procesos del sistema y otros procesos de alta prioridad que se ejecutan en el máquina. Si fuera a correr en un grande. PEQUEÑO dispositivo, 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 se puede realizar en el núcleo grande, por ejemplo, aumentando innecesariamente el consumo de energía. Por eso necesitamos un nuevo programador para los grandes. LITTLE, uno que realmente puede 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 ejecutan la mayoría de los teléfonos Android actualmente.
Multiprocesamiento heterogéneo
Este es el programador de carga estándar para cualquier empresa grande. PEQUEÑO dispositivo lanzado en los últimos años, aparte del Google Pixel. HMP hace uso de lo grande. PEQUEÑA arquitectura, delegando trabajo de baja prioridad y menos intensivo a los pequeños núcleos 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 para configurarlo en el lado del desarrollo que algo como EAS, del que hablaremos en un momento. HMP es sólo una extensión de CFS para que tenga en cuenta el poder.
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 es por lo que 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
La programación consciente de la energía (EAS) es el próximo gran tema del que hablan los usuarios en nuestros foros. Si utilizas un OnePlus 3 (o un Google Pixel, obviamente) seguro que has oído hablar de él en los foros. Se lanzó al mercado con el Qualcomm Snapdragon 845, por lo que si tienes uno de estos dispositivos, ya tienes un teléfono inteligente con capacidad EAS. EAS en forma de núcleos como RenderZenith y ROM como VértexOS y Pura fusión estaban arrasando 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 problema?
La programación consciente de la energía no es tan simple ya que no es universal para todos los dispositivos como CFS o HMP. EAS requiere comprender el procesador en el que se ejecuta, basándose en un modelo energético. Estos modelos energéticos son fabricados por equipos de ingenieros probando y trabajando constantemente para dar un rendimiento óptimo. Como Snapdragon 820 y 821 son básicamente iguales, los núcleos personalizados del OnePlus 3 utilizan el modelo energético de Google Pixel. Los dispositivos con 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 nuestra revisión orientada a la velocidad del OnePlus 6.
Si tiene problemas para comprender los gráficos, puede consultar la imagen a continuación como guía. Cualquier cosa que exceda la línea verde indica fotogramas perdidos y, en el peor de los casos, un tartamudeo notable.
La implementación de EAS en 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 el rendimiento como cabría esperar. Es extremadamente conservador en el consumo de energía, y el sistema prioriza los núcleos de baja potencia para la mayor parte del trabajo.
Los sintonizables son simplemente un conjunto de parámetros que se pasan al gobernador de la CPU, lo que cambia la forma en que el gobernador reacciona ante ciertas situaciones en términos de frecuencia. Luego, el programador decide dónde ubica las tareas en los diferentes procesadores. Los sintonizables del OnePlus 6 están configurados para priorizar el trabajo en núcleos de baja potencia. Tampoco ayuda que Google Pixel 2 tenga una gran cantidad de impulso de entrada, manteniendo los 8 núcleos en línea todo el tiempo. Google también utiliza un equilibrador de interrupciones lo que ayuda a eliminar las caídas de fotogramas y mejorar el rendimiento.
Entonces, ¿cómo funciona EAS? ¿Por qué es tan eficaz sólo en determinadas condiciones?
Energy Aware Scheduling introduce la necesidad de utilizar un modelo energético y, como se mencionó anteriormente, requiere muchas pruebas y trabajo para hacerlo perfecto. EAS intenta unificar tres partes centrales diferentes del núcleo que actúan de forma independiente, y el modelo energético ayuda a unificarlas.
- Programador de Linux (CFS, mencionado anteriormente)
- CPU Linux
- frecuencia de CPU de Linux
Unificar las 3 partes bajo el programador 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 entrar en 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: aplicación superior, fondo del sistema, primer plano y fondo. Las tareas que deben procesarse se colocan en una de estas categorías, y luego a la categoría se le asigna potencia de CPU y el trabajo se delega a diferentes núcleos de CPU. top-app es la prioridad más alta de finalización, seguida de primer plano, fondo y luego fondo del sistema. Técnicamente, el fondo tiene la misma prioridad que el fondo del sistema, pero el fondo del sistema generalmente también tiene acceso a más núcleos pequeños. De hecho, Energy Aware Scheduling toma partes centrales del kernel 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, minimizando la energía necesaria para activar el dispositivo. Esto ayuda a reducir la energía necesaria para usar el dispositivo, ya que no activará el clúster grande si no es necesario. El seguimiento de la 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; luego, la información se usa para decidir las frecuencias y cómo delegar tareas en la CPU. También se puede utilizar el "Seguimiento de carga asistido por ventana" (WALT) y es lo que se utiliza en Google Pixel. Muchas ROM EAS en nuestros foros, como VertexOS, optan por utilizar WALT. Muchas ROM lanzarán dos versiones del kernel con WALT o PELT, por lo que la decisión depende del usuario. WALT es más ráfaga, con picos altos en la frecuencia de la CPU, mientras que PELT intenta permanecer más consistente. El rastreador de carga en realidad no afecta la frecuencia de la CPU, simplemente le dice al sistema cuál es el uso de la CPU. Un mayor uso de la CPU requiere una frecuencia más alta, por lo que una característica constante de PELT es que hace que la frecuencia de la CPU aumente o disminuya lentamente. PELT tiende a desviarse hacia informes de carga de CPU más altos, 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 seguimiento de carga es mejor, ya que ambos métodos de seguimiento de carga se actualizan y perfeccionan 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 asignación inteligente de 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 se trata de obtener la interfaz de usuario más fluida posible con un uso 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 sobre las tareas a completar. No solo controla la distribución de tareas en múltiples CPU, sino también si la carga percibida debe inflarse para garantizar que las tareas urgentes se completen más rápido. De esta manera, las aplicaciones y servicios en primer plano que utiliza el usuario no se ralentizarán ni causarán problemas de rendimiento innecesarios.
Si bien la programación consciente de la energía es el próximo gran avance, también se puede argumentar que ya está aquí y lo ha estado por un tiempo. Con cada vez más dispositivos llegando a la corriente principal con Energy Aware Scheduling, ha llegado una nueva era de eficiencia de procesamiento móvil.
Los pros y los contras de Round-Robin, CFS, HMP y EAS
Si bien mis habilidades gráficas son deficientes, he elaborado una imagen que debería resumir los pros y los contras de cada uno de estos programadores.
Me gustaría extender un agradecimiento especial al colaborador reconocido de XDA. Mostafa Wael cuyas explicaciones de varios aspectos de EAS ayudaron enormemente a hacer posible este artículo. También me gustaría agradecer al desarrollador reconocido de XDA. josué, Desarrollador reconocido por XDA renderizado roto y Mostafa Wael por su artículo sobre EAS. Para aquellos de ustedes que encontraron interés en partes relacionadas con EAS, Linaro tiene mucha documentación sobre EAS que pueden leer.