Comprendre la taille des pages de mémoire sur ARM64 –

L’une des façons dont l’architecture ARM64 est différente de X86 est la capacité de configurer la taille des pages de mémoire dans l’unité de gestion de la mémoire (MMU) du CPU à 4K, 16K ou 64K. Cet article résume la taille de la page de mémoire, comment configurer la taille de la page sur les systèmes Linux et lorsqu’il peut être logique d’utiliser une taille de page différente dans vos applications.

Introduction à la taille de la page de mémoire

Comme nous l’avons déjà discuté dans Diagnostic et résolution d’un problème de performance de défaut de page avec ARM64 AtomicsLes systèmes d’exploitation présentent un espace d’adresse de mémoire virtuelle aux applications et mappent les pages de mémoire physique vers des adresses mémoire virtuelles à l’aide d’un tableau de page. Le CPU fournit ensuite un mécanisme appelé Traduction Lookaside Buffer (TLB) pour s’assurer que les pages de mémoire récemment accessibles peuvent être identifiées et lues plus rapidement en utilisant le cache CPU L1 ou L2.

La taille des pages de mémoire physique (appelées granules) sur l’architecture x86 est un 4KB fixe. Sur les systèmes ARM64 comme Ampère Altra (R) ou l’ampéReone (R), cependant, le développeur peut configurer la taille des pages de mémoire physique à 4 Ko, 16 Ko ou 64KB.

Quand utiliser des tailles de page plus grandes?

Comme la modification de la taille de la page peut avoir un impact sur l’efficacité de la mémoire et les performances de votre système, il est important de comprendre quand il est logique d’utiliser une plus grande taille de page et les compromis impliqués. Des tailles de page plus grandes peuvent conduire à une utilisation moins efficace de la mémoire en ayant des pages qui ne sont pas pleines.

Par exemple, si nous stockons 7 Ko de données en mémoire, cela utilisera deux pages de 4KB pour un total de 8 Ko de mémoire sur un système avec des pages de noyau de 4 Ko, une efficacité de 87,5%. Sur un système avec des pages de 64 Ko, cependant, nous consommons maintenant une seule page de 64 Ko avec 7 Ko de données pour une efficacité de 11% avec la seule allocation ci-dessus.

Cependant, le MMU et le noyau OS sont suffisamment intelligents pour utiliser des blocs de mémoire contigus qui ont déjà été alloués mais qui ne sont pas pleins pour les allocations de mémoire futures. Si le même processus alloue 32 Ko de mémoire plus tard, nous n’utilisons toujours qu’une seule page de 64 Ko avec 39 Ko occupée. Avec la taille de la page 4K, nous gérerons désormais dix pages 4KB.

Le deuxième compromis est en performance en raison des manquements de cache pour les recherches de table de page. Il y a un nombre relativement faible d’entrées de page stockées dans le TLB pour chaque niveau de cache (L1, L2, cache de niveau système).

Avec des tailles de page plus grandes, ces entrées TLB couvrent une plus grande quantité de mémoire physique. Sur les processeurs Ampère Altra et Altra Max, par exemple, le TLB DATA L1 a 48 entrées, et le L2 TLB a 1280 entrées.

Cela signifie qu’avec un granule de 4KB, le TLB L1 peut mettre en cache des adresses pour 192 Ko de mémoire physique, et le L2 TLB peut stocker des adresses de page couvrant 5 Mo de mémoire physique.

Avec des tailles de page de 64 Ko, cela augmente à 3 Mo pour les données L1 TLB et 80 Mo pour le TLB L2. Chaque cache manque dans le TLB ajoute du temps pour une page de page pour trouver la page physique correspondant à une recherche de mémoire virtuelle, en cache la page une fois située et à la mise à jour du TLB de manière appropriée. Avec des pages plus grandes, vous avez moins de ratés de cache et de meilleures performances pour les charges de travail à forte intensité de mémoire.

Vous améliorez également les performances d’E / S en ayant des zones plus grandes de mémoire contiguë disponibles. En conséquence, les applications à forte intensité de données qui ont beaucoup de données en mémoire ou en transit peuvent bénéficier de plus grandes tailles de pages. Certaines de ces applications sont:

• Bases de données: Les systèmes de base de données ont tendance à stocker de nombreuses informations en mémoire à des fins de mise en cache et ont beaucoup d’E / S disque pour de grands ensembles de données. Les deux caractéristiques font des serveurs de base de données grands candidats pour les grandes tailles de page de mémoire.
• Infrastructure de virtualisation: Les machines virtuelles (VM) comprennent une image disque, comprenant un noyau de système d’exploitation et toutes les applications requises par cette machine virtuelle, et varient en taille de centaines de mégaoctets à des centaines de gigaoctets. En conséquence, ils peuvent utiliser de grandes quantités de mémoire et peuvent bénéficier de plus grandes tailles de page.
• Créer des serveurs pour une intégration continue: Des tâches comme la construction du processus du noyau Linux des milliers de fichiers source et utilisent beaucoup de RAM tout en les compilant. En tant que charge de travail à haut débit, les hôtes configurés avec des tailles de page plus grandes ont tendance à mieux fonctionner en tant que serveurs de construction.
• Réseau ou E / S Applications lourdes: Pour les applications avec beaucoup d’E / S réseau et de traitement des données en mémoire comme les caches d’objet, les équilibreurs de chargement, les pare-feu ou le streaming vidéo, de grandes pages de mémoire peuvent entraîner moins de défauts de page, améliorant les performances.
• Des applications à intensités intensives comme l’inférence IA: L’inférence AI, exécutant un modèle formé comme un moteur de recommandation d’un chatbot LLM, est une charge de travail intensive à la mémoire et au processeur, où de grandes tailles de page de mémoire peuvent aider à fournir des performances élevées.

En général, les performances de ces types d’applications avec des tailles de page plus grandes dépendront de plusieurs facteurs, y compris les ensembles de données impliqués et le modèle d’accès à la mémoire de l’application.

Si vous pensez que votre application pourrait bénéficier de pages de mémoire plus importantes, vous devez comparer votre charge de travail cible avec des pages 4K et 64k et prendre votre décision de déploiement en fonction des résultats de vos tests.

En plus de l’analyse comparative de votre application cible avec des pages 4K et 64K à l’aide de données de style production, vous pouvez évaluer le bénéfice potentiel de plus grandes tailles de pages à l’aide de l’outil «perf», en mesurant les stands TLB (c’est-à-dire à quelle fréquence les manchets TLB entraînent le pipeline du CPU en attendant que les informations soient chargées à partir de la mémoire).

Tout d’abord, vérifiez que le noyau prend en charge les compteurs de décrochage TLB sur Ampereone et les CPU plus récents.

# perf list | grep end_tlb
stall_backend_tlb
stall_frontend_tlb

Avec le support du noyau confirmé, les stands de pipeline en raison des manchets TLB peuvent être mesurés:

# perf stat -e instructions,cycles,stall_frontend_tlb,stall_backend_tlb ./a.out 
time for 12344321 * 100M nops: 3.7 s 
Performance counter stats for './a.out': 
12,648,071,049 instructions # 1.14 insn per cycle  
11,109,161,102 cycles  
1,482,795,078 stall_frontend_tlb  
1,334,751 stall_backend_tlb  
3\. 706937365 seconds time elapsed 
3\. 629966000 seconds user 
0\. 000995000 seconds sys

Le rapport (stall_fronttend_tlb + stall_backend_tlb) / cycles est une limite supérieure pour le temps qui pourrait être enregistré en utilisant des pages de mémoire plus grandes.

Méfiez-vous, cependant, que, comme 4K a été la taille de la page par défaut depuis si longtemps, certains packages logiciels peuvent faire cette hypothèse sur votre système, ce qui entraîne une faible efficacité dans l’utilisation de la mémoire. Ce n’est pas une situation très courante dans les piles de logiciels modernes, mais il est conseillé d’exécuter des tests et des analyses comparatives avant de s’engager dans une taille de page plus grande.

Configuration des tailles de page plus grandes sur des processeurs ampères

La modification de la taille de la taille de la page de mémoire nécessite l’exécution d’un noyau de système d’exploitation qui a été compilé pour prendre en charge la taille souhaitée. Pour les systèmes d’exploitation cloud populaires comme Red Hat Enterprise Linux, Oracle Enterprise Linux, SUSE Enterprise Linux ou Ubuntu de Canonical, les systèmes d’exploitation sont expédiés avec des noyaux pré-construits prenant en charge la taille de la page 4KB et la taille de la page 64KB sur ARM64.

Pour utiliser un noyau avec des pages de 64 Ko sur Red Hat Enterprise Linux 9:

1. Installez le package du noyau-64K:

dnf –y install kernel-64k 

2. Pour permettre le démarrage du noyau 64K par défaut au démarrage:

k=$(echo /boot/vmlinuz*64k)
grubby --set-default=$k \ 
     --update-kernel=$k \ 
     --args="crashkernel=2G-:640M" 

Pour démarrer un noyau de 64KB sur Ubuntu 22.04:

1. Installez l’ISO ARM64 + Largemm qui contient le noyau 64K par défaut, ou:
2. Installez le package Linux-Generic-64K, qui ajoutera une option de noyau 64K au menu de démarrage avec la commande sudo apt installer Linux-Generic-64K
3. Vous pouvez définir le noyau 64K comme option de démarrage par défaut en mettant à jour le menu de démarrage GRUB2 avec la commande:

echo "GRUB_FLAVOUR_ORDER=generic-64k" | sudo tee
/etc/default/grub.d/local-order.cfg

Pour des pages de 64KB sur Oracle Linux:

1. Installez le package Kernel-UEK64K:

sudo dnf install -y kernel-uek64k

2. Définissez le noyau 64K comme par défaut au moment du démarrage:

sudo grubby --set-default=$(echo /boot/vmlinuz*64k)

3. Après avoir redémarré le système, vous pouvez vérifier que vous exécutez le noyau 64K à l’aide de GetConf comme décrit ci-dessous.

Des instructions similaires peuvent être disponibles sur les sites Web d’autres distributions de systèmes d’exploitation.

Si vous construisez votre propre noyau Linux, vous pouvez utiliser Faire Menuconfig pour modifier la configuration du noyau. Dans le sous-menu «Type de processeur et fonctionnalités», vous trouverez les registres de fonctionnalités CPU ARM64 basés sur l’option de configuration des fonctionnalités du noyau, que vous pouvez passer à 16k ou 64k.

Alternativement, vous pouvez modifier directement le fichier de configuration du noyau .config directement pour définir la valeur de config_arm_page_shift à partir de sa valeur par défaut de 12 (4k = 212 octets) sur 14 (16k = 214 octets) OR16 (64K = 216 octets). Vous pouvez ensuite choisir le noyau à démarrer au démarrage en créant plusieurs entrées dans votre chargeur de démarrage pour les noyaux avec différentes tailles de page et en choisissant le noyau approprié au moment du démarrage.

Pour vérifier quel est le paramètre de taille de page du noyau pour votre noyau Linux actuel, vous pouvez utiliser l’utilitaire System GetConf. Avec une taille de page de 64k, celles-ci afficheront ce qui suit:

$ getconf PAGESIZE 
65536 

Conclusion

Pour résumer: la modification de la taille de la page de mémoire du noyau sur vos systèmes cloud peut avoir un impact positif sur les performances de l’application pour de nombreuses charges de travail cloud courantes. Si votre application comprend beaucoup de disques, de mémoire ou d’E / S réseau, vous pourrez peut-être améliorer considérablement vos performances en utilisant un noyau avec des pages 16K ou 64k activées sur les hôtes ARM.

Cependant, ce n’est pas une panacée et votre kilométrage peut varier. Nous vous recommandons de tester avec des tests de référence synthétiques et réels pour voir si la modification de la taille de la page entraînera un impact positif sur votre résultat net.

De nombreuses distributions Linux courantes avec les versions ARM64 incluent déjà plusieurs noyaux dans leurs référentiels de distribution. En installant ces packages de noyau et en les démarrant au démarrage, le coût d’essayer les plus grands noyaux pour tester s’ils fournissent une amélioration des performances sont relativement faibles.