Mejorando el Exynos 9810 en el Galaxy S9

Tras nuestra revisión del Galaxy S9, ha habido mucha discusión sobre el rendimiento y la duración de la batería de las variantes Exynos 9810 del Galaxy S9. En la revisión original, se identificaron algunos problemas clave con la plataforma que se se consideraron la más negativa atribución a las malas características del teléfono. En una primera parte después de la revisión hicimos algunos pequeños cambios en el kernel que ya parecían haber beneficiado la duración de la batería en nuestra prueba de navegación web, y un ligero cambio en las características de rendimiento del teléfono para lo positivo.

Centrándose en el rendimiento
Para esta segunda parte nos propusiomos tratar de recuperar el mejor rendimiento posible y coincidir con la variante Snapdragon 845 del Galaxy S9, sin perder de vista la duración de la batería.

Como punto de partida continuamos donde lo dejamos en la parte 1, que fue extremadamente sencillo ya que los únicos cambios fueron la eliminación de todas las frecuencias de refuerzo por encima de 1.8 GHz en los núcleos M3 y la desactivación del controlador en línea de núcleo/hotplugging.

En la revisión original, el problema más evidente identificado en términos de afectación gravemente del rendimiento del teléfono, era la forma en que el dispositivo era extremadamente lento en términos de ampliación de frecuencia, así como la migración de hilos en los núcleos grandes. Los valores originales descritos fueron alrededor de 410 ms para una carga de trabajo continua de estado estacionario para alcanzar realmente la frecuencia máxima de los núcleos grandes. Este fue un gran contraste con los 65 ms de la variante Snapdragon 845. Aparte de todo lo demás, esto es lo que más limitaba el rendimiento interactivo del Exynos 9810, así que, naturalmente, es lo que queremos solucionar en primer lugar.

Planificador del EAS
Como una pequeña historia de fondo, desde la introducción de Big.LITTLE hace varios años, el objetivo principal de ARM ha sido que los proveedores de SoC ejecuten las CPU heterogéneas con un programador inteligente que tenga en cuenta el rendimiento y las características energéticas de la CPU. Este fue un buen objetivo, pero el camino para llegar ha sido, en mi opinión, nada menos que un desastre. El enfoque de ARM era intentar hacer el trabajo en el kernel de Linux o dentro del kernel de grupo de trabajo de Linaro. Desafortunadamente, a lo largo de los años y las demoras, gran parte del bombo que la programación consciente de la energía (EAS) traería terminaba con una confusión cuando se trataba de enviar dispositivos comerciales. Creo que Qualcomm estuvo presente tanto como en 2015 para el Snapdragon 810, y cubrimos ampliamente lo que la compañía estaba tratando de hacer para resolver los problemas relacionados con EAS.

Un componente clave para permitir la programación en CPUs heterogéneas es la capacidad del planificador para conocer realmente la actividad y la carga de las tareas individuales, en lugar de conocer únicamente la utilización general de la CPU. Si conoce la carga de una tarea individual, puede tomar decisiones de programación sobre en qué núcleos de CPU colocarla. Esto se implementó originalmente a través del mecanismo PELT (seguimiento de carga por entidad) en el kernel de Linux y es lo que se usó para las decisiones de migración tanto en HMP como en la programación de EAS.

Otro objetivo a largo plazo de ARM y la comunidad Linux era integrar la lógica de selección de frecuencia de CPU dentro del programador, en lugar de ser un mecanismo separado. Esto se intentó por primera vez en un proyecto llamado schedfreq, y ahora está completamente integrado en un nuevo gobernador llamado schedutil. De nuevo, la escala de tiempo de implementación de la que estamos hablando aquí fue de varios años, mientras que al mismo tiempo vemos que se envían varias generaciones de dispositivos con una gran cantidad de soluciones.

Los chipsets Exynos de S.LSI estaban jugando a lo seguro, y hasta el Exnyos 9810 la compañía simplemente optó por apegarse a un programador HMP con un gobernador de frecuencia de CPU independiente. Los chipsets Huawei Kirin se envían con EAS; sin embargo, aquí incluso con los últimos dispositivos como el P20, la compañía renuncia a los gobernadores de frecuencia de la CPU del planificador y vuelve a un interactivo tradicional (con muy buenos resultados). Mientras tanto, Qualcomm ha avanzado en su implementación personalizada y ha adoptado otro enfoque llamado WALT (seguimiento de carga asistido por ventanas) que es mucho más receptivo a PELT. En Snapdragon 835 y 845, este es el mecanismo central que asegura el mejor rendimiento en términos de programación y selección de frecuencia de CPU.

