Cómo EAS ayuda a que Google Pixel sea el teléfono Android más rápido

Lo que significa para tu próximo teléfono inteligente

Mucho 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 por poca energía. El primer procesador disponible comercialmente, el Intel 4004, funcionó a una velocidad de reloj de 740 kHz en un solo núcleo. En aquel entonces, no había necesidad de un planificador 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 corrían a una velocidad de 1.1GHz a 1.9GHz y requerían programas y el sistema para utilizar 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 Energy Aware Scheduling (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, necesitamos hablar sobre los planificadores de carga de Linux.


La evolución de los programadores de carga de Linux

Programación Round-Robin

Procesamiento Round Robin. Fuente: Wikipedia

El procesamiento de round robin es un concepto simple para explicar y comprender, y uno aún más simple para comprender sus desventajas. Round-robin usa el corte de 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 round-robin. Asignaremos 100 milisegundos (división de tiempo) a cada proceso antes de pasar al siguiente. Esto significa que el Proceso A puede tomar 100 milisegundos para hacer su procesamiento, luego se mueve al Proceso B y así sucesivamente. Si el trabajo de una aplicación demora 250 milisegundos, tendrá que pasar por este proceso 3 veces solo para terminar su trabajo. Ahora escale esto a través de 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 la programación O (1) (sobrecarga minimizada, soporte de proceso ilimitado), y finalmente el Programador Completamente Justo (CFS). CFS se fusionó con el kernel de Linux versión 2.6.23 en octubre de 2007. Se ha 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 su inicio y se utiliza en dispositivos no grandes. 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 se centra básicamente en proporcionar prioridad a los procesos del sistema y otros procesos de alta prioridad. corriendo 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 baja potencia pueden verse obligados a ejecutar aplicaciones intensivas, o peor aún, puede ocurrir lo contrario. La decodificación para escuchar música se puede hacer en el núcleo grande, por ejemplo, aumentando el consumo de energía innecesariamente. Es por eso que necesitamos un nuevo programador para big.LITTLE, uno que realmente pueda reconocer y utilizar la diferencia en núcleos de una manera eficiente. Ahí es donde entra en juego el procesamiento múltiple heterogéneo (HMP), el programador de carga estándar que la mayoría de los teléfonos Android están ejecutando ahora.

Procesamiento múltiple heterogéneo

Este es el programador de carga estándar para cualquier dispositivo big.LITTLE lanzado en los últimos años, que no sea Google Pixel. HMP utiliza 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" en el que sabe lo que debe ir a los núcleos grandes y lo que debe ir a los núcleos pequeños, sin cometer errores. Simplemente funciona y requiere mucho menos esfuerzo para instalarse en el lado del desarrollo que algo como EAS, que abordaremos en un momento. HMP es solo 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 aquellos que ejecutan EAS y también es por eso que consume un poco más de batería. Esto, finalmente, nos lleva a Energy Aware Scheduling (EAS), que creo firmemente 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 la próxima gran cosa de la que hablan los usuarios en nuestros foros. Si usa un OnePlus 3 (o un Google Pixel, obviamente), definitivamente lo ha escuchado en los foros. Se lanzó a la corriente principal con Qualcomm Snapdragon 845, por lo que si tiene uno de estos dispositivos, ya tiene un teléfono inteligente habilitado para EAS. EAS en forma de núcleos como RenderZenith y ROM como VertexOS y PureFusion estaban tomando los foros de OnePlus 3 por sorpresa. Por supuesto, 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 con conocimiento de energía no es tan simple como no es universal para todos los dispositivos como CFS o HMP. EAS requiere una comprensión del procesador en el que se está ejecutando, basado en un modelo de energía. Estos modelos de energía están hechos por equipos de ingenieros que constantemente prueban y trabajan para brindar un rendimiento óptimo. Como Snapdragon 820 y 821 son básicamente lo mismo, los núcleos personalizados en OnePlus 3 utilizan el modelo de energía Google Pixel. Los dispositivos con Snapdragon 845 pueden utilizar EAS, y OnePlus 6 lo hace hasta cierto punto. No está tan afinado como lo estaría un dispositivo Google Pixel, pero hace el trabajo. Aquí hay un ejemplo de cómo, a pesar de que OnePlus 6 tiene un mejor procesador con EAS, el Pixel 2 XL aún lo supera en suavidad. 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 para obtener orientación. Cualquier cosa que exceda la línea verde indica cuadros caídos y, en el peor de los casos, tartamudeo notable.

La implementación de OnePlus 6 de EAS es interesante, ya que no parece ser una implementación completa como la que encontraría en un Google Pixel con el mismo SoC. Los ajustables del planificador tampoco tienen mucho sentido, por lo que probablemente eso explica por qué no es tan eficiente en el rendimiento como cabría esperar. Es extremadamente conservador en consumo de energía, con el sistema priorizando los núcleos de baja potencia para la mayoría del trabajo.

Los parámetros ajustables son simplemente un conjunto de parámetros que se pasan al gobernador de la CPU, que cambia la forma en que el gobernador reacciona ante ciertas situaciones en términos de frecuencia. El planificador luego 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 que ayuda a eliminar las caídas de cuadros y mejorar el rendimiento.

Entonces, ¿cómo funciona EAS? ¿Por qué es tan eficiente solo en ciertas condiciones?

La programación con conocimiento de energía introduce la necesidad de usar un modelo de energía y, como se mencionó anteriormente, requiere muchas pruebas y trabajo para que sea perfecto. EAS intenta unificar tres partes centrales diferentes del núcleo que actúan de manera independiente, y el modelo de energía ayuda a unificarlas.

  • Programador de Linux (CFS, mencionado anteriormente)
  • Cpuidle de Linux
  • Cpufreq de Linux

Unificar las 3 partes en 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 entrar en un modo inactivo, mientras CPUFreq intenta decidir cuándo subir o bajar la CPU. Ambos módulos tienen el objetivo principal de ahorrar energía. No solo eso, sino que también clasifica los procesos en cuatro grupos c, que son top-app, system-background, foreground y background. Las tareas que deben procesarse se colocan en una de estas categorías, y luego la categoría recibe potencia de CPU y el trabajo se delega en diferentes núcleos de CPU. top-app es la máxima prioridad de finalización, seguida de primer plano, fondo y luego fondo del sistema. El fondo técnicamente 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. En efecto, Energy Aware Scheduling está tomando partes centrales del kernel de Linux y unificándolo todo en un solo proceso.

Al despertar el dispositivo, EAS elegirá el núcleo en el estado inactivo más superficial, minimizando la energía necesaria para despertar el dispositivo. Esto ayuda a reducir la potencia requerida 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, la información se usa para decidir las 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 EAS en nuestros foros, como VertexOS, optan por usar WALT. Muchas ROM lanzarán dos versiones del núcleo con WALT o PELT, por lo que depende del usuario decidir. WALT es más explosivo, con picos altos en la frecuencia de la CPU, mientras que PELT intenta mantenerse más consistente. 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 CPU requiere una frecuencia más alta, por lo que un rasgo 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 a 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 refinan 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, la tarea se analiza y se estima la cantidad de energía necesaria para ejecutarla. Esta ubicación inteligente de tareas significa que las tareas se completan de una manera mucho más eficiente y al mismo tiempo hacen que el sistema sea más rápido en su conjunto. EAS se trata de obtener la IU 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 por dos ajustables que aseguran un control más fino sobre las tareas a completar. No solo controla la dispersión de las tareas en varias CPU, sino también si la carga percibida se debe inflar para garantizar que las tareas urgentes se completen más rápido. De esta forma, las aplicaciones y servicios en primer plano que el usuario está utilizando no se ralentizarán y causarán problemas de rendimiento innecesarios.

Si bien la programación consciente de la energía es la próxima gran cosa, también se puede argumentar que ya está aquí y lo ha estado por un tiempo. Con más y más dispositivos llegando a la corriente principal con Energy Aware Scheduling, una nueva era de eficiencia de procesamiento móvil está aquí.

Los pros y los contras de Round-Robin, CFS, HMP y EAS

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


Quisiera extender un agradecimiento especial al Reconocido Colaborador Mostafa Wael cuyas explicaciones de varios aspectos de EAS ayudaron enormemente a hacer posible este artículo. También me gustaría agradecer a los desarrolladores reconocidos joshuous, los desarrolladores reconocidos RenderBroken y Mostafa Wael por sus comentarios sobre EAS. Para aquellos de ustedes que encontraron interés en las partes relacionadas con EAS, Linaro tiene mucha documentación sobre EAS que puede leer.