Mejorando el Exynos 9810 Galaxy S9: Parte 2 - Poniéndose al día con el Snapdragon

Después de nuestra revisión del Galaxy S9, se ha discutido mucho sobre el rendimiento y la duración de la batería de las variantes Exynos 9810 del Galaxy S9. En la revisión original, identifiqué algunos problemas clave con la plataforma, por lo que consideré que eran los más negativos debido a las malas características del teléfono. En Una primera pieza tras la revisión. Hice algunos cambios menores en el kernel que ya parecían haber beneficiado la vida útil de la batería en nuestra prueba de navegación web, y cambiando ligeramente las características de rendimiento del teléfono por lo positivo.

En ese artículo anterior noté que hay mucho por hacer para mejorar aún más el rendimiento del teléfono y tratar de optimizar la vida útil de la batería. Especialmente en el lado del rendimiento de las cosas, en mi opinión hubo resultados muy bajos en términos de posibles cambios que beneficiarían la experiencia del usuario.

Centrándose en el rendimiento

Para esta segunda parte, comencé a tratar de recuperar el mejor rendimiento posible y hacer coincidir la variante Snapdragon 845 del Galaxy S9, sin dejar de vigilar la duración de la batería.

Samsung Galaxy S9 (E9810)
Comparación de kernel y registro de cambios
VersiónCambios y notas
Firmware oficialComo enviado- Configuración de stock y comportamiento.
- Solo Core M3 en 2704 MHz
- Dual Core M3 en 2314 MHz
- Quad Core M3 en 1794 MHz
'CPU Limited
Modo'
- Modo de CPU definido por Samsung opcional en Configuración
- CPU limitada a 1469 MHz
- Controlador de memoria a media velocidad.
- Programador conservador
Configuración personalizada 1- Comience con el firmware 'Como enviado'
- Retirar el mecanismo de conexión en caliente.
- Limite el pico de frecuencia M3 a 1794MHz en cualquier carga
Configuración personalizada 2
(Fuente Kernel)
Elevar poca frecuencia de núcleo a 1950MHz
- Elevar la frecuencia mínima del núcleo grande a 962MHz
- Adaptar las tablas de costos EAS basadas en el rendimiento y la potencia medidos.
Fusionar parches del planificador a 4.9-eas-dev (Hasta Jan18)
Backport PELT util_est y lo usa
Cambio de la tasa de decaimiento PELT de Backport a 16ms
- Adaptar / deshabilitar ya no se necesitan los modificadores de programación de Samsung
Pequeñas modificaciones personalizadas para tuning.
Configuración personalizada 3Elevar la frecuencia del núcleo grande a 2314MHz y los ajustes relevantes

Como punto de partida, continuamos con el punto 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 impulso por encima de 1.8GHz en los núcleos de M3 y la desactivación del controlador de conexión en línea / núcleo.

En la revisión original, el problema más evidente que identifiqué en términos de que afectaba gravemente el rendimiento del teléfono era la forma en que el dispositivo era extremadamente lento en términos de escalamiento de frecuencia, así como la migración de subprocesos a los grandes núcleos. Los valores originales que describí estaban alrededor de 410ms para que una carga de trabajo continua en estado estable alcance realmente la frecuencia máxima de los núcleos grandes. Esto fue un gran contraste con los 65ms de la variante Snapdragon 845. Dejando de lado todas las demás cosas, esto es lo que más limitaba el rendimiento interactivo de Exynos 9810, por lo que, naturalmente, es lo que queremos solucionar ante todo.

Historial de programación en torno a EAS

Como un poco de historia, desde la introducción de big.LITTLE hace varios años, el principal objetivo de ARM ha sido que los proveedores de SoC ejecuten las CPU heterogéneas con un programador inteligente que sea consciente de las diversas características de rendimiento y energía de la CPU. Este era un buen objetivo, pero el camino para llegar allí ha sido, en mi opinión, nada menos que un desastre. El enfoque de ARM fue tratar de hacer el trabajo en el kernel de Linux ascendente o dentro del kernel de grupo de trabajo Linaro. Desafortunadamente, a lo largo de los años y muchos retrasos en el bombo que trajo la programación de energía consciente (EAS) terminaron con un fizzle cuando se trata de enviar dispositivos comerciales. Creo que Qualcomm estaba en la pelota aquí, incluso tan pronto como 2015 para el Snapdragon 810, y hemos cubierto ampliamente lo que la compañía estaba tratando de hacer para resolver los problemas relacionados con EAS.

Un componente clave para habilitar la programación a través de CPU heterogéneas es la capacidad del programador para conocer realmente la actividad y la carga de tareas individuales, en lugar de solo conocer la utilización general de la CPU. Si conoce la carga de una tarea individual, puede tomar decisiones sobre la programación de la batería en los núcleos de la CPU para 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 la programación de HMP como de EAS.


Plan de piso Exynos 9810. Credito de imagen TechInsights

Otro objetivo de larga duración de Arm y la comunidad de Linux era integrar la lógica de selección de frecuencia de la CPU en el programador, en lugar de ser un mecanismo independiente. 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 estamos viendo varias generaciones de dispositivos que se envían con una gran variedad de soluciones.

Los conjuntos de chips Exynos de S.LSI estaban a salvo, y hasta el Exnyos 9810, la compañía simplemente decidió atenerse a un programador HMP con un gobernador de frecuencia de CPU interactiva independiente. Los chipsets Huawei Kirin se envían con EAS, sin embargo, incluso con los dispositivos más recientes como el P20, la compañía renuncia a los gobernadores de frecuencia de la CPU del programador y recurre a uno tradicional (con muy buenos resultados). Mientras tanto, Qualcomm ha avanzado su implementación personalizada y ha adoptado otro enfoque llamado WALT (seguimiento de carga asistido por ventana) que responde mucho mejor al PELT. En el 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.

Articulo original

Publicación relacionada

Deje un comentario.

Este sitio usa Akismet para reducir el correo no deseado. Descubra cómo se procesan los datos de sus comentarios.