Lorsque les processus peuvent dépasser la taille de la mémoire, les tables de pages deviennent également très volumineuses. Comment pourrions-nous organiser des tables de pages et TLB pour garder les temps d'accès aussi vite que possible pour les codes avec une bonne localité? Supposons, par exemple, que la mémoire physique est de 512 Ko, que chaque page est de 1 Ko et que la TLB est de 128. Si nous supposons que la plupart des processus sont de 256 Ko ou moins, nous pouvons allouer une table de page de 256 caractères. Maintenant, dans le cas inattendu, où la table de page se développe plus de 256 entrées, comment devrions-nous l'organiser? Quelles sont les implications de votre conception sur le temps moyen d'accès et sur la taille maximale de la mémoire virtuelle d'un programme?Croissance de la table de pages de la mémoire virtuelle
Répondre
La solution utilisée sur x86 consiste à avoir des tables de pages «clairsemées», c'est-à-dire qu'il n'y a pas de table complète pour contenir un mappage pour chaque page. Plutôt un mécanisme à deux niveaux est utilisé:
La mémoire virtuelle est 4 GB grande. Une seule page a la taille 4 KB. L'utilisation d'une approche à un niveau nécessiterait donc une table de 4 GB/4 KB = 1024 * 1024 entrées. Si une entrée consommait 4 octets, alors chaque processus aurait besoin de 4 MB juste pour stocker sa table.
En utilisant a two level approach nous avons un répertoire page avec 1024 entrées, chacune de la taille 4 octets (ce qui en intègrent parfaitement dans une seule page 4 KB). Ainsi, chaque entrée de ce répertoire gère 4 GB/1024 = 4 MB. Si (et seulement si) il doit y avoir un mappage de certaines pages de la mémoire virtuelle à la mémoire physique dans cette plage 4 MB, l'entrée pointe vers une instance d'une autre structure, une table page. Cela contient 1024 entrées, aussi, chacun gère 4 MB/1024 = 4 KB exactement une page.
S'il existe un processus qui nécessite une seule page pour fonctionner, l'utilisation de l'approche à un seul niveau requiert l'utilisation de 4 MB pour stocker sa configuration de mémoire virtuelle. En utilisant le mécanisme à deux niveaux décrit ci-dessus, nous avons besoin de 4 KB pour le répertoire de la page et 4 KB pour la table de page contenant le mappage pour cette page unique. Ainsi, seuls les numéros 8 KB sont utilisés pour stocker la configuration de la mémoire virtuelle. Si le processus a besoin de mémoire supplémentaire au moment de l'exécution, et si cette mémoire est à une adresse (virtuelle) non comprise dans la plage 4 MB gérée par sa table de pages, une deuxième table de pages doit être fournie, augmentant la mémoire utilisée stocker les mappages par un autre 4 KB. Cette approche à deux niveaux augmente légèrement les temps d'accès pour les pages ne se trouvant pas dans le TLB, car l'unité de gestion de la mémoire doit accéder à deux emplacements de mémoire (le répertoire de la page, puis la table de pages correspondante) pour pouvoir calculer les données physiques. adresse.
Le TLB n'est pas affecté par ceci: Il stocke les mappages de pages simples. La manière dont ces cartographies ont été établies n'est pas pertinente pour son fonctionnement.
Appliquons cela à la configuration par exemple que vous avez donné ci-dessus: Une page a 1 KB taille roussir. La plupart des processus, comme vous l'avez dit, auront 256 KB ou moins de mémoire. Mais nous voulons être en mesure d'avoir des processus utilisant plus de mémoire virtuelle.
Si nous choisissons d'avoir le dernier niveau gérer un plein 256 KB, alors nous avons 256 KB/1 KB = 256 entrées. En supposant une architecture 32 bit, cela signifie que nous pouvons avoir chaque entrée avec la taille de 4 byte (pour contenir une adresse). 256 entries * 4 Byte = 1 KB et donc une page entière. Agréable.
Pour pouvoir gérer plus de mémoire virtuelle que 256 KB, nous ajoutons une autre couche. Parce que c'est facile, nous laissons ce niveau utiliser des tables avec 256 entrées (un octet de 4 octets), aussi, pour rendre une telle table exactement dans une page. Ceci nous donne une mémoire virtuelle de 256 * 256 KB (environ 65 MB). Une adresse virtuelle dans ce système serait alors 26 bit longue:
DDDDDDDDTTTTTTTTPPPPPPPPPP
D := Index to page directory, highest level.
8 bit to be able to index 256 entries.
T := Index to page table, lower level.
8 bit to be able to index 256 entries.
P := Offset inside page.
10 bit to be able to address 1024 bytes.
un procédé utilisant moins de besoins 256 KB puis 2 KB pour gérer sa configuration mémoire. Chaque 256 KB supplémentaire de mémoire virtuelle nécessaire ajouter un autre 1 KB de la mémoire de configuration.
En supposant que le TLB peut contenir 128 entrées (votre question est un peu floue ici), il faudrait 128 * (16 + X - 10) bit, où X est le nombre de bits utilisés pour adresser la mémoire physique. (Bien que cela dépend de la implemenation réelle. Je pensais à 16 bit par entrée pour stocker les indices des structures de recherche de personnes + les bits supérieurs de l'adresse physique, sans compter les 10 bits OFFSET)
J'espère que cette répond à votre question Une implémentation réelle devra faire des choix de conception basés sur beaucoup de contraintes.