La capacité est la quantité totale d'une ressource (CPU, GPU, etc.) qu'un appareil possède sur une certaine période de temps. Cette page décrit comment identifier et résoudre les problèmes de courrier indésirable liés à la capacité.
Le gouverneur tarde à réagir
Pour éviter les perturbations, le régulateur de fréquence du processeur doit être capable de répondre rapidement aux charges de travail en rafale. La plupart des applications d'interface utilisateur suivent le même modèle de base :
- L'utilisateur lit l'écran.
- L'utilisateur touche l'écran : appuie sur un bouton, fait défiler, etc.
- L'écran défile, modifie l'activité ou s'anime d'une manière ou d'une autre en réponse à la saisie.
- Le système s'arrête lorsqu'un nouveau contenu est affiché.
- L'utilisateur revient à la lecture de l'écran.
Les appareils Pixel et Nexus implémentent Touch Boost pour modifier le comportement du régulateur de fréquence du processeur (et du planificateur) au toucher. Pour éviter une rampe lente vers une fréquence d'horloge élevée (ce qui pourrait entraîner une perte d'images de l'appareil au toucher), l'augmentation tactile définit généralement une fréquence plancher sur le processeur pour garantir qu'une grande capacité du processeur est disponible au toucher. Un sol dure un certain temps après avoir été touché (généralement environ deux secondes).
Pixel utilise également le groupe de contrôle schedtune fourni par Energy Aware Scheduling (EAS) comme signal d'amplification tactile supplémentaire : les principales applications reçoivent un poids supplémentaire via schedtune pour garantir qu'elles disposent de suffisamment de capacité CPU pour fonctionner rapidement. Les Nexus 5X et 6P ont un écart de performances beaucoup plus important entre les petits et les grands clusters de processeurs (A53 et A57, respectivement) que le Pixel avec le processeur Kryo. Nous avons constaté que le petit cluster de processeur n'était pas toujours adéquat pour un rendu fluide de l'interface utilisateur, en particulier compte tenu des autres sources de gigue sur l'appareil.
En conséquence, sur les Nexus 5X et 6P, Touch Boost modifie le comportement du planificateur pour rendre plus probable le déplacement des applications de premier plan vers les gros cœurs (ceci est conceptuellement similaire au plancher sur la fréquence du processeur). Sans la modification du planificateur pour rendre les applications de premier plan plus susceptibles de migrer vers le gros cluster de processeur, les applications de premier plan peuvent avoir une capacité de processeur insuffisante pour effectuer le rendu jusqu'à ce que le planificateur décide d'équilibrer la charge du thread sur un gros cœur de processeur. En modifiant le comportement du planificateur pendant le boost tactile, il est plus probable qu'un thread d'interface utilisateur s'exécute immédiatement sur un gros cœur et évite les erreurs sans le forcer à toujours s'exécuter sur un gros cœur, ce qui pourrait avoir de graves impacts sur la consommation d'énergie.
Limitation thermique
La limitation thermique se produit lorsque l'appareil doit réduire sa puissance thermique globale, généralement effectuée en réduisant les horloges du CPU, du GPU et de la DRAM. Sans surprise, cela entraîne souvent des erreurs, car le système peut ne plus être en mesure de fournir suffisamment de capacité pour effectuer le rendu dans un délai donné. La seule façon d’éviter la limitation thermique est d’utiliser moins d’énergie. Il n'existe pas beaucoup de façons de procéder, mais sur la base de nos expériences avec les SOC précédents, nous avons quelques recommandations à l'intention des fournisseurs de systèmes.
Tout d’abord, lors de la création d’un nouveau SOC avec des architectures de processeur hétérogènes, assurez-vous que les courbes performances/W des clusters de processeurs se chevauchent. La courbe performance globale/W pour l’ensemble du processeur doit être une ligne continue. Les discontinuités dans la courbe perf/W obligent le planificateur et le régulateur de fréquence à deviner les besoins d'une charge de travail ; pour éviter les parasites, le planificateur et le régulateur de fréquence privilégient l'attribution à la charge de travail de plus de capacité que ce dont elle a besoin. Cela entraîne une consommation excessive d’énergie, ce qui contribue à l’étranglement thermique.
Imaginez un SOC hypothétique avec deux clusters de processeurs :
- Le cluster 1, le petit cluster, peut dépenser entre 100 et 300 mW et obtient un score de 100 à 300 dans un test de débit en fonction des horloges.
- Le cluster 2, le plus gros cluster, peut dépenser entre 1 000 et 1 600 mW et obtient des scores 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 plus lent, plus rapide == plus grande consommation d'énergie.
Si le planificateur estime qu'une charge de travail de l'interface utilisateur nécessiterait l'équivalent d'un score de 310 sur ce test de débit, sa meilleure option pour éviter les perturbations est d'exécuter le gros cluster à la fréquence la plus basse, gaspillant ainsi beaucoup d'énergie. (Cela dépend du comportement du cpuidle et de la course au ralenti ; les SOC avec des courbes perf/W continues sont plus faciles à optimiser.)
Deuxièmement, utilisez des cpusets. Assurez-vous d'avoir activé les cpusets dans votre noyau et dans votre BoardConfig.mk . Vous devez également configurer les affectations réelles des cpuset dans le init.rc spécifique à votre appareil. Certains fournisseurs laissent cette option désactivée dans leurs BSP dans l'espoir de pouvoir utiliser d'autres astuces pour influencer le comportement du planificateur ; nous pensons que cela n'a pas de sens. Les cpusets sont utiles pour garantir que l'équilibrage de charge entre les processeurs est effectué d'une manière qui reflète ce que l'utilisateur fait réellement sur l'appareil.
ActivityManager attribue des applications à différents processeurs en fonction de l'importance relative de ces applications (en haut, au premier plan, en arrière-plan), les applications plus importantes ayant davantage accès aux cœurs du processeur. Cela permet de garantir la qualité de service pour les applications de premier plan et de premier plan.
Les cpusets sont utiles sur les configurations de processeur homogènes, mais vous ne devez pas expédier un périphérique avec une configuration de processeur hétérogène sans les cpusets activés. Le Nexus 6P est un bon modèle pour savoir comment utiliser les processeurs 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 de puissance en garantissant que les threads d'arrière-plan qui ne sont pas critiques en termes de performances ne soient jamais équilibrés en charge sur les gros cœurs de processeur, où ils pourraient dépenser beaucoup plus d'énergie sans aucun avantage perçu par l'utilisateur. Cela peut également aider à éviter l’étranglement thermique. Bien que la limitation thermique soit un problème de capacité, les améliorations de la gigue ont un impact considérable sur les performances de l'interface utilisateur lors de la limitation thermique. Étant donné que le système se rapprochera de sa capacité à restituer 60 images par seconde, il faudra moins de gigue pour provoquer une perte d'image.