Nous faisons partie de l'équipe de la chaîne d'outils Android LLVM. L'une de nos principales priorités est d'améliorer les performances d'Android grâce à des techniques d'optimisation dans l'écosystème LLVM. Nous recherchons constamment des moyens de rendre Android plus rapide, plus fluide et plus efficace. Bien qu'une grande partie de notre travail d'optimisation se déroule dans l'espace utilisateur, le noyau reste le cœur du système. Aujourd'hui, nous sommes heureux de vous expliquer comment nous intégrons l'optimisation automatique basée sur les commentaires (AutoFDO) au noyau Android pour offrir des gains de performances significatifs aux utilisateurs.

Qu'est-ce qu'AutoFDO ?

Lors d'une compilation logicielle standard, le compilateur prend des milliers de petites décisions, par exemple s'il doit intégrer une fonction et quelle branche d'une condition est susceptible d'être prise, en fonction d'indices de code statiques.Bien que ces heuristiques soient utiles, elles ne prédisent pas toujours avec précision l'exécution du code lors de l'utilisation réelle du téléphone.

AutoFDO modifie cela en utilisant des modèles d'exécution réels pour guider le compilateur. Ces modèles représentent les chemins d'exécution d'instructions les plus courants que le code emprunte lors de l'utilisation réelle, capturés en enregistrant l'historique de branchement du processeur. Bien que ces données puissent être collectées à partir d'appareils de la flotte, pour le noyau, nous les synthétisons dans un environnement de laboratoire à l'aide de charges de travail représentatives, comme l'exécution des 100 applications les plus populaires. Nous utilisons un profileur d'échantillonnage pour capturer ces données, en identifiant les parties du code qui sont "chaudes" (fréquemment utilisées) et celles qui sont "froides". Lorsque nous reconstruisons le noyau avec ces profils, le compilateur peut prendre des décisions d'optimisation beaucoup plus intelligentes, adaptées aux charges de travail Android réelles.

Pour comprendre l'impact de cette optimisation, tenez compte des faits clés suivants :

• Sur Android, le noyau représente environ 40% du temps processeur.
• Nous utilisons déjà AutoFDO pour optimiser les exécutables et les bibliothèques natifs dans l'espace utilisateur, ce qui permet d'améliorer le lancement des applications à froid d'environ 4% et de réduire le temps de démarrage de 1 %.

Gains de performances réels

Nous avons constaté des améliorations impressionnantes dans les métriques Android clés en exploitant les profils d'environnements de laboratoire contrôlés. Ces profils ont été collectés à l'aide de l'exploration et du lancement d'applications, et mesurés sur des appareils Pixel avec les noyaux 6.1, 6.6 et 6.12.

Les améliorations les plus notables sont listées ci-dessous. Vous trouverez des informations sur les profils AutoFDO pour ces versions du noyau dans les dépôts de noyau Android respectifs pour les noyaux android16-6.12 et android15-6.6.

Il ne s'agit pas que de chiffres théoriques. Ils se traduisent par une interface plus rapide, un changement d'application plus rapide, une autonomie prolongée et un appareil globalement plus réactif pour l'utilisateur final.

Fonctionnement : le pipeline

Notre stratégie de déploiement implique un pipeline sophistiqué pour garantir la pertinence des profils et la stabilité des performances.

Étape 1 : Collecte des profils

Bien que nous nous appuyions sur notre flotte de test interne pour profiler les binaires de l'espace utilisateur, nous sommes passés à un environnement de laboratoire contrôlé pour l'image générique du noyau (GKI). Le découplage du profilage du cycle de publication de l'appareil permet des mises à jour flexibles et immédiates, indépendamment des versions du noyau déployées. Il est essentiel de noter que les tests confirment que ces données de laboratoire offrent des gains de performances comparables à ceux des flottes réelles.

• Outils et environnement : nous flashons les appareils de test avec la dernière image du noyau et utilisons simpleperf pour capturer les flux d'exécution des instructions. Ce processus repose sur les capacités matérielles pour enregistrer l'historique de branchement, en utilisant spécifiquement  ARM Embedded Trace Extension (ETE) et ARM Trace Buffer Extension (TRBE) sur les appareils Pixel.
• Charges de travail : nous construisons une charge de travail représentative à l'aide des 100 applications les plus populaires de la Compatibility Test Suite des applications Android (C-Suite). Pour capturer les données les plus précises, nous nous concentrons sur les points suivants :
  • Lancement d'applications: optimisation pour les retards les plus visibles pour l'utilisateur
  • Exploration d'applications basée sur l'IA: simulation d'interactions utilisateur contiguës et évolutives
  • Surveillance à l'échelle du système : capture non seulement des activités d'application au premier plan, mais aussi des charges de travail en arrière-plan critiques et des communications interprocessus