Mecanismos del planificador: WALT & PELT
A lo largo de los años, parece que ARM notó el lento progreso y ahora parece estar trabajando más de cerca con Google en el desarrollo del kernel común de Android, utilizando modificaciones fuera de árbol (es decir, fuera del kernel oficial de Linux) que benefician el rendimiento y la duración de la batería de dispositivos móviles. Qualcomm también ha sido un gran colaborador ya que WALT ahora está integrado en el kernel común de Android, y hay mucho trabajo por parte de estas partes, así como de otros fabricantes de SoC, para hacer avanzar la plataforma de una manera que beneficie a los dispositivos comerciales mucho más.

La situación de Samsung LSI aquí parece muy desconcertante. El Exynos 9810 es el primer SoC insignia en hacer uso de EAS, y están basando el kernel BSP (paquete de soporte de la Junta) fuera del kernel común de Android. El problema aquí es que en lugar de optar por optimizar el SoC a través de WALT, optaron por recurrir a la utilización de tareas dictadas por PELT. Eso todavía está bien en términos de migraciones centrales, sin embargo, también eligieron usar un controlador de frecuencia de CPU schedutil muy vainilla. Esto significaba que el aumento de frecuencia de las CPU Exynos 9810 podría tener las mismas características que PELT, lo que significa que también traería consigo una de las desventajas existentes de PELT: una aceleración relativamente lenta.

Uno de los mejores recursos sobre el tema en realidad proviene de Qualcomm, ya que habían encabezado el tema hace años. En la presentación anterior en Linaro Connect 2016 en Bangkok, vimos la representación visual del comportamiento de PELT frente a WinLT (que se llamó WALT en ese momento). Las métricas a tener en cuenta aquí en el contexto del Exynos 9810 son el util_avg (que es el comportamiento predeterminado en el Galaxy S9) y el contraste al ravg.demand de WALT y la ejecución real de la tarea. Entonces, de todas las opciones posibles en términos de configuraciones BSP, Samsung parecía haber elegido la peor para el rendimiento. Y creo que esto parece haber sido una elección consciente ya que Samsung había hecho mecanismos adicionales tanto para el programador (eHMP) como schedutil (freqvar) para contrarrestar este comportamiento muy lento causado por PELT.

Lo que se probó por primera vez es quizás la ruta más obvia, y es para habilitar WALT y ver a dónde va eso. Al usar WALT como señal de utilización de la CPU para el Exynos S9, el rendimiento fue excepcionalmente bueno y la vida de la batería muy deteriorada. Eché un vistazo al programador de Snapdragon 845 Galaxy S9, pero aquí parece que Qualcomm difiere significativamente del kernel común de Google en el que se basa Exynos. Como estaba trabajando demasiado en el puerto, eché otro vistazo al núcleo de Pixel 2, que afortunadamente estaba mucho más cerca de Samsung. Transmití todos los parches relevantes que también se aplicaron a los dispositivos Pixel 2, junto con la transferencia de EAS a un estado de enero de la rama 4.9-eas-dev. Esto mejoró el comportamiento de WALT a la vez que mantuvo el rendimiento, sin embargo, la degradación de la vida útil de la batería fue significativa en comparación con la configuración anterior. No quería pasar más tiempo con esto, así que busqué en otras vias.

Al mirar a través de los recursos de ARM, parece que la compañía está consciente de los problemas de rendimiento y está tratando activamente de mejorar el comportamiento de PELT para que coincida más con el de WALT. Un cambio significativo es una nueva señal de utilización llamada util_est (estimación de utilización) que se agrega encima de WALT y está destinada a ser utilizada para la selección de frecuencia de la CPU. Copilicé el parche e inmediatamente vi una mejora significativa en la capacidad de respuesta debido a la mayor utilización del estado de frecuencia de la CPU. Otra forma simple de mejorar PELT fue reducir los tiempos de rampa / decaimiento, que también recibieron recientemente un parche aguas arriba . Copilicé esto también al kernel, y después de probar un ajuste de vida media de 8ms por un momento y juzgando que no era bueno para la duración de la batería, establecí una configuración de 16ms, que es una mejora sobre los 32ms del kernel de stock y ofrece el mejor rendimiento y el mejor compromiso de la batería.

