Pourquoi le système d'exploitation ne peut-il pas utiliser la totalité des 64 bits pour l'adressage ? Pourquoi seulement les 48-bits ?

Question

Je suis en train de lire "Understanding Linux Kernel".

Pagination pour les architectures 64 bits

Comme nous l'avons vu dans le précédent sections précédentes, la pagination à deux niveaux est couramment utilisée par les microprocesseurs 32 bits. La pagination à deux niveaux, cependant, n'est pas convient pas aux ordinateurs qui adoptent une architecture 64 bits. Nous allons utiliser une expérience de pensée pour expliquer pourquoi :

Commencez par supposer une taille de page standard de 4 Ko. Comme 1 Ko couvre une gamme de 2 10 adresses, 4 KB couvre 2 12 adresses, le champ Offset est donc de 12 bits. Cela laisse jusqu'à 52 bits de l'adresse l'adresse linéaire à distribuer entre le champ Table et le champ Directory et le champ Directory. Si nous décidons maintenant d'utiliser seulement 48 des 64 bits pour l'adressage (cette restriction nous laisse avec un espace d'adressage confortable de 256 TB) , les 48-12 = 36 bits restants devront devront être répartis entre les champs Table et champ Répertoire. Si nous décidons maintenant de de réserver 18 bits pour chacun de ces deux champs, le répertoire de pages et les tables de pages de chaque processus devraient inclure 2 18 entrées, c'est-à-dire plus de 256 000 entrées.

1. "Si nous décidons maintenant d'utiliser seulement 48 des 64 bits pour l'adressage". Pourquoi ? & Pourquoi seulement 48 bits ? Pourquoi pas un autre nombre ?

2. Je ne suis qu'un simple utilisateur de PC et un programmeur. J'ai du mal à croire que l'adressage 32 bits, c'est-à-dire un espace d'adressage de 4GB (2GB/3GB pour être plus correct) par processus, soit une limite. Si vous vraiment a rencontré cette limite. Veuillez me donner un exemple.

3. Quelle est cette limite pour Windows ?

4. Je sais que la mémoire virtuelle != la mémoire physique & les broches d'adresse du processeur n'ont rien à voir avec la mémoire virtuelle. Il s'agit d'une question complètement différente. Comment connaître le nombre de broches d'adresse (= taille du bus d'adresse) pour un processeur. http://ark.intel.com Les spécifications d'un processeur n'incluent pas cette spécification.

Réponse :

Voir La réponse de Paul Betts pour une réponse raisonnable à la première question.

Answer 1

Aucune de ces réponses n'est correcte, la raison pour laquelle les systèmes d'exploitation n'utilisent pas la totalité des 64 bits est que les tables de pages seraient beaucoup plus grandes (64 bits représentent déjà 3 niveaux de tables de pages), et il n'y a aucune raison de payer l'indirection supplémentaire nécessaire, 48 bits sont suffisants. Les 48 bits sont également pratiques parce que vous obtenez quelques bits supplémentaires pour stocker les drapeaux (marquage des pointeurs).

Answer 2

"Si nous décidons maintenant d'utiliser seulement 48 des 64 bits pour l'adressage". Pourquoi ? & Pourquoi seulement 48bits ? Pourquoi pas un autre nombre ?

Les architectes de systèmes font des compromis. 256 To semblent être plus que suffisants pour l'espace d'adressage d'un processus. N'oubliez pas que l'adresse virtuelle = l'adresse physique et que, d'une manière générale, chaque processus possède son propre espace d'adressage.

Tant que les pointeurs sont en 64 bits, il s'agit plus d'un problème de capacité de performance que d'autre chose. Si et quand 48 bits deviennent une limitation, le système d'exploitation pourrait être modifié pour utiliser plus de bits de l'espace d'adressage 64 bits sans rompre l'incompatibilité des applications. Pour l'instant, les architectes ne font que s'offrir un délai très confortable.

Cela peut avoir un rapport avec les capacités d'adressage virtuel du côté du processeur, car de nombreux processeurs ont désormais unités de gestion de la mémoire pour gérer le mappage de la mémoire virtuelle -> physique.

