Déterminer la taille de la table de page pour la mémoire virtuelle

Eh bien, si la question est simplement "quelle est la taille de la table de page?"qu'elle s'inscrive ou non dans la mémoire physique, la réponse peut être calculée ainsi:

premier souvenir physique. Il y a 512K pages de mémoire physique (512M / 1K). Cela nécessite 19 bits pour représenter chaque page. Ajoutez ça aux 4 bits d'information comptable et vous obtenez 23 bits.

maintenant mémoire virtuelle. Avec un espace d'adresse de 38 bits et une taille de page de 10 bits (1K), vous avez besoin 2 ²⁸ entrées dans votre tableau de page.

donc 2 ²⁸ les entrées de tableau de page à 23 bits chacune est de 6,174,015,488 bits ou 736M.

C'est la taille maximale nécessaire pour un seul niveau de la VM sous-système pour chaque processus.

maintenant évidemment, cela ne va pas marcher si vous avez seulement 512M de RAM physique donc vous avez quelques options.

1. Vous pouvez réduire le nombre de pages physiques. Exemple, permettez seulement à la moitié de la mémoire d'être sujet à la pagination, en gardant l'autre moitié résident à tout moment. Cela permettra d'économiser un peu par entrée, pas vraiment assez pour faire une différence.

2. Augmenter la taille de la page, si possible. Une page de 1K sur un espace d'adresse de 38 bits est la raison pour les tables de page très volumineuses. Par exemple, je pense que le '386, avec son espace d'adresse de 32 bits, utilise 4K pages. Cela se traduirait par un million d'entrées de tableau de page, beaucoup moins que les 260 millions nécessaires ici.

3. multi-niveau. Un peu plus avancé mais il signifie fondamentalement que les tables de page eux-mêmes sont sujets à la pagination. Vous devez garder le premier niveau des tables de page résident dans la mémoire physique, mais le deuxième niveau peut entrer et sortir si nécessaire. Ceci réduira considérablement les exigences physiques mais au prix de la vitesse, puisque deux niveaux de défauts de page peuvent se produire pour obtenir une page de processus réelle (un pour les tables de pagination secondaires puis un pour le processus de la page).

regardons de plus près à l'option 3.

si nous autorisons 32M pour la table de pagination primaire et donnons à chaque entrée 4 bytes (32 bits: seulement 23 sont nécessaires mais nous pouvons arrondir pour l'efficacité ici), cela permettra 8.388.608 pages pour la table de page secondaire.

puisque chacune de ces pages de table de page secondaire est de 1K long (nous permettant de stocker 256 entrées de table de page secondaire à 4 bytes chacun), nous pouvons adresser un total de 2 147 483 648 pages virtuelles.

cela permettrait à 8 192 processus entièrement chargés (c.-à-d. utilisant leur espace d'adresse entier de 28 bits) de s'exécuter côte à côte, en supposant que vous ayez une bonne partie de l'espace disque pour stocker les pages non-résidentes.

de toute évidence, la table de pagination primaire (et le sous-système VM, et probablement une bonne partie du reste de L'OS) doit rester résidente à tout moment. Vous ne pouvez pas être autorisé à biper une des pages primaires car vous pourriez bien avoir besoin que la page afin de le ramener dans :-)

mais c'est un coût résident de seulement 32M du 512M pour la table de pagination primaire, beaucoup mieux que le (au minimum, pour un processus entièrement chargé) de 736M.