La capacidad es la cantidad total de un recurso (CPU, GPU, etc.) que posee un dispositivo durante un período determinado. En esta página, se describe cómo identificar y abordar los problemas de bloqueo relacionados con la capacidad.
El gobernador tarda en reaccionar
Para evitar los bloqueos, el regulador de frecuencia de la CPU debe poder responder con rapidez a las cargas de trabajo con aumentos repentinos de actividad. La mayoría de las apps de IU siguen el mismo patrón básico:
- El usuario está leyendo la pantalla.
- El usuario toca la pantalla: presiona un botón, se desplaza, etcétera.
- La pantalla se desplaza, cambia de actividad o se anima de alguna manera en respuesta a la entrada.
- El sistema entra en estado inactivo a medida que se muestra contenido nuevo.
- El usuario vuelve a leer la pantalla.
Los dispositivos Pixel y Nexus implementan el aumento de la sensibilidad táctil para modificar el comportamiento del regulador de frecuencia (y el programador) de la CPU al tacto. Para evitar una rampa lenta a una frecuencia de reloj alta (que podría hacer que el dispositivo pierda fotogramas al tacto), el aumento de la sensibilidad táctil suele establecer un límite inferior de frecuencia en la CPU para garantizar que haya suficiente capacidad de la CPU disponible al tacto. Un piso dura un tiempo después del toque (por lo general, alrededor de dos segundos).
Pixel también usa el cgroup schedtune que proporciona la programación consciente de la energía (EAS) como un indicador adicional de aumento de la sensibilidad táctil: las apps principales obtienen un peso adicional a través de schedtune para garantizar que tengan suficiente capacidad de CPU para ejecutarse rápidamente. Los Nexus 5X y 6P tienen una brecha de rendimiento mucho mayor entre los clústeres de CPU pequeños y grandes (A53 y A57, respectivamente) que el Pixel con la CPU Kryo. Descubrimos que el pequeño clúster de CPU no siempre era adecuado para una renderización fluida de la IU, en especial, teniendo en cuenta otras fuentes de jitter en el dispositivo.
En consecuencia, en el Nexus 5X y el 6P, el aumento de la sensibilidad táctil modifica el comportamiento del programador para que sea más probable que las apps en primer plano se trasladen a los núcleos grandes (esto es conceptualmente similar al límite inferior de la frecuencia de la CPU). Sin el cambio del programador para que las apps en primer plano tengan más probabilidades de pasar al clúster de CPU grande, es posible que las apps en primer plano no tengan suficiente capacidad de CPU para renderizar hasta que el programador decida balancear la carga del subproceso en un núcleo de CPU grande. Si cambias el comportamiento del programador durante el aumento de la sensibilidad táctil, es más probable que un subproceso de IU se ejecute de inmediato en un núcleo grande y evite la inestabilidad, sin forzarlo a ejecutarse siempre en un núcleo grande, lo que podría tener un impacto grave en el consumo de energía.
Limitación térmica
La limitación térmica se produce cuando el dispositivo debe reducir su rendimiento térmico general, lo que suele hacerse reduciendo los relojes de la CPU, la GPU y la DRAM. No es de extrañar que, a menudo, esto genere interrupciones, ya que es posible que el sistema ya no pueda proporcionar suficiente capacidad para renderizar en un período determinado. La única manera de evitar el estrangulamiento térmico es usar menos energía. No hay muchas formas de hacerlo, pero, en función de nuestras experiencias con SOC anteriores, tenemos algunas recomendaciones para los proveedores de sistemas.
Primero, cuando crees un nuevo SoC con arquitecturas de CPU heterogéneas, asegúrate 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 lo que necesita una carga de trabajo. Para evitar el bloqueo, el programador y el regulador de frecuencia se equivocan y le dan a la carga de trabajo más capacidad de la que requiere. Esto genera un consumo excesivo de energía, lo que contribuye al estrangulamiento térmico.
Imagina un SOC hipotético con dos clústeres de CPU:
- El clúster 1, el pequeño, puede consumir entre 100 y 300 mW y obtener puntuaciones de 100 a 300 en una comparativa de rendimiento según los relojes.
- El clúster 2, el clúster grande, puede consumir entre 1000 y 1600 mW y obtener puntuaciones de entre 800 y 1200 en la misma comparativa de rendimiento según los relojes.
En esta comparativa, una puntuación más alta es más rápida. Si bien no es más deseable que ser más lento, más rápido significa un mayor consumo de energía.
Si el programador cree que una carga de trabajo de la IU requeriría el equivalente a una puntuación de 310 en esa comparativa de rendimiento, la mejor opción para evitar la inestabilidad es ejecutar el clúster grande a la frecuencia más baja, lo que desperdicia mucha energía. (Esto depende del comportamiento de cpuidle y de la carrera para inactividad; los SoC con curvas de rendimiento/W continuas son más fáciles de optimizar).
En segundo lugar, usa cpusets. Asegúrate de haber habilitado cpusets en el kernel y en tu BoardConfig.mk. También debes configurar las asignaciones de cpuset reales en tu init.rc específico del dispositivo. Algunos proveedores dejan esta opción inhabilitada en sus BSP con la esperanza de poder usar otras sugerencias para influir en el comportamiento del programador. Creemos que esto no tiene sentido. Los cpusets son útiles para garantizar que el balanceo de cargas entre las CPUs se realice de una manera que refleje lo que el usuario está haciendo en el dispositivo.
ActivityManager asigna apps a diferentes conjuntos de CPU según la importancia relativa de esas apps (superior, en primer plano, en segundo plano), y las apps más importantes obtienen más acceso a los núcleos de CPU. Esto ayuda a garantizar la calidad de servicio de las apps en primer plano y principales.
Los cpusets son útiles en configuraciones de CPU homogéneas, pero no debes enviar un dispositivo con una configuración de CPU heterogénea sin cpusets habilitados. Nexus 6P es un buen modelo para usar cpusets en configuraciones de CPU heterogéneas. Úsalo como base para la configuración de tu propio dispositivo.
Los cpusets también ofrecen ventajas de energía, ya que garantizan que los subprocesos en segundo plano que no son esenciales para el rendimiento nunca se balanceen de carga en núcleos de CPU grandes, donde podrían consumir mucha más energía sin ningún beneficio percibido por el usuario. Esto también puede ayudar a evitar la limitación térmica. Si bien el regulador térmico es un problema de capacidad, las mejoras en el jitter tienen un impacto desproporcionado en el rendimiento de la IU cuando se aplica el regulador térmico. Debido a que el sistema se ejecutará más cerca de su capacidad para renderizar 60 FPS, se necesita menos jitter para provocar la pérdida de un fotograma.