Comment connaître le nombre de broches d'adresse (= taille du bus d'adresse) pour un processeur. http://ark.intel.com Les spécifications d'un processeur n'incluent pas cette spécification.

C'est en grande partie sans intérêt. C'est un moyen pour un processeur de mettre en œuvre différents schémas d'adressage physique. Un processeur 64 bits pourrait réaliser des bus d'adresses/données externes pour son espace d'adressage complet avec 64, 32, 16, 8, 4, 2 ou 1 broche d'adresse si le bus est synchrone et que les bits d'adresse sont multiplexés dans le temps. Encore une fois, adresse virtuelle != adresse physique ; l'adressage virtuel de 64 bits pourrait être implémenté avec des adresses physiques de 48 ou 32 bits (mais vous seriez limité à 2 ou 3 bits). 48 ou 2 32 mots de mémoire).

mettre à jour : si vous voulez vraiment savoir, vous devez regarder la fiche technique de chaque processeur en question. Par exemple. Intel Core 2 Duo -- la section 4.2 de la fiche technique parle des signaux -- le bus d'adresse a une largeur de 36 bits (mais il s'agit en fait de 33 lignes de signaux ; la largeur des données est de 64 bits = 8 octets, donc les 3 autres lignes sont probablement inutiles avec un alignement correct des données).

Je ne suis qu'un simple utilisateur de PC et un programmeur. J'ai du mal à croire que l'adressage 32 bits, c'est-à-dire un espace d'adressage de 4GB (2GB/3GB pour être plus correct) par processus, soit une limite. Si vous avez vraiment rencontré cette limite. Veuillez me donner un exemple.

Deux mots : _fichiers à mémoire partagée_ .

Answer 3

Aucune conception actuelle de x86-64 n'utilise plus de 1,5 million d'euros. 48 bits pour cela - c'est donc un nombre pratique à choisir, et c'est automatiquement la même limite sous Windows, aussi.

Answer 4

J'ai du mal à croire que l'adressage 32 bits, c'est-à-dire 4GB (2GB/3GB pour être plus correct) d'espace d'adressage par processus, soit une limite. Si vous avez vraiment rencontré cette limite. S'il vous plaît donnez-moi un exemple.

Il est plus efficace (plus rapide) d'extraire des données de la mémoire vive que de les extraire du disque.

La vitesse du serveur SQL dépend en partie de la quantité de données (par exemple, le nombre de pages d'index et de données) qu'il est capable de conserver en mémoire vive plutôt que sur disque.

Ainsi, les bases de données SQL (par exemple) peuvent être plus rapides sur les machines disposant de plus de 4 Go de RAM.

Il en va de même pour d'autres types de serveurs (par exemple, les serveurs de fichiers, les proxies HTTP, etc.), qui peuvent être plus rapides s'ils disposent de caches RAM plus importants.

Answer 5

Je pense que la réponse la plus simple est : la loi de Moore.

La loi de Moore dit en substance que le coût des circuits intégrés diminue de moitié tous les 18 mois. Il y a plusieurs façons d'interpréter cette loi : La quantité de mémoire installée dans un PC a tendance à doubler tous les 18 mois. La vitesse effective double (du moins si l'on prend les cœurs * les MHz plutôt que les seuls MHz).

Quoi qu'il en soit, l'espace d'adressage de 32 bits vient de s'épuiser, de sorte qu'un saut de 32 à 48 signifie que, du côté matériel, nous avons alloué un espace d'expansion pour environ 16 itérations de la loi de Moore, ce qui correspond à environ 20 ans.

Je suis à peu près sûr que si certains PC peuvent être poussés jusqu'à 10 ans, 20 ans de marge d'expansion semble un bon compromis : les ordinateurs dans 20 ans seront différents - ils n'utiliseront pas les mêmes CPU et bus de RAM, tout comme ils étaient différents il y a 20 ans. Concevoir plus de 20 ans de marge de manœuvre dans une interface n'est qu'une sur-ingénierie stupide qui ne sera jamais utilisée de toute façon.

Et il n'est pas si court que le matériel existant court un réel risque d'être obsolète trop tôt.