Debido a estos cambios significativos en la forma en que el programador se alimenta de las estadísticas de utilización, obviamente la afinación existente de Samsung ya no era válida. Adapté la mayoría de ellos lo mejor que pude, lo que básicamente implica simplemente deshabilitar la mayoría de ellos ya que ya no los necesitaban. También modifiqué significativamente la capacidad y las tablas de costos de EAS, ya que no creo que la forma en que Samsung llenó la mesa sea correcta o representativa del uso real de energía, lo cual es muy desafortunado. A propósito, este último bit fue una de las razones por las que el rendimiento cambió cuando limité la frecuencia de la CPU en la parte 1, ya que cambió toda la tabla de capacidad y cambió la heurística del programador.

Rendimiento y resultados de la batería
El rendimiento del sistema fue la principal preocupación del Exynos 9810 Galaxy S9. Habiendo abordado los problemas más importantes en términos de programación y escalado DVFS, es hora de comprobar cómo esto afecta nuestros resultados de referencia. Una vez más, me gustaría comentar que las siguientes cifras no son las mejores puntuaciones que el dispositivo logró; pero están en la configuración que, en mi opinión, mejor rendimiento equilibrado y duración de la batería dado el tiempo invertido.

Para recapitular lo que estamos viendo: los puntajes originales del firmware S9 (E9810) muestran el comportamiento no modificado; las modificaciones Custom 1 simplemente limitan el rendimiento a 1794 MHz en los núcleos M3 y desactivan los modos de aumento de reloj más altos. Custom 2 contiene las modificaciones más importantes del kernel que hemos cubierto en la primera página mientras se mantienen los 1794MHz de relojes máximos.

La configuración Custom 3 mantiene todos los mecanismos, pero eleva el reloj a 2314MHz, un reloj que según algunas investigaciones en el código fuente del kernel puede haber sido la frecuencia original máxima diseñada, el SoC y, por cierto, la última frecuencia antes de una mayor disminución en rendimiento/potencia términos de escalado de voltaje.


En la prueba de navegación web 2.0 de PCMark vemos una mejora importante de todas las configuraciones personalizadas. El impulso de rendimiento de la primera variante fue causado por el cambio de escala de capacidad hacia los núcleos grandes y, por lo tanto, se migraron más cargas de trabajo a los M3. Custom 2 y 3 conservaron un rendimiento similar; sin embargo, el aumento de rendimiento aquí sobre la configuración de stock proviene del aumento en el programador y la capacidad de respuesta de DVFS. Aumentar las velocidades de los relojes hasta 2.3GHz no trajo mucha mejoría: mejorar el rendimiento aquí disminuye los retornos y hacer que los núcleos sean más agresivos trae una mayor potencia y la degradación de la batería.



Como mencioné en la parte 1, dije que confiaba en poder recuperar rápidamente algunas de las degradaciones de rendimiento del primer kernel personalizado. Los cambios PELT junto con la sintonización nos llevaron de vuelta por encima del kernel stock en las pruebas de video y escritura. Es interesante ver aquí la diferencia que trae el aumento del reloj de 2,3 GHz: si todo lo demás sigue igual, la prueba de escritura obtiene un gran impulso en el puntaje. Sospecho que esto se debe a que la parte de la prueba PDF es más intensiva en cómputo y solo depende del rendimiento de la CPU.


La prueba de Manipulación de datos no detectó diferencias importantes entre las personalizaciones 1 y 2: esta prueba no pareció verse significativamente influenciada por los cambios en el planificador, y la puntuación solo se amplió lentamente con modificaciones más agresivas y que requieren mucha energía. Elevar el reloj a 2,3 GHz a su vez nos dio un buen aumento lineal, apuntando a más tareas de larga duración y límites de capacidad de la CPU.


El punto de referencia de edición de fotos fue la prueba más afectada por el programador y los cambios de DVFS. Aquí finalmente encontramos la explicación para el mal desempeño de Exynos SoC en esta prueba: la frecuencia simplemente no escala lo suficientemente rápido con las tareas pesadas pero efímeras. Esta prueba se amplió a puntajes de 13000 en los ajustes más agresivos con WALT, pero nuevamente a costos de potencia demasiado grandes para que sea razonable.

