La capacidad es la cantidad total de algún recurso (CPU, GPU, etc.) que posee un dispositivo durante un período de tiempo. Esta página describe cómo identificar y abordar los 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 las cargas de trabajo en ráfagas. La mayoría de las aplicaciones de interfaz de usuario 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 la actividad o se anima de alguna manera en respuesta a la entrada.
- El sistema se desactiva 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 gobernador de frecuencia de la CPU (y el programador) al tocar. Para evitar una rampa lenta a una frecuencia de reloj alta (lo que podría hacer que el dispositivo pierda fotogramas al tocarlo), Touch Boost generalmente establece un piso de frecuencia en la CPU para garantizar que haya suficiente capacidad de CPU disponible al tocar. Un piso dura una cierta cantidad de tiempo después del toque (generalmente alrededor de dos segundos).
Pixel también utiliza el cgroup schedtune proporcionado por Energy Aware Scheduling (EAS) como una señal de refuerzo táctil adicional: las aplicaciones principales obtienen peso adicional a través de schedtune para garantizar que obtengan suficiente capacidad de CPU para ejecutarse rápidamente. El Nexus 5X y el 6P tienen una brecha de rendimiento mucho mayor entre los grupos de CPU pequeños y grandes (A53 y A57, respectivamente) que el Pixel con el 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 inestabilidad en el dispositivo.
En consecuencia, en el Nexus 5X y 6P, Touch Boost 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 mínimo en la frecuencia de la CPU). Sin el cambio del programador para hacer que las aplicaciones en primer plano tengan más probabilidades de moverse al clúster de CPU grande, las aplicaciones en primer plano pueden tener una capacidad de CPU insuficiente para procesar hasta que el programador decida equilibrar la carga del subproceso a un núcleo de CPU grande. Al cambiar el comportamiento del programador durante el refuerzo 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 obligarlo a ejecutarse siempre en un núcleo grande, lo que podría tener un impacto severo en el consumo de energía.
Estrangulación térmica
El estrangulamiento térmico ocurre cuando el dispositivo debe reducir su producción térmica general, generalmente mediante la reducción de los relojes de CPU, GPU y DRAM. Como era de esperar, esto a menudo resulta en bloqueo, 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 el estrangulamiento térmico es usar menos energía. No hay muchas formas de hacer esto, pero según nuestras experiencias con los SOC anteriores, tenemos algunas recomendaciones para los proveedores de sistemas.
En primer lugar, al crear 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 de rendimiento general/W para todo el procesador debe ser una línea continua. Las discontinuidades en la curva de rendimiento/W obligan al programador 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 dar a la carga de trabajo más capacidad de la que requiere. Esto da como resultado gastar demasiada energía, lo que contribuye al estrangulamiento térmico.
Imagine un SOC hipotético con dos clústeres de CPU:
- El clúster 1, el pequeño clúster, puede gastar entre 100 y 300 mW y obtiene una puntuación de 100 a 300 en un punto de referencia de rendimiento según los relojes.
- El clúster 2, el clúster grande, puede gastar entre 1000 y 1600 mW y obtener puntuaciones de entre 800 y 1200 en el mismo punto de referencia de rendimiento según 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 la interfaz de usuario requeriría el equivalente a una puntuación de 310 en ese punto de referencia de rendimiento, su mejor opción para evitar bloqueos es ejecutar el clúster grande a la frecuencia más baja, desperdiciando una cantidad significativa de energía. (Esto depende del comportamiento de inactividad de la CPU y de la carrera a inactividad; los SOC con curvas continuas de rendimiento/W son más fáciles de optimizar).
En segundo lugar, use cpusets. Asegúrese de haber habilitado cpusets en su núcleo y en su BoardConfig.mk . También debe configurar las asignaciones reales de cpuset en su init.rc específico del dispositivo. Algunos proveedores dejan esto deshabilitado en sus BSP con la esperanza de que puedan usar otras sugerencias para influir en el comportamiento del programador; sentimos que esto no tiene sentido. cpusets son útiles para garantizar que el equilibrio de carga entre las CPU se realice de una manera que refleje lo que el usuario está haciendo realmente en el dispositivo.
ActivityManager asigna aplicaciones a diferentes conjuntos de CPU en función de la importancia relativa de esas aplicaciones (superior, en primer plano, en segundo plano), 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 de primer plano.
cpusets son útiles en configuraciones de CPU homogéneas, pero no debe enviar un dispositivo con una configuración de CPU heterogénea sin cpusets habilitados. Nexus 6P es un buen modelo sobre cómo usar conjuntos de CPU en configuraciones de CPU heterogéneas; utilícelo como base para la configuración de su propio dispositivo.
Los cpusets también ofrecen ventajas de energía al garantizar que los subprocesos en segundo plano que no son críticos para el rendimiento nunca se equilibren en la carga de los grandes núcleos de CPU, donde podrían gastar mucha más energía sin ningún beneficio percibido por el usuario. Esto también puede ayudar a evitar el estrangulamiento térmico. Si bien la limitación térmica es un problema de capacidad, las mejoras en la inestabilidad 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 se ejecutará más cerca de su capacidad de renderizar 60FPS, se necesita menos fluctuación para provocar una caída de cuadro.