D'après ce que j'ai compris, la table des pages établit une correspondance entre les adresses virtuelles et les adresses physiques. Mais qu'en est-il si une page a été transférée sur le disque ? L'emplacement des données ne prendrait-il pas plus de bits à écrire que l'adresse physique ? L'emplacement des données ne change-t-il pas lorsque le fichier d'échange est modifié ? Ce problème est-il résolu de différentes manières selon les systèmes d'exploitation ?
Réponse
Trop de publicités?
Commençons par la question la plus simple :
L'emplacement des données ne change-t-il pas lorsque le fichier d'échange est modifié ?
Aucune modification du fichier de pages n'entraîne un changement de l'emplacement des données qu'il contient. Si un fichier de pages est étendu, d'autres clusters (regroupés en "extents" ou "runs") sont simplement ajoutés à son extrémité, de sorte que l'emplacement des données existantes ne change pas. L'emplacement des fichiers de pages est toujours relatif au début d'un fichier de pages, de sorte que même si les extensions existantes étaient déplacées, l'emplacement des fichiers de pages ne changerait pas.
Parlons maintenant des bits :
L'emplacement des données ne prendrait-il pas plus de bits à écrire que l'adresse physique ?
Oui, si le fichier de pages peut être plus grand que la taille possible de la mémoire physique, vous aurez besoin de plus de bits pour spécifier une page dans le fichier de pages que de bits pour spécifier un numéro de page physique.
Dans le système x86 sans PAE activé, il y a 20 bits dans l'entrée de la table des pages (PTE) pour le numéro de page physique (PFN, abréviation de "numéro de trame de page"). (Les PTE sont composés de 32 bits. Les 12 autres sont des bits drapeaux, le bit 0 étant le bit "valide" ou "page présente" qui indique que vous n'obtiendrez pas de défaut de page lorsque vous référencerez la page. Trois de ces bits sont réservés à l'usage du système d'exploitation. Les autres ont des significations telles que "lecture seule", "accessible uniquement en mode noyau", "désactivation du cache", etc.) (Tout ce qui figure dans ce paragraphe est déterminé par l'architecture du processeur - il est indépendant du système d'exploitation.)
Dans Windows, les mêmes bits du PTE qui contiennent le PFN pour une page valide sont, pour une page qui se trouve dans le fichier de pages, utilisés pour contenir l'emplacement à l'intérieur du fichier de pages. Ce dernier est exprimé sous la forme d'un décalage, en unités de la taille d'une page, par rapport au début du fichier de pages. Cela limite les fichiers de pages à 4 Go, tout comme le PFN de 20 bits pour les pages physiques limite la RAM à 4 Go sur ces systèmes.
Cependant, vous pouvez avoir plusieurs fichiers de pages. Il y a quatre bits supplémentaires dans l'ETP qui, pour une page dans un fichier de pages, indiquent le numéro du fichier de pages. Il peut donc y avoir 16 fichiers de pages, pour un total de 64 Go d'espace possible pour les fichiers de pages.
Lorsque vous activez le PAE sur les anciens processeurs x86 uniquement, les PTE ont une largeur de 64 bits et le CPU implémente 24 bits (au lieu de 20) de PFN dans le PTE. Cela permet de disposer de 64 Go de mémoire vive et, sous Windows, de 64 Go de fichiers de pages. Il y a beaucoup de bits inutilisés dans ce format PTE, de sorte qu'un système d'exploitation pourrait prendre en charge des fichiers de pages plus importants ; je ne suis pas sûr que Windows 32 bits le fasse.
Sur les nouveaux processeurs 64 bits en mode 64 bits, il y a 40 bits de PFN et, encore une fois, les mêmes bits sont utilisés pour contenir le décalage du fichier de pages pour les pages non valides (c'est-à-dire non présentes). Ainsi, RAM ou fichier de pages, nous pouvons décrire 2^40 pages - soit un "trillion binaire" de pages, 1024 au 4ème. Et chaque page a une taille de 4 KiB. Par conséquent, un fichier de pages de 4 KiB est le maximum, et également la RAM maximale supportée par le matériel. Et encore une fois, Windows indique qu'il est possible d'avoir plusieurs fichiers de pages. Je ne pense pas que nous nous heurterons bientôt à des limites d'espace pour les fichiers de pages. :)
Tout ce qui précède et qui n'est pas appliqué par le processeur est spécifique au système d'exploitation. Il n'y a en fait aucune raison pour que l'emplacement au sein du fichier de pages soit stocké dans l'ETP ; une autre structure pourrait être utilisée. Sur les processeurs tels que PowerPC qui utilisent une table de pages hachée, le système d'exploitation ne peut le stocker dans le PTE, puisqu'un PTE non valide n'est pas du tout stocké dans la structure HPT.
Mais sur x86/x64, il n'y a vraiment aucune raison de ne pas utiliser le PTE invalide. Cela fonctionne, d'ailleurs, parce que lorsque le bit "valide" est vide, le MMU ne se préoccupe pas du tout (jeu de mots) du reste de l'ETP. Ainsi, pour les PTE non valides, tous les bits sauf un sont disponibles pour que le système d'exploitation puisse les utiliser à sa guise. Sous Windows, il existe en fait plusieurs autres formes de "PTE non valide", en fonction de l'état de la page. Pour une page figurant dans la liste des pages en attente ou modifiées, par exemple, le champ PFN contient toujours l'emplacement physique de la page dans la RAM. L'ETP d'une page non valide peut faire référence à un "descripteur d'adresse virtuelle" ou, s'il s'agit d'une page partagée, à un "ETP prototype". Le MMU matériel ne voit jamais l'une ou l'autre de ces structures, mais uniquement les PTE.
Tous les détails se trouvent dans le chapitre "Gestion de la mémoire" de l'ouvrage Internes de Windows par Solomon, Russinovich et Ionescu.
