GEF 435 Principes des systèmes d’exploitation Mémoire virtuelle II (Tanenbaum 4.3)

Revue Quelle partie du matériel transforme les adresses logiques en adresses physiques? Comment on appel l’événement quand une Trap est fait au SE parce qu’une page n’est pas en mémoire? The MMU A Page Fault

Synopsis Tables de pages multiniveaux Répertoire de pages actives (Translation Lookaside Buffer) Tables de pages inversées

On se souvient: Pagination 4 bits 12 bits Virtual Page Offset Adresse logique Notre solution jusqu’à maintenant Adresse physique PAGE TABLE 16 Entries What happens with a 32 bit address? For a 4KB page frame there are 220=1M pages...far too many entries to keep in memory (4bytes per entry) Moreover, one page frame set is needed for each process!!! 3 bits 12 bits Page Frame Offset

Tables de pages multiniveaux Avec l’agrandissement des systèmes (adressage à 32 bits et plus) nous ne pouvons pas garder une simple table de pages dans des registres à l’intérieur du MMU À moins d’utiliser des pages très, très larges Mais des pages qui sont très, très larges causent du gaspille de mémoire pour les petits processus

Tables de pages multiniveaux Considérez: plusieurs programmes, en fait la majorité des programmes n’utiliseront pas entièrement leur espace de mémoire virtuel. Ils utiliseront leurs textes, piles et le tas, mais entre le texte/tas et la pile, il y aura un très grand espace de la table de pages inutilisé. Pourquoi ne pas laisser l’espace inutilisé ailleurs… comme sur le disque? This is reasonable. If the bulk of the table is on the disk then each process will have near to a 4MB page table on disk. Even 100 processes will require a total of only 400MB. Most hard drives are in the 200+GB range now.

Tables de pages multiniveaux Cependant, pour garder une partie de la table sur le disque, elle doit être séparée en parties. Solution: paginer la table de pages Exemple: adresses de 32 bits, pages de 4KO Requiert 220 entrées dans la table de pages Sépare la table de pages en un répertoire (premier niveau) qui contient 1024 entrées et 1024 tables de pages (deuxième niveau) qui contiennent 1024 entrées pointant aux pages du programme (on a encore 1méga pages) Must be broken up into parts so that the table can be paged in memory itself and swapped like any other page in memory.

