Ajout de la taille de page de 16 KB à Android

• La page est l’unité minimale utilisée par le système d’exploitation pour gérer la mémoire
• La plupart des CPU prennent en charge une taille de page de 4 KB, et Android OS ainsi que les applications sont optimisés pour cette taille de page de 4 KB
• Les CPU ARM prennent en charge une taille de page de 16 KB, et lorsque Android utilise cette taille, les performances s’améliorent de 5 à 10 % tandis que l’utilisation mémoire augmente d’environ 9 %
• Afin d’améliorer les performances globales du système d’exploitation et de permettre aux fabricants d’appareils de choisir ce compromis, Android 15 peut fonctionner avec une taille de page de 4 KB ou de 16 KB
• Les premiers systèmes Android prenant en charge une taille de page de 16 KB seront proposés comme option développeur sur certains appareils

Détails techniques sur la taille de page de 16 KB

• La plupart des CPU disposent d’un matériel dédié appelé Memory Management Unit (MMU) qui convertit les adresses utilisées par les programmes en emplacements physiques en mémoire
• Cette conversion s’effectue selon l’unité de la taille de page
  • Chaque fois qu’un programme a besoin de plus de mémoire, le système d’exploitation doit intervenir pour remplir une entrée de « table des pages » et attribuer ce bloc mémoire au processus
• Si la taille de page est 4 fois plus grande, le travail de gestion est réduit d’un facteur 4.
  • Le système peut donc consacrer davantage de temps à l’affichage fluide des vidéos, au bon fonctionnement des jeux et à l’exécution fluide des applications, et moins de temps aux tâches administratives de bas niveau du système d’exploitation
• La taille de page n’est pas une Application Binary Interface (ABI)
• Autrement dit, si l’application est modifiée pour être indépendante de la taille de page, le même binaire applicatif peut fonctionner sur des appareils 4 KB comme 16 KB
• Dans Android 15, Android a été refactorisé depuis la base afin de pouvoir fonctionner avec différentes tailles de page et d’être indépendant de cette contrainte

Principales modifications de l’OS

• Appareils basés sur Android 15 :
  • La macro PAGE_SIZE à la compilation est remplacée par getpagesize(2) à l’exécution
  • Tous les binaires de l’OS sont alignés sur 16 KB (les applications/bibliothèques tierces peuvent ne pas être alignées sur 16 KB)
  • Tous les binaires de l’OS sont construits avec un segment chargeable distinct afin de pouvoir lire toutes les zones mémoire mappées dans le processus, ce dont certaines applications dépendent
  • Plusieurs composants de l’OS ont été réécrits pour ne pas supposer une taille de page donnée et pour être optimisés pour des tailles de page plus grandes

Système de fichiers

• Pour de bonnes performances, la taille des blocs du système de fichiers doit correspondre à la taille de page. Les systèmes de fichiers EROFS et F2FS, ainsi que la couche de stockage UFS, sont compatibles 16 KB
• Sur les systèmes 4 KB, la taille des exécutables ELF augmente à cause du padding ajouté pour l’alignement 16 KB, mais plusieurs optimisations permettent d’éviter ce coût
• Le système de fichiers sparse en lecture seule empêche que les pages de zéros générées pour le padding additionnel requis par l’alignement 16 KB soient écrites sur disque
• Les systèmes de fichiers en lecture/écriture traitent les pages de zéros au cas par cas

Gestion de la mémoire

• Le page cache Linux a été modifié pour ne pas précharger ces espaces de padding supplémentaires, ce qui évite des chargements mémoire inutiles
• Ces pages correspondent à du padding vide, que le programme ne lit jamais. C’est simplement un espace situé entre les parties utilisables du programme à des fins d’alignement

Noyau Linux

• Le noyau Linux est étroitement lié à une taille de page spécifique ; il faut donc choisir la taille de page à utiliser lors de la compilation du noyau, tandis que le reste du système d’exploitation reste identique

Applications Android

• Toute application comportant du code natif ou des dépendances doit être recompilée pour être compatible avec les appareils à taille de page de 16 KB
• Comme la plupart des applications Android et du code natif dans les SDK ont été construits en supposant une taille de page de 4 KB, il faut les réaligner sur 16 KB pour que les binaires soient compatibles à la fois avec les appareils 4 KB et 16 KB
• Pour la plupart des applications et des SDK, il s’agit d’un processus en 2 étapes :
  1. Recompiler le code natif avec un alignement 16 KB
  2. Tester sur appareil/émulateur 16 KB et corriger les éventuelles hypothèses codées en dur sur la taille de page

Développer pour des appareils 16 KB

• Les appareils Android actuellement commercialisés ne prennent pas en charge une taille de page de 16 KB
  • Pour résoudre ce problème, des actions sont en cours avec des partenaires afin d’activer des options développeur sur des appareils existants
• Une prise en charge de la taille de page de 16 KB sera proposée via une option développeur
• Une cible d’émulateur 16 KB est disponible dans Android Studio

Option développeur 16 KB

• Dans Android 15, une option développeur permet de basculer entre les tailles de page de 16 KB et de 4 KB
• Disponible sur Pixel 8 et Pixel 8 Pro, avec une prise en charge prévue sur d’autres appareils
• Pour utiliser l’option développeur, il faut réinitialiser l’appareil et déverrouiller le bootloader

16 KB sur un desktop x86_64

• Il est possible d’émuler une taille de page de 16 KB dans l’émulateur x86_64
• Il est possible de télécharger et d’exécuter l’émulateur de pages 16 KB depuis le SDK Manager d’Android Studio

Avenir

• Android 15 et AOSP prennent en charge les pages de 16 KB, avec une implémentation possible via l’option développeur
• Il est attendu que les développeurs d’applications et de SDK utilisent cette option pour préparer des appareils Android plus performants et plus efficaces

