Wie sieht der Inhalt der Seitentabelle aus, nachdem eine Seite auf die Festplatte ausgelagert wurde?

548
Deckel

Soweit ich weiß, ordnet die Seitentabelle virtuelle Adressen physischen Adressen zu. Was aber, wenn eine Seite auf die Festplatte ausgelagert wurde? Würde der Speicherort der Daten nicht mehr Bits als die physische Adresse aufschreiben? Ändert sich der Speicherort der Daten nicht, wenn die Auslagerungsdatei geändert wird? Wird dieses Problem in verschiedenen Betriebssystemen auf unterschiedliche Weise gelöst?

1

1 Antwort auf die Frage

1
Jamie Hanrahan

Nehmen wir zuerst die einfachere Frage:

Ändert sich der Speicherort der Daten nicht, wenn die Auslagerungsdatei geändert wird?

Es gibt keine Änderung der Auslagerungsdatei, die dazu führt, dass sich der Ort der vorhandenen Daten darin ändert. Wenn eine Auslagerungsdatei erweitert wird, werden einfach weitere Cluster (gruppiert in "Ausdehnungen" oder "Läufe") am Ende hinzugefügt, sodass sich der Speicherort der vorhandenen Daten nicht ändert. Die Speicherorte der Seitendateien beziehen sich immer auf den Beginn einer Seitendatei. Selbst wenn die bereits vorhandenen Erweiterungen irgendwie verschoben wurden, würden sich die Seitendateispeicherorte nicht ändern.

Nun zu den Bits:

Würde der Speicherort der Daten nicht mehr Bits als die physische Adresse aufschreiben?

Ja, wenn die Auslagerungsdatei größer sein kann als die mögliche physische Speichergröße, benötigen Sie mehr Bits, um eine Seite innerhalb der Auslagerungsdatei anzugeben, als Bits, um eine physische Seitennummer anzugeben.

In x86 ohne aktivierten PAE enthält der Seitentabelleneintrag (PTE) 20 Bits für die physische Seitennummer (PFN, kurz "Seitenrahmennummer"). (PTEs sind 32 Bits. Die anderen 12 sind Flag-Bits, wobei Bit 0 das Bit "gültig" oder "Seite vorhanden" ist, das besagt, dass beim Seitenverweis kein Seitenfehler auftritt. Drei der Flag-Bits sind für reserviert Verwendung durch das Betriebssystem. Andere haben Bedeutungen wie "Nur-Lesen", "Nur im Kernelmodus zugänglich", "Cache-Deaktivierung" usw.) (Alles in diesem Absatz wird von der CPU-Architektur bestimmt - dies ist unabhängig vom Betriebssystem.)

In Windows sind die gleichen Bits in dem PTE, die den PFN für eine gültige Seite enthalten, für eine Seite, die sich in der Auslagerungsdatei befindet, tatsächlich dazu verwendet, die Position innerhalb der Auslagerungsdatei aufzunehmen. Dies wird als Versatz in Seitengrößeneinheiten vom Beginn der Auslagerungsdatei ausgedrückt. Dies beschränkt die Auslagerungsdateien auf 4 GB, genauso wie der 20-Bit-PFN für physische Seiten den Arbeitsspeicher auf diesen Systemen auf 4 GB begrenzt.

Sie können jedoch mehrere Auslagerungsdateien haben. Es gibt vier weitere Bits im PTE, die für eine Seite in einer Auslagerungsdatei die Auslagerungsdateinummer angeben. Somit können 16 Auslagerungsdateien vorhanden sein, sodass insgesamt 64 GB Seitenspeicherplatz möglich sind.

Wenn Sie PAE für ältere x86-Prozessoren aktivieren, werden die PTEs 64 Bit breit, und die CPU implementiert 24 Bit (ab 20) PFN im PTE. Dies ermöglicht 64 GB RAM und in Windows 64 GB-Seitendateien. In diesem PTE-Format gibt es viele nicht verwendete Bits, so dass ein Betriebssystem tatsächlich größere Auslagerungsdateien unterstützen kann. Ich bin nicht sicher, ob 32-Bit-Windows dies tut.

Auf den neueren 64-Bit-Prozessoren im 64-Bit-Modus gibt es 40 Bits von PFN, und wieder werden dieselben Bits verwendet, um den Seitenauszug für ungültige (dh nicht vorhandene) Seiten zu halten. Also, RAM oder Auslagerungsdatei, können wir 2 ^ 40 Seiten beschreiben - das ist eine "binäre Billion" von Seiten, 1024 bis 4. Und jede Seite ist 4 KiB. Daher ist eine 4-PiB-Auslagerungsdatei der maximale und auch der von der Hardware unterstützte maximale Arbeitsspeicher. Wiederum sagt Windows, dass Sie mehrere Auslagerungsdateien haben können. Ich denke nicht, dass wir in Kürze auf Seitenbeschränkungen stoßen werden. :)

Alle oben genannten Punkte, die nicht von der CPU durchgesetzt werden, sind betriebssystemspezifisch. Es gibt eigentlich keinen Grund dafür, dass die location-within-Page-Datei überhaupt im PTE gespeichert werden muss. Eine andere Struktur könnte verwendet werden. Auf Prozessoren wie PowerPC, die eine Hash-Seitentabelle verwenden, kann das Betriebssystem diese nicht im PTE speichern, da ein ungültiger PTE überhaupt nicht in der HPT-Struktur gespeichert wird.

Bei x86 / x64 gibt es wirklich keinen Grund, den ungültigen PTE nicht zu verwenden. Dies funktioniert übrigens, denn wenn das "gültige" Bit frei ist, kümmert sich die MMU nicht um ein Bit (Wortspiel beabsichtigt) für den Rest des PTE. Für ungültige PTEs stehen dem Betriebssystem alle bis auf ein Bit zur Verfügung, um es nach Belieben zu verwenden. In Windows gibt es tatsächlich mehrere andere Formen von "ungültigem PTE", abhängig vom Zustand der Seite. Für eine Seite in der Standby- oder modifizierten Liste enthält das PFN-Feld beispielsweise immer noch den physischen Speicherort der Seite im RAM. Ein PTE für eine ungültige Seite kann sich auf einen "virtuellen Adressbeschreibungen" oder, wenn es sich um eine gemeinsam genutzte Seite handelt, auf einen "Prototyp-PTE" beziehen. Die Hardware-MMU sieht keine dieser Strukturen, nur PTEs.

Ausführliche Informationen finden Sie im Kapitel "Speicherverwaltung" von Windows Internals von Solomon, Russinovich und Ionescu.

Vielen Dank für das gute Feedback! Wenn Sie weitere Fragen haben, zögern Sie nicht, sie als Kommentar zu veröffentlichen oder ändern Sie Ihre ursprüngliche Frage. Jamie Hanrahan vor 8 Jahren 0