• Validation : cette charge de travail synthétisée présente une similitude de 85% avec les modèles d'exécution collectés à partir de notre flotte interne.
• Données ciblées : en répétant suffisamment ces tests, nous capturons des modèles d'exécution haute fidélité qui représentent avec précision l'interaction de l'utilisateur réelle avec les applications les plus populaires. De plus, ce framework extensible nous permet d'intégrer de manière transparente des charges de travail et des benchmarks supplémentaires pour élargir notre couverture.

Étape 2 : Traitement des profils

Nous post-traitons les données de trace brutes pour nous assurer qu'elles sont propres, efficaces et prêtes pour le compilateur.

• Agrégation : nous consolidons les données de plusieurs exécutions de test et appareils dans une vue système unique.
• Conversion : nous convertissons les traces brutes au format de profil AutoFDO, en filtrant les symboles indésirables si nécessaire.
• Découpage des profils : nous découpons les profils pour supprimer les données des fonctions "froides", ce qui leur permet d'utiliser l'optimisation standard. Cela évite les régressions dans le code rarement utilisé et les augmentations inutiles de la taille binaire.

Étape 3 : Test des profils

Avant le déploiement, les profils sont soumis à une vérification rigoureuse pour s'assurer qu'ils offrent des gains de performances cohérents sans risque de stabilité.

• Analyse des profils et des binaires : nous comparons strictement le contenu du nouveau profil (y compris les fonctions à chaud, les nombres d'échantillons et la taille du profil) aux versions précédentes. Nous utilisons également le profil pour créer une nouvelle image du noyau, en analysant les binaires pour nous assurer que les modifications apportées à la section de texte sont conformes aux attentes.
• Vérification des performances : nous exécutons des benchmarks ciblés sur la nouvelle image du noyau. Cela confirme qu'elle maintient les améliorations de performances établies par les références précédentes.

Mises à jour continues

Le code "dérive" naturellement au fil du temps. Un profil statique finirait donc par perdre son efficacité. Pour maintenir des performances optimales, nous exécutons le pipeline en continu afin de générer des mises à jour régulières :

• Actualisation régulière : nous actualisons les profils dans les branches LTS du noyau Android avant chaque version GKI, ce qui garantit que chaque build inclut les dernières données de profil.
• Extension future : nous fournissons actuellement ces mises à jour aux branches android16-6.12 et android15-6.6, et nous étendrons la compatibilité aux versions GKI plus récentes, telles que la prochaine android17-6.18.

Assurer la stabilité

Une question courante concernant l'optimisation guidée par profil est de savoir si elle introduit des risques de stabilité. Étant donné qu'AutoFDO influence principalement les heuristiques du compilateur, telles que l'intégration de fonctions et la disposition du code, plutôt que de modifier la logique du code source, il préserve l'intégrité fonctionnelle du noyau. Cette technologie a déjà fait ses preuves à grande échelle, servant d'optimisation standard pour les bibliothèques de la plate-forme Android, ChromeOS et l'infrastructure de serveur de Google depuis des années.

Pour garantir un comportement cohérent, nous appliquons une stratégie "conservatrice par défaut". Les fonctions non capturées dans nos profils haute fidélité sont optimisées à l'aide de méthodes de compilation standard. Cela garantit que les parties "froides" ou rarement exécutées du noyau se comportent exactement comme dans un build standard, ce qui évite les régressions de performances ou les comportements inattendus dans les cas extrêmes.

Perspectives d'avenir

Nous déployons actuellement AutoFDO dans les branches android16-6.12 et android15-6.6. Au-delà de ce déploiement initial, nous voyons plusieurs pistes prometteuses pour améliorer encore la technologie :

• Portée étendue : nous prévoyons de déployer des profils AutoFDO sur des versions plus récentes du noyau GKI et sur des cibles de compilation supplémentaires au-delà de la compatibilité aarch64 actuelle.
• Optimisation des modules GKI : actuellement, notre optimisation est axée sur le binaire principal du noyau (vmlinux). L'extension d'AutoFDO aux modules GKI pourrait apporter des avantages en termes de performances à une plus grande partie du sous-système du noyau.
• Compatibilité avec les modules de fournisseur : nous souhaitons également prendre en charge AutoFDO pour les modules de fournisseur créés à l'aide du kit de développement de pilotes (DDK). La compatibilité étant déjà disponible dans notre système de compilation (Kleaf) et nos outils de profilage (simpleperf), les fournisseurs peuvent appliquer ces mêmes techniques d'optimisation à leurs pilotes matériels spécifiques.
• Couverture plus large des profils : il est possible de collecter des profils à partir d'un plus large éventail de parcours utilisateur critiques (CUJ) afin de les optimiser.

En intégrant AutoFDO au noyau Android, nous nous assurons que la base même du système d'exploitation est optimisée pour la façon dont vous utilisez votre appareil au quotidien.