La capacité correspond à la quantité totale d'une ressource (CPU, GPU, etc.) qu'un appareil possède sur une période donnée. Cette page explique comment identifier et résoudre les problèmes de à-coups liés à la capacité.
Le gouverneur réagit lentement
Pour éviter les à-coups, le gouverneur de fréquence du processeur doit pouvoir répondre rapidement aux charges de travail par rafales. La plupart des applications d'UI suivent le même schéma de base:
- L'utilisateur lit l'écran.
- L'utilisateur appuie sur l'écran: il appuie sur un bouton, fait défiler l'écran, etc.
- L'écran défile, change d'activité ou s'anime d'une manière ou d'une autre en réponse à une entrée.
- Le système passe en mode veille lorsque de nouveaux contenus sont affichés.
- L'utilisateur revient à la lecture de l'écran.
Les appareils Pixel et Nexus implémentent l'amélioration tactile pour modifier le comportement du gouverneur de fréquence du processeur (et du planificateur) lors d'une pression. Pour éviter une montée lente vers une fréquence d'horloge élevée (ce qui pourrait entraîner la perte de frames sur l'écran tactile), l'optimisation tactile définit généralement un plancher de fréquence sur le processeur pour s'assurer que la capacité du processeur est suffisante pour l'écran tactile. Un étage persiste pendant un certain temps après avoir été touché (généralement environ deux secondes).
Le Pixel utilise également le cgroup schedtune fourni par la planification consciente de l'énergie (EAS) comme signal de boost tactile supplémentaire: les applications principales reçoivent un poids supplémentaire via schedtune pour s'assurer qu'elles disposent d'une capacité de processeur suffisante pour s'exécuter rapidement. Le Nexus 5X et le Nexus 6P présentent un écart de performances beaucoup plus important entre les groupes de processeurs petits et grands (A53 et A57, respectivement) que le Pixel avec le processeur Kryo. Nous avons constaté que le petit cluster de processeurs n'était pas toujours adapté pour un rendu de l'interface utilisateur fluide, en particulier compte tenu d'autres sources de jitter sur l'appareil.
Par conséquent, sur les Nexus 5X et 6P, le boost tactile modifie le comportement du planificateur pour que les applications de premier plan soient plus susceptibles d'être transférées vers les cœurs principaux (ce qui est conceptuellement semblable au plancher de la fréquence du processeur). Sans le changement de planificateur pour que les applications au premier plan soient plus susceptibles de passer au grand cluster de processeurs, la capacité de processeur des applications au premier plan peut être insuffisante pour l'affichage jusqu'à ce que le planificateur décide d'équilibrer la charge du thread sur un grand cœur de processeur. En modifiant le comportement du planificateur lors du boost tactile, il est plus probable qu'un thread d'UI s'exécute immédiatement sur un grand cœur et évite les à-coups, sans le forcer à s'exécuter toujours sur un grand cœur, ce qui pourrait avoir des conséquences graves sur la consommation d'énergie.
Limite thermique
La limitation thermique se produit lorsque l'appareil doit réduire sa production thermique globale, généralement en réduisant les horloges du processeur, du GPU et de la DRAM. Sans surprise, cela entraîne souvent des à-coups, car le système ne peut plus fournir suffisamment de capacité pour l'affichage dans un intervalle de temps donné. Le seul moyen d'éviter le throttling thermique est de consommer moins d'énergie. Il n'existe pas beaucoup de façons de procéder, mais d'après nos expériences passées avec les SOC, nous avons quelques recommandations à formuler pour les fournisseurs de systèmes.
Tout d'abord, lorsque vous créez un SOC avec des architectures de processeur hétérogènes, assurez-vous que les courbes de performances/W des clusters de processeurs se chevauchent. La courbe des performances/W globales pour l'ensemble du processeur doit être une ligne continue. Les discontinuités de la courbe des performances/W obligent le planificateur et le gouverneur de fréquence à deviner les besoins d'une charge de travail. Pour éviter les à-coups, le planificateur et le gouverneur de fréquence donnent à la charge de travail plus de capacité qu'elle n'en a besoin. Cela entraîne une consommation d'énergie excessive, ce qui contribue à la limitation thermique.
Imaginons un SOC hypothétique avec deux clusters de processeurs:
- Le cluster 1, le petit cluster, peut dépenser entre 100 et 300 mW et obtenir un score de 100 à 300 dans un benchmark de débit, en fonction des horloges.
- Le cluster 2, le grand cluster, peut consommer entre 1 000 et 1 600 mW et obtenir un score compris entre 800 et 1 200 dans le même benchmark de débit, en fonction des horloges.
Dans ce benchmark, un score plus élevé est plus rapide. Bien que ce ne soit pas plus souhaitable que de ralentir, plus vite = plus de consommation d'énergie.
Si l'ordonnanceur estime qu'une charge de travail d'interface utilisateur nécessite l'équivalent d'un score de 310 sur ce benchmark de débit, la meilleure option pour éviter les à-coups consiste à exécuter le grand cluster à la fréquence la plus basse, ce qui gaspille une quantité d'énergie importante. (Cela dépend du comportement cpuidle et de la course à l'inactivité. Les SOC avec des courbes de performances/W continues sont plus faciles à optimiser.)
Deuxièmement, utilisez des cpusets. Assurez-vous d'avoir activé les cpusets dans votre kernel et dans votre BoardConfig.mk. Vous devez également configurer les attributions de cpuset réelles dans votre init.rc spécifique à l'appareil. Certains fournisseurs laissent cette option désactivée dans leurs BSP dans l'espoir de pouvoir utiliser d'autres indices pour influencer le comportement de l'ordonnanceur. Nous pensons que cela n'a pas de sens. Les cpusets sont utiles pour s'assurer que l'équilibrage de la charge entre les processeurs est effectué de manière à refléter ce que l'utilisateur fait réellement sur l'appareil.
ActivityManager attribue des applications à différents cpusets en fonction de l'importance relative de ces applications (haut, premier plan, arrière-plan), les applications les plus importantes ayant un accès plus important aux cœurs de processeur. Cela permet de garantir la qualité de service pour les applications de premier plan et les applications principales.
Les cpusets sont utiles pour les configurations de processeur homogènes, mais vous ne devez pas expédier un appareil avec une configuration de processeur hétérogène sans cpusets activés. Le Nexus 6P est un bon modèle pour savoir comment utiliser des cpusets sur des configurations de processeur hétérogènes. Utilisez-le comme base pour la configuration de votre propre appareil.
Les cpusets offrent également des avantages en termes d'alimentation en veillant à ce que les threads en arrière-plan qui ne sont pas critiques en termes de performances ne soient jamais équilibrés en charge sur les grands cœurs de processeur, où ils pourraient consommer beaucoup plus d'énergie sans aucun avantage perçu par l'utilisateur. Cela peut également aider à éviter le throttling thermique. Bien que la limitation thermique soit un problème de capacité, les améliorations du jitter ont un impact disproportionné sur les performances de l'UI en cas de limitation thermique. Étant donné que le système s'exécutera plus près de sa capacité de rendu à 60 FPS, il faudra moins de jitter pour provoquer une perte de frame.