Avis de GN⁺

• Le passage à une taille de page de 16 KB constitue une évolution importante pour améliorer les performances et l’efficacité des appareils Android
• L’utilisation d’une taille de page plus grande peut réduire la surcharge liée à la gestion mémoire et améliorer les performances globales du système
• Cependant, ce changement peut aussi entraîner des problèmes de compatibilité, en particulier pour les applications et SDK qui dépendent du code natif ; les développeurs doivent donc mettre à jour leurs logiciels en tenant compte de la taille de page de 16 KB
• Google fournit aux développeurs des outils pour tester et préparer cette transition grâce à l’option développeur 16 KB et à la prise en charge dans l’émulateur
• Les pages de 16 KB ne s’appliquent actuellement qu’aux appareils Android basés sur ARM, mais elles pourraient à l’avenir être étendues à d’autres plateformes matérielles
• En plus d’adapter leurs applications et SDK à la taille de page de 16 KB, les développeurs doivent également prendre en compte l’impact d’une taille de page plus grande sur l’utilisation mémoire et effectuer des optimisations si nécessaire
• La transition vers les pages de 16 KB est un effort important qui nécessite une collaboration à l’échelle de l’écosystème Android, mais elle finira par offrir de meilleures performances et une meilleure efficacité aux utilisateurs

[GN⁺]

Commentaires sur Hacker News

• Un travail a récemment commencé dans le noyau Debian pour compiler le noyau ARM64 avec une taille de page de 16 KiB

  • L’ajout d’une taille de page de 64 KiB est aussi en discussion
  • Le DART IOMMU de l’Apple M1 exige une taille de page minimale de 16 KiB, ce qui devrait améliorer l’efficacité

• Les premiers systèmes Android avec prise en charge du 16 KB devraient être proposés sur certains appareils via les options développeur

  • Il sera possible de tester et de corriger via les options développeur
  • Les binaires d’application indépendants de la taille de page pourront s’exécuter à la fois sur des appareils 4 KB et 16 KB

• Je me demande dans quels cas une application n’est pas indépendante de la taille de page

  • J’aimerais savoir dans quelles situations ce problème survient

• Utiliser 16 KB par défaut sans prendre en charge simultanément les processus 4 KB et 16 KB pose problème

  • Les anciens binaires risquent de casser et il y a des craintes d’une baisse des performances de l’émulateur
  • Il faut un noyau qui prenne aussi en charge les pages de 4 KB
  • Il serait logique que la conception du CPU permette de mapper des entrées de table de pages de 16 KB par unités de 4 KB

• iOS utilise des pages de 16 KB depuis la transition vers le 64 bits

  • Les Mac ARM ont hérité de cette conception

• Par le passé, RHEL a essayé des pages de 64 KB sur AARCH64, mais a finalement fait marche arrière à cause de nombreux bugs

  • Les efforts de Google sont impressionnants, mais on peut douter de leur réussite

• Je me demande dans quelle mesure Asahi a aidé sur le travail du noyau et de l’écosystème pour activer les pages de 16 KB

  • Le fait que RISC-V soit resté bloqué sur des pages de 4 KB semble être une erreur

• iOS utilise des pages de 16K depuis longtemps

  • OSX est passé aux pages de 16K avec le M1 en 2020
  • Windows reste sur des pages de 4K, y compris sur AArch64
  • Linux prend en charge différentes tailles de page. Asahi est en 16K

• Je me demande si l’augmentation de la taille des pages a un impact négatif sur les performances d’E/S ou sur la durée de vie du flash

  • Je me demande aussi si l’unité d’écriture des appareils flash modernes gérés est supérieure à 4 KB ou 16 KB

• Des gains de performance ont été mesurés

  • En particulier, l’application appareil photo démarre plus vite
  • Je me demande quelles autres optimisations sont possibles
  • Je me demande s’il serait possible de minimiser le code d’initialisation d’une manière comparable au « image dump » de Lisp

• Une amélioration de performance de 5 à 10 % semble énorme

  • Si le page walk est si coûteux, ne faudrait-il pas un TLB plus grand ?
  • Une hausse de 9 % de l’utilisation mémoire semble aussi importante
  • Je me demande quel a été l’impact sur l’utilisation mémoire

[gurugio]

• Les stockages récents mettent les E/S en cache à l’intérieur du support, donc même si des E/S se produisent en 16 KB, on s’attend à ce qu’il n’y ait pas de différence notable.
• Les performances des composants pour lesquels les performances sont cruciales, comme la caméra ou le GPU, s’améliorent grâce à l’allocation de pages contiguës.
• Le TLB étant un cache matériel, le coût risque d’être problématique.
• Il semble qu’ils considèrent qu’une augmentation de 10 % de l’utilisation mémoire ne pose pas vraiment de problème au regard de la quantité de mémoire des modèles récents.
• Prendre en charge simultanément le 4k et le 16k nécessiterait, selon moi, de modifier des éléments allant des cœurs CPU jusqu’au noyau, donc je pense que c’est presque impossible. Comme le noyau utilise depuis longtemps de grandes pages avec des mécanismes comme hugepage, je pense qu’un fonctionnement en 16k ne poserait pas de problème particulier. Quant aux problèmes pouvant survenir en dehors du noyau, dans les fonctionnalités d’Android ou dans les applications, ce sera à Google de les gérer.
• Quoi qu’il en soit, dans un contexte où la mémoire augmente progressivement sur les cœurs 64 bits, l’augmentation de la taille des pages est déjà discutée depuis longtemps sur le marché des serveurs. Je pense que les smartphones aussi vont désormais devoir l’adopter inévitablement.