Fuente: WALT vs PELT: Redux – SFO17-307

Nuevamente, Qualcomm parece estar al tanto de esto, ya que usan PCMark como una demostración de sus modificaciones personalizadas del planificador. Soy consciente de que esto puede no ser representativo de los usos del mundo real y podría haber demasiado enfoque en PCMark, pero en mi experiencia este no es el caso y sigo pensando que es en general la mejor representación que tenemos en el dispositivo “Snappiness”.

De hecho, ambas configuraciones con las modificaciones del planificador hicieron que el S9 tuviera una capacidad de respuesta significativamente mayor y entre uno de los dispositivos, si no el más receptivo. Sin embargo, hay una gran “pero” consideración para el uso del mundo real: no he ajustado los amplificadores táctiles del teléfono. Estos fueron sintonizados naturalmente para el comportamiento de existencias más lento del SoC. En general, las modificaciones WALT y PELT tienen el objetivo final de evitar por completo la necesidad de dichos mecanismos de refuerzo de entrada y ahorrar energía. Por lo tanto, mi experiencia subjetiva de que el teléfono sea tan rápido podría ser solo algo temporal y para la optimización de la batería podríamos atenuarlo un poco mediante la eliminación de los amplificadores de entrada. Desafortunadamente, aparte de tener un brazo robótico y puntos de referencia especiales, todo esto es casi imposible de probar objetivamente.

Terminamos probando un kernel con boosters de entrada completamente desactivados y el teléfono todavía funciona muy bien.


En términos de puntos de referencia web, comenzamos con SpeedoMeter 2.0. En esta primera prueba, la nueva configuración del programador experimentó un incremento menor del 7%, por lo que, en general, el rendimiento aquí no era un problema de capacidad de respuesta del rendimiento, sino más bien de capacidad de CPU en bruto. Al subir el reloj a 2,3 GHz, el rendimiento vuelve a subir cerca de los niveles de Snapdragon 845.


WebXPRT también fue extremadamente sensible a la configuración del planificador, ya que vemos un aumento del 10% en la configuración personalizada 2. Este fue también uno de los casos de uso donde el nuevo comportamiento PELT en realidad superó a WALT ya que solo pude alcanzar una puntuación de 76 con el primero. De nuevo, el puntaje aquí con la configuración personalizada 2 parece ser el rendimiento más alto razonablemente alcanzable bajo 1794MHz, y cualquier cosa por encima de eso parece ser capacidad de CPU limitada. La configuración de 2,3 GHz llevó el rendimiento a los niveles de Snapdragon 845.

También agregar que los niveles de rendimiento en los benchmarks de la web aquí son los más altos que se pueden lograr para Exynos, y no creo que haya más planificadores o optimizaciones de software. Especialmente porque bloquear los núcleos a su frecuencia máxima no mejora el rendimiento mucho más.

Duración de la batería
El equilibrio entre el rendimiento y la duración de la batería vuelve a ser un aspecto clave y un problema del teléfono y del SoC. He intentado miríadas de configuraciones, pero simplemente no pude superar los resultados de la batería de la primera configuración personalizada. Lamentablemente, la física aquí anula cualquier posible optimización de software, y cualquier aumento de rendimiento significará que estamos haciendo cálculos en estados de mayor rendimiento del SoC, y por lo tanto quemaremos más energía por unidad de trabajo.


La configuración personalizada 2 trajo una mejora en el rendimiento, sin embargo, esto tuvo un costo de vida útil de la batería. Este fue un compromiso razonable y, en mi opinión, el mejor escenario para el Exynos 9810 S9. El aumento de los núcleos a 2,3 GHz llevó al 9810 a la par con el Snapdragon 845 en casi todos los puntos de referencia, pero esto bajó aún más la duración de la batería.

La yuxtaposición entre los resultados de stock de la configuración de S9 frente a la configuración personalizada 3 es interesante: estamos logrando una duración de batería similar en ambos escenarios, un poco menos de 7 horas. Sin embargo, la configuración personalizada 3 brinda un aumento del rendimiento del 25-40% en una variedad de pruebas. Puede que esté superando a un caballo muerto aquí, pero una vez más muestra que el Exynos 9810 podría lograr resultados mucho mejores en función de la dirección en la que uno optó por optimizar, ya sea el rendimiento o la duración de la batería.


