La capacidad es la cantidad total de algún recurso (CPU, GPU, etc.) que posee un dispositivo durante un período de tiempo determinado. Esta página describe cómo identificar y abordar problemas de bloqueo relacionados con la capacidad.
Gobernador tarda en reaccionar
Para evitar bloqueos, el regulador de frecuencia de la CPU debe poder responder rápidamente a cargas de trabajo en ráfagas. La mayoría de las aplicaciones de UI siguen el mismo patrón básico:
- El usuario está leyendo la pantalla.
- El usuario toca la pantalla: toca un botón, se desplaza, etc.
- La pantalla se desplaza, cambia de actividad o se anima de alguna manera en respuesta a la entrada.
- El sistema se detiene cuando se muestra contenido nuevo.
- El usuario vuelve a leer la pantalla.
Los dispositivos Pixel y Nexus implementan Touch Boost para modificar el comportamiento del regulador de frecuencia de la CPU (y del programador) al tacto. Para evitar una rampa lenta hacia una frecuencia de reloj alta (que podría hacer que el dispositivo pierda fotogramas al tocarlo), el impulso táctil generalmente establece una frecuencia mínima en la CPU para garantizar que haya suficiente capacidad de CPU disponible al tacto. Un suelo dura cierto tiempo después del tacto (normalmente unos dos segundos).
Pixel también utiliza el cgroup schedtune proporcionado por Energy Aware Scheduling (EAS) como una señal de impulso táctil adicional: las principales aplicaciones obtienen peso adicional a través de schedtune para garantizar que obtengan suficiente capacidad de CPU para ejecutarse rápidamente. El Nexus 5X y 6P tienen una diferencia de rendimiento mucho mayor entre los grupos de CPU pequeños y grandes (A53 y A57, respectivamente) que el Pixel con CPU Kryo. Descubrimos que el pequeño grupo de CPU no siempre era adecuado para una representación fluida de la interfaz de usuario, especialmente dadas otras fuentes de fluctuación en el dispositivo.
En consecuencia, en Nexus 5X y 6P, el impulso táctil modifica el comportamiento del programador para que sea más probable que las aplicaciones en primer plano se muevan a los núcleos grandes (esto es conceptualmente similar al piso en la frecuencia de la CPU). Sin el cambio del programador para hacer que las aplicaciones en primer plano tengan más probabilidades de pasar al clúster de CPU grande, las aplicaciones en primer plano pueden tener capacidad de CPU insuficiente para renderizar hasta que el programador decida equilibrar la carga del subproceso en un núcleo de CPU grande. Al cambiar el comportamiento del programador durante el impulso táctil, es más probable que un subproceso de la interfaz de usuario se ejecute inmediatamente en un núcleo grande y evite bloqueos sin forzarlo a ejecutarse siempre en un núcleo grande, lo que podría tener graves impactos en el consumo de energía.
Estrangulamiento térmico
La limitación térmica se produce cuando el dispositivo debe reducir su salida térmica general, lo que generalmente se realiza reduciendo los relojes de CPU, GPU y DRAM. Como era de esperar, esto a menudo resulta en bloqueos, ya que es posible que el sistema ya no pueda proporcionar suficiente capacidad para renderizar dentro de un intervalo de tiempo determinado. La única forma de evitar la estrangulación térmica es utilizar menos energía. No hay muchas maneras de hacer esto, pero según nuestras experiencias con SOC anteriores, tenemos algunas recomendaciones para los proveedores de sistemas.
En primer lugar, al construir un nuevo SOC con arquitecturas de CPU heterogéneas, asegúrese de que las curvas de rendimiento/W de los clústeres de CPU se superpongan. La curva rendimiento general/W para todo el procesador debe ser una línea continua. Las discontinuidades en la curva rendimiento/W obligan al planificador y al regulador de frecuencia a adivinar qué necesita una carga de trabajo; Para evitar bloqueos, el programador y el regulador de frecuencia se equivocan al darle a la carga de trabajo más capacidad de la que necesita. Esto resulta en un gasto excesivo de energía, lo que contribuye al estrangulamiento térmico.
Imagine un SOC hipotético con dos grupos de CPU:
- El grupo 1, el pequeño grupo, puede consumir entre 100 y 300 mW y obtiene una puntuación de 100 a 300 en un punto de referencia de rendimiento dependiendo de los relojes.
- El grupo 2, el grupo grande, puede consumir entre 1000 y 1600 mW y obtener puntuaciones entre 800 y 1200 en el mismo punto de referencia de rendimiento dependiendo de los relojes.
En este punto de referencia, una puntuación más alta es más rápida. Si bien no es más deseable que más lento, más rápido == mayor consumo de energía.
Si el programador cree que una carga de trabajo de UI requeriría el equivalente a una puntuación de 310 en ese punto de referencia de rendimiento, su mejor opción para evitar interferencias es ejecutar el clúster grande a la frecuencia más baja, desperdiciando una cantidad significativa de energía. (Esto depende del comportamiento de la CPU y de la carrera hacia la inactividad; los SOC con curvas continuas de rendimiento/W son más fáciles de optimizar).
En segundo lugar, utilice cpusets. Asegúrese de haber habilitado cpusets en su kernel y en su BoardConfig.mk . También debe configurar las asignaciones de cpuset reales en init.rc específico de su dispositivo. Algunos proveedores dejan esto deshabilitado en sus BSP con la esperanza de poder utilizar otras sugerencias para influir en el comportamiento del programador; Creemos que esto no tiene sentido. Los cpusets son útiles para garantizar que el equilibrio de carga entre CPU se realice de manera que refleje lo que el usuario está haciendo realmente en el dispositivo.
ActivityManager asigna aplicaciones a diferentes conjuntos de CPU según la importancia relativa de esas aplicaciones (arriba, primer plano, fondo), y las aplicaciones más importantes obtienen más acceso a los núcleos de la CPU. Esto ayuda a garantizar la calidad del servicio para las aplicaciones principales y en primer plano.
Los cpusets son útiles en configuraciones de CPU homogéneas, pero no debe enviar un dispositivo con una configuración de CPU heterogénea sin los cpusets habilitados. Nexus 6P es un buen modelo sobre cómo utilizar cpusets en configuraciones de CPU heterogéneas; Úselo como base para la configuración de su propio dispositivo.
Los cpusets también ofrecen ventajas energéticas al garantizar que los subprocesos en segundo plano que no son críticos para el rendimiento nunca obtengan un equilibrio de carga en núcleos de CPU grandes, donde podrían gastar significativamente más energía sin ningún beneficio percibido por el usuario. Esto también puede ayudar a evitar la estrangulación térmica. Si bien la limitación térmica es un problema de capacidad, las mejoras en la fluctuación tienen un impacto enorme en el rendimiento de la interfaz de usuario cuando se aplica la limitación térmica. Debido a que el sistema funcionará más cerca de su capacidad para renderizar 60 FPS, se necesita menos fluctuación para provocar una pérdida de fotograma.