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

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

Transcript of GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

Page 1: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

GEF 435Principes des systèmes d’exploitation

Mémoire virtuelle II(Tanenbaum 4.3)

Page 2: GEF 435 Principes des systèmes dexploitation 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?

Page 3: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

Synopsis

• Tables de pages multiniveaux• Répertoire de pages actives (Translation Lookaside

Buffer)• Tables de pages inversées

Page 4: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

On se souvient: Pagination

Adresse logique

Notre solution jusqu’à maintenant

Adresse physique

4 bits 12 bits

Virtual Page Offset

PAGE TABLE

3 bits 12 bits

Page Frame Offset

16 Entries

Page 5: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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 largesMais des pages qui sont très, très larges causent du

gaspille de mémoire pour les petits processus

Page 6: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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?

Page 7: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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 4KORequiert 220 entrées dans la table de pagesSé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)

Page 8: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

1024

Tab

les d

e

Pages

10 bits 10 bits 12 bits

Index de répertoire Index de Page Offset

Répertoire

18 bits ??? 12 bits

Cadre de Page Offset

1024 Entrées

PTR

1024 Entrées

Page 9: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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émoireAu 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...

Page 10: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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 lentePourquoi?

• Pour compléter l’illusion, nous avons besoin de réduire le montant de temps requis pour identifier où une page est située

Page 11: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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)

Page 12: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

Répertoire de pages actives (RPA)

• Pour permettre un accès rapide, la liste doit être stockée dans la mémoire associativeCe 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

Page 13: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

CPUAdresse logique

Page virtuelle Offset

Numéro

de page

Numéro

de cadre

MémoirePhysique

Adresse physique

Cadre de page Offset

Hit dans RPA

RPA

Tables de pages

Page 14: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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

Page 15: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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 utilisateursSi 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!!!

Page 16: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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

Page 17: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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 difficileL’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!

Page 18: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

Table de pages inversée

• SolutionsUn RPA qui est suffisamment précis va grandement

réduire la demande pour les recherches dans la tableEn 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

Page 19: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

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

Page 20: GEF 435 Principes des systèmes dexploitation Mémoire virtuelle II (Tanenbaum 4.3)

Quiz Time!

Questions?