No cubrí la duración de la batería de PCMark en la primera parte, pero quería asegurarme de cubrir todas mis bases para esta pieza. Aquí, tanto el Custom 2 como el 3 experimentaron una regresión de la vida útil de la batería en comparación con el comportamiento del stock, pero nuevamente en ambos casos, eso se debe simplemente al mayor rendimiento general. El delta de la frecuencia de reloj incrementada de 2.3GHz es mucho más pequeño aquí que en la prueba web, y eso se debe a que PCMark es mucho más interactivo en términos de cargas de trabajo continuas. Tiene menos tareas realmente pesadas, como cargar páginas web, que utilizan los estados de mayor frecuencia de los M3 durante tiempos relativamente más largos.

Conclusión
Con estas piezas queríamos ver qué es posible con Exynos 9810. Definitivamente aún hay margen de mejora; Todavía estamos seguros de que una configuración WALT correctamente ajustada como en el Snapdragon 845 S9 o el Pixel 2 mejoraría aún más el rendimiento o la duración de la batería del Exynos S9. No quería pasar por ese agujero de conejo para un núcleo personalizado, por ahora los cambios PELT mejorados son tan buenos como razonablemente se consiguen.

Una cosa que descubrimos es la discrepancia de rendimiento entre el M3 y Kryo 385 cuando se trata de puntos de referencia sintéticos versus algunos de los puntos de referencia web. Mientras que 1794 MHz es suficiente para que coincida con los núcleos de CPU basados ​​en A75 del Snapdragon en GeekBench o SPEC, no pude igualar el mayor rendimiento en los puntos de referencia web a menos que elevara los relojes a alrededor de 2.3GHZ. Ahora puedo descartar el software como el principal culpable aquí, y en cambio hay más dedos apuntando a la micro-arquitectura del M3. Esto tiene algunas repercusiones relativamente grandes ya que plantea la pregunta de qué tipo de carga de trabajo es realmente más representativa de los casos de uso de teléfonos inteligentes Android en general.

El gráfico anterior es nuestra mejor estimación de cómo son las curvas de rendimiento/potencia. Estos se basan en tablas de costos del planificador, curvas de voltaje y correlaciones con la potencia medida real en ciertos puntos. La gran pregunta aquí es, ¿cuál es el posicionamiento representativo real entre las dos arquitecturas en términos de rendimiento? Como vimos en la parte 1, el M3 puede ganar en promedio en cargas de trabajo como SPEC en los mismos puntos de rendimiento que el S845. Sin embargo, para alcanzar el mayor rendimiento del 845 en cargas de trabajo web, debemos elevar los relojes, y esto, por supuesto, cambiaría las curvas de eficiencia con un favor mucho mayor hacia los núcleos del brazo. El promedio probablemente sea algo intermedio, y es de esperar que Arm y Samsung tengan una visión más completa en términos de la caracterización de la carga de trabajo.

Lo que es indiscutible es que el M3 va a la zaga en los estados de frecuencia más baja. Aquí, los núcleos de Samsung simplemente dejan de aumentar más en el voltaje después de 1170MHz, mientras que las curvas de potencia de los núcleos de Snapdragon y Arm son mucho más pronunciadas. De nuevo, la diferencia absoluta es discutible en función de las cargas de trabajo, ya sea el 25% o el 100%. Lamentablemente, en este punto estamos hablando de física insuperable y simplemente no hay optimización de software que superará esto.

Al final, el Exynos S9 se vio obstaculizado en dos frentes: uno era simplemente un BSP (paquete de soporte, kernel, drivers, etc.) muy poco optimizado por S.LSI (con la División Móvil posiblemente como un factor), particularmente las aparentemente sin sentido persecusiones de puntajes sintéticos más altos como GeekBench, lo que a su vez resultó contraproducente en cualquier carga de trabajo del mundo real. Qualcomm proporcionó a Samsung un excelente BSP de referencia en el S845 S9, por lo que para S.LSI no poder hacer lo mismo es desafortunado. El otro frente donde el Exynos S9 se vio obstaculizado fue que el M3 parece demasiado grande y tiene mucha energía, y no puede actuar como el caballo de batalla eficiente para las cargas de trabajo generales. Complicando los problemas, esto tiene un costo de vida de la batería. Aquí hay mucho más por hacer para corregir la eficiencia y la discrepancia de rendimiento en relación con los núcleos de ARM.

Fuente: www.anadtech.com

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *