Certains processeurs prennent en charge des adresses physiques de 46 bits et des adresses virtuelles de 48 bits. Pourquoi 46 bits, pourquoi 48 bits? Est-ce que x86 ne devrait pas prendre en charge des adresses 64 bits? Pourquoi les adresses virtuelles ne sont-elles pas de la même longueur que les adresses physiques?
Les applications doivent-elles être ajustées pour utiliser des adresses physiques/virtuelles de 46/48 bits? La plupart des applications le supportent-elles?
La limite d'adresse virtuelle de 48 bits pour x86-64 est basée sur la profondeur de la hiérarchie de table de pages. Avec des pages de 4 KiB et des entrées de table de pages de 64 bits, chaque niveau de la table de pages utilise neuf bits. Utiliser trois recherches aurait fourni des adresses virtuelles de 39 bits, ce qui a été vraisemblablement reconnu comme une solution à court terme étant donné que l'ajout de niveaux nécessite le support du système d'exploitation. Utiliser quatre recherches fournit un espace d'adresses virtuelles de 48 bits.
Ajouter des niveaux a tendance à augmenter la latence en cas de miss du TLB (bien que les nœuds intermédiaires puissent également être mis en cache pour réduire la latence si il y a un hit dans ces caches) car les recherches sont dépendantes.
En ce qui concerne la limite d'adresse physique, l'entrée de table de pages est de 64 bits et contient des permissions d'accès et d'autres informations (9 bits : présentation, lecture/écriture, utilisateur/superviseur, écriture à niveau de page, désactivation du cache à niveau de page, accès, saleté, PAT et global). Les entrées de table de pages x86-64 sont actuellement définies pour inclure 14 bits pouvant être utilisés par le système d'exploitation [9:11, 52:62] et sont ignorés par le matériel. Cela laisse 41 bits disponibles pour spécifier un numéro de page, ce qui (étant donné des pages de 4 KiB) supporte des adresses physiques de 53 bits.
Le choix de prendre en charge un espace d'adresse physique plus petit que ce qui est supporté par le format d'entrée de table de pages est spécifique à l'implémentation. Fournir un espace d'adresse physique plus grand que l'espace d'adresse virtuelle introduit des problèmes pour les systèmes d'exploitation, en particulier pour ceux qui mappent l'ensemble de l'espace d'adresse physique dans l'espace d'adresse virtuelle.
Pour un processeur donné avec un contrôleur mémoire intégré, le nombre de canaux mémoire et les types de mémoire pris en charge sont fixes, ce qui impose une contrainte significative sur la capacité mémoire maximale. Ajouter plus de puces avec des contrôleurs mémoire pose des problèmes d'échelle, en particulier en ce qui concerne la latence. (Les systèmes avec de grands facteurs NUMA peuvent être utiles, mais ces systèmes ne constituent pas une cible importante pour x86-64.)
Augmenter l'espace d'adresse physique augmente la taille des étiquettes de cache (dans les caches physiquement étiquetés courants) et introduit d'autres surcoûts. Si les adresses ne seraient pas utiles pour les utilisations attendues du système, ces coûts réduiraient directement la rentabilité. (Il peut également y avoir une incitation à limiter la capacité pour encourager les mises à niveau futures.)
Les 44 bits étaient utilisés dans la version Windows 64 bits jusqu'à Windows 8.1 (avant la Mise à jour de novembre 2014 Rollup) pour faciliter la gestion de la mémoire. Depuis la Mise à jour de novembre 2014 de Windows 8.1 ou Windows 10, Windows utilise désormais 64 bits pour les adresses virtuelles. Avec cet espace d'adressage plus large, il est possible de rendre Windows plus sécurisé en fournissant Control Flow Guard (CFG)
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
