Dans un livre, j'ai lu ce qui suit :
Les processeurs 32 bits ont 2^32 adresses possibles, tandis que les processeurs 64 bits actuels ont un espace d'adressage de 48 bits.
Je m'attendais à ce que, si c'est un processeur 64 bits, l'espace d'adressage soit également 2^64.
Je me demandais donc quelle était la raison de cette limitation ?
Lisez la section sur les limitations du article de wikipédia :
Un PC ne peut pas contenir 4 pétaoctets de mémoire (notamment en raison de la taille des puces mémoire actuelles), mais AMD a envisagé de grands serveurs, des grappes de mémoire partagée et d'autres utilisations de l'espace d'adressage physique qui pourraient s'en approcher dans un avenir prévisible, et l'adresse physique de 52 bits offre une marge de manœuvre suffisante pour l'expansion sans avoir à supporter le coût de la mise en œuvre d'adresses physiques de 64 bits.
En d'autres termes, il est inutile d'implémenter un adressage 64 bits complet à ce stade, car nous ne pouvons pas construire un système qui pourrait utiliser un tel espace d'adressage dans son intégralité - nous choisissons donc quelque chose qui est pratique pour les systèmes d'aujourd'hui (et de demain).
D'où vient le 4 dans les 4 pétaoctets ? Si nous parlons de 64 lignes d'adresse, nous devrions nous retrouver avec le carré de l'espace d'adressage rendu possible par 32 lignes d'adresse, soit 4 gigaoctets. Au carré, on devrait avoir 16, pas 4 pétaoctets. Est-ce que quelque chose m'échappe ?
Pour répondre à la question initiale : Il n'y avait pas besoin d'ajouter plus de 48 Bits de PA.
Les serveurs ont besoin d'une quantité maximale de mémoire, alors essayons de creuser davantage.
1) La plus grande configuration de serveur (couramment utilisée) est un système à 8 sockets. Un système 8S n'est rien d'autre que 8 processeurs de serveur connectés par une interconnexion cohérente à haute vitesse (ou simplement, un "bus" à haute vitesse) pour former un seul nœud. Il existe des clusters plus grands, mais ils sont rares. Nous parlons ici des configurations les plus courantes. Notez que dans le monde réel, le système à 2 sockets est l'un des serveurs les plus couramment utilisés, et le système à 8 sockets est généralement considéré comme très haut de gamme.
2) Les principaux types de mémoire utilisés par les serveurs sont la mémoire DRAM ordinaire adressable par octet (par exemple, la mémoire DDR3/DDR4), la mémoire MMIO (Memory Mapped IO) (comme la mémoire utilisée par une carte d'extension), ainsi que l'espace de configuration utilisé pour configurer les périphériques présents dans le système. Le premier type de mémoire est celui qui est généralement le plus grand (et qui nécessite donc le plus grand nombre de bits d'adresse). Certains serveurs haut de gamme utilisent également une grande quantité de MMIO, en fonction de la configuration réelle du système.
3) Supposons que chaque CPU de serveur puisse accueillir 16 DIMM DDR4 dans chaque emplacement. Avec une taille maximale de DIMM DDR4 de 256 Go. (Selon la version du serveur, ce nombre de DIMM possibles par socket est en réalité inférieur à 16 DIMM, mais continuez à lire pour les besoins de l'exemple).
Chaque socket peut donc théoriquement disposer de 16*256GB=4096GB = 4 TB. Pour notre exemple de système 8S, la taille de la DRAM peut atteindre un maximum de 4*8= 32 TB. Cela signifie que le nombre maximum de bits nécessaires pour adresser cet espace DRAM est de 45 (=log2 32TB/log2 2).
Nous n'entrerons pas dans les détails des autres types de mémoire (MMIO, MMCFG, etc.), mais ce qu'il faut retenir, c'est que le type de mémoire le plus "exigeant" pour un système à 8 sockets avec les plus grands types de DIMM DDR4 disponibles aujourd'hui (DIMM de 256 Go) n'utilise que 45 bits.
Pour un système d'exploitation qui supporte 48 bits (WS16 par exemple), il reste (48-45=) 3 bits. Ce qui signifie que si nous utilisons les 45 bits inférieurs uniquement pour 32 To de DRAM, il nous reste 2^3 fois la mémoire adressable qui peut être utilisée pour MMIO/MMCFG pour un total de 256 To d'espace adressable.
Donc, pour résumer : 1) 48 bits d'adresse physique, c'est beaucoup de bits pour prendre en charge les plus grands systèmes d'aujourd'hui qui sont "entièrement chargés" avec de copieuses quantités de DDR4 et aussi beaucoup d'autres dispositifs d'E/S qui demandent de l'espace MMIO. 256 To pour être exact.
Notez que cet espace d'adressage de 256 To (=48bits d'adresse physique) n'inclut PAS les lecteurs de disques tels que les lecteurs SATA car ils ne font PAS partie de la carte d'adressage, mais uniquement la mémoire adressable par octet et exposée au système d'exploitation.
2) Le matériel de l'unité centrale peut choisir d'implémenter 46, 48 ou > 48 bits en fonction de la génération du serveur. Mais un autre facteur important est de savoir combien de bits le système d'exploitation reconnaît. Aujourd'hui, WS16 supporte des adresses physiques de 48 bits (=256 TB).
Pour l'utilisateur, cela signifie que, même s'il dispose d'un gros processeur de serveur ultra moderne capable de prendre en charge >48 bits d'adressage, s'il exécute un système d'exploitation qui ne prend en charge que 48 bits de PA, il ne peut tirer parti que de 256 To.
3) Dans l'ensemble, il y a deux facteurs principaux pour profiter d'un nombre plus élevé de bits d'adresse (= plus de capacité de mémoire).
a) Combien de bits le HW de votre CPU supporte-t-il ? (Cela peut être déterminé par l'instruction CPUID dans les CPU Intel).
b) Quelle version de système d'exploitation utilisez-vous et combien de bits de PA reconnaît-il/supporte-t-il ?
Le minimum de (a,b) déterminera finalement la quantité d'espace adressable dont votre système peut profiter.
J'ai rédigé cette réponse sans examiner en détail les autres réponses. De même, je n'ai pas approfondi les nuances de MMIO, MMCFG et l'ensemble de la construction de la carte d'adresses. Mais j'espère que cela vous aidera.
Merci, Anand K Enamandram, Architecte de plate-forme de serveur Intel Corporation
Cette question porte sur les 48 bits virtuel taille de l'espace d'adressage (exigeant que les adresses virtuelles soient canoniques). Vous voulez plus de bits virtuels que de bits physiques, de sorte qu'un noyau à moitié élevé peut mapper toute la mémoire physique dans un seul espace d'adressage (le sien ou celui de l'utilisateur). Comme vous le dites, HW n'a besoin d'implémenter qu'autant de bits PA que les contrôleurs DRAM + MMIO peuvent utiliser, et peut utiliser n'importe quel nombre jusqu'à la limite de 52 bits dans le format page-table x86-64. ( Pourquoi en 64 bits l'adresse virtuelle est courte de 4 bits (48 bits) par rapport à l'adresse physique (52 bits) ? )
Le format de table de pages à 4 niveaux impose également la limite des VA de 48 bits, jusqu'à ce que HW + SW supportent les tables de pages PML5 pour les VA de 57 bits. Quoi qu'il en soit, il s'agit d'une réponse utile, mais elle semble avoir été postée sous la mauvaise question. Je ne suis pas sûr qu'il y ait un meilleur endroit pour cela, donc je suppose que nous pouvons la laisser ici, avec une modification pour ajouter un en-tête pour dire quelque chose sur PA vs. VA.
Il n'est pas vrai que seuls les 48 bits de poids faible d'un VA 64 bits sont utilisés, du moins avec Intel 64. Les 16 bits supérieurs sont utilisés, en quelque sorte, en quelque sorte.
Section 3.3.7.1 Adressage canonique dans les Manuel du développeur de logiciels pour les architectures Intel® 64 et IA-32 dit :
une adresse canonique doit avoir les bits 63 à 48 mis à zéro ou à un (selon que le bit 47 est un zéro ou un).
Ainsi, les bits 47 à 63 forment un super-bit, soit tout 1, soit tout 0. Si une adresse n'est pas sous forme canonique, l'implémentation doit se tromper.
Sur AArch64, c'est différent. Selon le Présentation du jeu d'instructions ARMv8 il s'agit d'un VA de 49 bits.
Le système de traduction de mémoire AArch64 prend en charge une adresse virtuelle de 49 bits (48 bits par table de traduction). Les adresses virtuelles sont étendues en signe à partir de 49 bits, et stockées dans un pointeur de 64 bits. En option, sous le contrôle d'un registre système, les 8 bits les plus significatifs d'un pointeur de 64 bits peuvent contenir une "balise" qui sera ignorée lorsqu'elle est utilisée comme adresse de chargement/stockage ou comme cible d'un branchement indirect.
Seuls les 48 premiers sont significatifs, mais le matériel vérifie que le signe est correctement étendu à 64 bits. Je ne sais pas pourquoi ils n'ont pas spécifié l'extension zéro ; peut-être voulaient-ils rendre plus pratique la vérification d'une demi-adresse haute ou basse (en vérifiant simplement le bit de signe). Ou peut-être pour éviter de rendre spéciale la limite de 2^48, et pour que les adresses proches du sommet puissent s'insérer facilement dans des constantes 32 bits avec extension de signe. Je pense que la dernière hypothèse est plus probable.
Quoi qu'il en soit, la vérification du matériel actuel pour le canonique empêche les logiciels d'utiliser des bits ignorés pour les pointeurs marqués qui se briseront sur le matériel futur, c'est donc une partie du mécanisme qui rend possible l'extension du matériel futur si/quand cela est nécessaire. (Ce qui pourrait être plus tôt qu'ils ne l'avaient prévu, grâce à la mémoire non volatile qui est directement connectée à l'espace d'adressage physique et virtuel).
Procfs sous Linux sur mon Core i5 indique qu'il est mappé sur 7ffd5ea41000-7ffd5ea62000. Cette plage d'adresses est logique selon la règle "canonique" ci-dessus. Les bits 48-63 sont à 0, ce qui en fait une adresse canonique correcte. Ce qui est un peu étrange, ce sont certaines adresses dans le code source de Linux. Dans include/asm/pgtable_64_types, il est écrit #define __VMALLOC_BASE _AC(0xff92000000000000, UL). Il ne s'agit PAS d'une adresse canonique. Une telle adresse commencerait par 0xffff8. Je ne sais pas pourquoi.
Un processeur est considéré comme "N-bits" principalement en fonction de la taille de son bus de données et d'une grande partie de ses entités (architecture interne). : Registres, accumulateurs, unité arithmétique et logique (UAL), jeu d'instructions, etc. Par exemple : Le bon vieux CPU Motorola 6800 (ou Intel 8050) est un CPU 8-bits. Il possède un bus de données de 8 bits, une architecture interne de 8 bits et un bus d'adresses de 16 bits.
Il y a déjà une réponse pour illustrer ce point avec le Motorola 68000 / 68020 comme exemple. Cette question concerne spécifiquement le x86-64, et non les anciens processeurs 8 / 16 bits. Dans le cas de x86-64, l'un des principaux facteurs est que des adresses virtuelles plus larges nécessitent une table de pages plus profonde, et ce facteur n'existait pas pour les anciennes puces dont vous parlez.
La largeur du bus de données ne doit pas nécessairement correspondre à la largeur du registre ou de l'ALU. Par exemple, le Pentium P5 possède un bus de données de 64 bits (les chargements/stockages alignés de 64 bits sont garantis comme étant atomiques), mais les registres/ALU ne sont que de 32 bits (à l'exception de la FPU intégrée et, dans le Pentium MMX ultérieur, des SIMD ALU).
OP écrit : "Mon attente était que si c'est un processeur 64 bits, l'espace d'adressage devrait aussi être 2^64." ........ Vous écrivez : "Cette question concerne spécifiquement les x86-64, pas les anciens processeurs 8 / 16 bits". ........ Je pense que vous avez manqué l'essence de la question OP. La question OP est le résultat de l'hypothèse erronée qu'un CPU 64-bits devrait avoir un bus d'adresse 64-bits. A propos de l'ALU, j'ai écrit grande partie de ses entités ; pas toutes.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
19 votes
Le livre devait parler spécifiquement de l'implémentation actuelle de l'architecture AMD64 (x86-64). Seuls les 48 bits de poids faible sont utilisés. Il ne s'agit pas d'une limitation matérielle, cependant - tous les 64 bits sont disponibles.
13 votes
C'est toujours une bonne idée d'identifier le livre.
1 votes
Je suppose que les lignes d'adresses physiques ne sont pas libres (il faut au moins 16 broches supplémentaires pour le processeur). Et je ne connais pas encore de matériel capable de remplir un espace de 48 bits avec des puces de RAM physique sur le même processeur. Lorsque cela deviendra possible, je suis sûr qu'AMD ajoutera les 16 broches manquantes :)
0 votes
@Cody : Je sais ce que vous voulez dire, mais n'est-ce pas exactement une limitation matérielle, si elle est spécifique à l'implémentation actuelle de l'AMD64 ;)
8 votes
Même,
The 32-bit processors have 2^32 possible addressesn'est pas nécessairement vrai, il peut exister des processeurs 32 bits avec seulement 24 "broches" pour l'adressage de la mémoire. Par exemple, le 68EC020 (version 68020 moins chère) est un processeur 32 bits mais avec 24 bits pour l'adressage de la mémoire.28 votes
Il y a un problème très réel avec l'adressage physique 64 bits, la taille des pages de la mémoire virtuelle est trop petite. Il en résulte d'énormes répertoires de pages et des vidages de cache TLB extrêmement coûteux à chaque changement de contexte. Passer de 4KB à 4MB est une option, mais elle est très incompatible avec les systèmes d'exploitation actuels.
1 votes
En outre,
The 32-bit processors have 2^32 possible addressesest plutôt vague ; par exemple, un certain nombre de CPU x86 32 bits (généralement des serveurs/stations de travail) prennent en charge le PAE, qui permet un espace d'adressage physique de 36 bits. Un certain nombre de CPU x86_64 modernes prennent en charge un espace d'adressage physique de 48 bits et un espace d'adressage virtuel de 52 bits.1 votes
@HansPassant Pouvez-vous développer ce point ? Je ne suis pas tout à fait sûr de ce que vous voulez dire. Comment la taille de la page individuelle d'un système d'exploitation est-elle liée à l'espace d'adressage ? En quoi le fait de modifier la taille des pages permet-il d'augmenter l'espace d'adressage physique ?
1 votes
@AaronFranke : pour une taille de page et un nombre d'entrées TLB fixes, vous ne pouvez couvrir qu'une quantité fixe de la taille de l'ensemble de travail virtuel. Avec plus de RAM, c'est une fraction de plus en plus petite de la mémoire disponible, et comme la bande passante de la mémoire s'améliore, vous mâchez cet ensemble plus rapidement et obtenez plus d'échecs TLB. Mais je pense que Hans parlait principalement de la quantité d'espace nécessaire uniquement pour les tables de pages afin d'indiquer au CPU où se trouve la page physique pour chaque page virtuelle. Avec des tables de pages imbriquées plus profondément, le page walker est plus coûteux, et les TLB plus grandes coûtent plus cher si vous les videz toutes.