PTR 1024 Entrées 1024 Entrées 1024 Tables de Pages Index de répertoire 10 bits 12 bits Index de répertoire Index de Page Offset PTR Répertoire 1024 Entrées 1024 Entrées 1024 Tables de Pages PTR is a page table register for this process The directory is called such just so we don’t get its index confused with the page index. Draw the other lines with the pen (ctrl-p) demonstrating how each entry from the directory points to a page of page table entries and from there how each one points to a page in memory (well, they can, as long as they have a “present” bit. So why does it take Windows so frickin’ long to load? Page table creation is one of the culprits... 18 bits ??? 12 bits Cadre de Page Offset

Tables de pages multiniveaux Cet exemple a seulement deux niveaux, mais nous pouvons avoir autant de niveaux que nous voulons pour garder la grandeur des tables raisonnable Si on a des tables de pages qui sont la même grandeur que les pages de programmes, ces tables peuvent à leurs tour être paginées entre le disque et la mémoire Au minimum, seulement la page répertoire et une table de pages doit être gardées en mémoire, ce qui réduit grandement nos besoins de mémoire Cependant, cela viens quand même avec un coût... Ask them what the cost is: The cost is the time required to get a page into memory on a fault of one of the page tables Must go to the directory page, then see that the required page table is missing, TRAP to the OS, have the page loaded into memory, then look up the page we want, if it’s not in memory, have the OS load it in and update the page table Very time consuming!

La moitié d’une illusion... La raison d’avoir de la mémoire virtuelle est pour créer l’illusion que nous avons considérablement plus de RAM qu’en réalité Jusqu’à date, nous avons joué un tour au processus en lui faisant accroire que la mémoire est large, mais avec touts ces niveaux d’indirection et d’accès au disque, notre tricherie est lente Pourquoi? Pour compléter l’illusion, nous avons besoin de réduire le montant de temps requis pour identifier où une page est située By slow, what I mean is that if going to memory one takes a certain number of nanoseconds, but we have to go through 2,3, or 4 levels of indirection to look up a page we have doubled, tripled, or quadrupled our search time through page tables!!! Then, if you have a page fault you are really screwed.

Répertoire de pages actives (RPA) Les dessinateurs d’ordinateurs et de SE ont fait une observation sur le comportement d’un programme: Un programme tend à faire un grand nombre de références à un petit nombre de pages. Parce que les programmes ont des boucles et des conditions, le fonctionnement normal d’un programme n’a pas souvent besoin de traitement des exceptions, du programme d’aide, … Pensez au programmes que vous vous servez et regardez les items dans les menus que vous utilisés rarement ou jamais. Si nous gardons une liste des pages les plus récemment utilisées dans une mémoire rapide (genre cache) alors nous pouvons réduire les recherches dans les tables de pages Cette liste est gardée dans le Répertoire de pages actives (translation lookaside buffer)

Répertoire de pages actives (RPA) Pour permettre un accès rapide, la liste doit être stockée dans la mémoire associative Ce genre de mémoire nous permet de comparer une valeur (numéro de page virtuelle) avec tout les champs de la mémoire associative simultanément. Si la valeur est dans la mémoire associative, le résultat est presque instantané (on obtient le cadre rapidement) Concourant avec le RPA, le MMU commence à regarder dans la table de pages au cas ou l’information n’est pas dans le RPA Associative memory means that all registers can be searched simultaneously

CPU Mémoire Physique Hit dans RPA RPA Tables de pages Page virtuelle Adresse logique Page virtuelle Offset Mémoire Physique Numéro de page de cadre Hit dans RPA Adresse physique Cadre de page Offset RPA So, we check to see if the virtual page has been accessed recently. If it has (and is still valid) we have our page frame/physical address immediately. If not, we let the search through the page tables complete. If that gives us the physical address, great. If not, page fault! Tables de pages

Répertoire de pages actives (RPA) Qu’est-ce qu’il y a dans le RPA? Si nous ne voulons pas aller chercher dans le RAM, le RPA doit contenir la même information que dans la table de pages (adresse du cadre, bit de présence, bit de modification, etc...) Est-ce que cela fonctionne bien? Sur les ordinateurs avec un RPA qui a 32 entrées, 98% du temps on a un hit et on peut avoir mieux dépendamment du système

Mais un instant un système Athlon a des adresses de 64 bits... Maintenant nous avons l’illusion d’une mémoire très grande pour les processus des utilisateurs Si le système de 64 bits a des pages de 4KO? Nous avons 252 entrées dans notre solution de table de pages. C’est 36 PetaOctets!!! (1.8x1016) Utiliser un disque pour stocker 36 million gigaoctets n’est probablement pas une solution acceptable... Spécialement quand nous avons besoin d’autant d’espace pour chaque processus!!!

Table de pages inversée Une autre solution est d’avoir une table avec une entrée pour chaque cadre de page dans la mémoire RAM. Même dans les systèmes à 64 bits, le nombre d’entrées dans la table est définie par la quantité de RAM installée. De plus, on a besoin d’une seule instance de la table, pas une par processus Pour 1GO de RAM et des pages de 4KO on a besoin de seulement 230/212=218=256K entrées La solution s’appel Table de pages inversée

Table de pages inversée Problèmes avec la table de pages inversée: La traduction entre les adresses virtuelles et physiques est beaucoup plus difficile L’adresse de page virtuelle n’est plus l’index dans la table. Au lieu d’indexer nous devons maintenant vérifier les entrées dans la table pour savoir si un cadre stock la page virtuelle Vérifier 256K entrées à chaque accès à la mémoire pourrait rendre votre Pentium comme un Commodore 64 ou un Coco de Radio Shack!

Table de pages inversée Solutions Un RPA qui est suffisamment précis va grandement réduire la demande pour les recherches dans la table En plus si on garde les cadres de page physiques dans une table de hachage avec les numéros de pages virtuelles comme clés, alors nous pouvons nous servir de ce numéro pour localiser le cadre dans la table Vous allez avoir un nombre d’entrées de cadres à chaque clé pour chaque processus, si la table est raisonnablement grande, il n’y aura pas beaucoup d’entrées à chercher Habituellement 1 ou 2 entrées à chercher, maximum Worst case scenario: Every process you are running has the same virtual page in memory at the same time. This would mean that all the physical page entries would be on the single entry in the hash table. Not likely, but possible. Then again, who is going to be running 256K processes?

Table de pages inversée La table de hachage est très petite - sa grandeur sera basée sur la grandeur de la mémoire physique

Quiz Time! Questions? What is the advantage to multi-level page tables? They let us keep most of the page table on disk What is the TLB used for?