Warum gibt es in der x86-Architektur weniger Bits für den virtuellen Adressraum als für den physischen?


11

Ich habe diesen Artikel über 64-Bit-Computer gelesen und er erwähnt:

Beispielsweise erlaubte die AMD64-Architektur ab 2011 52 Bit für den physischen Speicher und 48 Bit für den virtuellen Speicher

Ich würde denken, dass es sinnvoller wäre, mehr virtuellen Speicher als physischen Speicher zuzulassen. Warum ist es also eigentlich umgekehrt?

Bonusfrage: Was bedeutet es, 52 oder 48 Bit in einer 64-Bit-Architektur zu "zulassen "? Wofür werden die anderen Bits verwendet?


Für x86 müssen die nicht verwendeten VA-Bits eine Vorzeichenerweiterung des MSbits der VA sein. (ARM AArch64 bietet die Option, 8 MSbits von der Hardware ignorieren zu lassen, damit sie bequem für Tags verwendet werden können. Der Vega-Prozessor von Azul Systems - Teil einer Java-Appliance - stellte 16 VA-Bits für Tags bereit.) In der Seitentabelle müssen reservierte PA-Bits Null sein (hauptsächlich, um sicherzustellen, dass die Software nicht versucht, sie zu verwenden, und um die Kompatibilität mit späterer Hardware zu beeinträchtigen).
Paul A. Clayton

Antworten:


11

Hier ist ein Bild einer AMD64-Seitentabelle (aus dem AMD Architecture Programmer's Guide, Band 2, Rev. 3.23, 2013, Seite 132).

AMD64 Longmode-Seitentabelle

Die "natürliche" Größe einer Seite in der AMD64-Architektur beträgt 2 12 = 4096 Byte. (Es gibt Modi, in denen Sie 2 21 = 2 MByte-Seiten haben können, aber wir werden sie vorerst ignorieren.)

Jeder Seitentabelleneintrag (PTE) (oder, abhängig von der als PDE, PDPE oder PML4E bezeichneten Ebene) ist 64 Bit = 2 3 Byte. Es gibt also 2 9 Einträge pro Seite. Mit 4 Ebenen der Seitentabelle erhalten Sie also 4x9 + 12 = 48 Bit virtuelle Adresse pro Prozess. Das Durchlaufen der Seitentabelle ist teuer, daher werden sie erst dann auf 5 oder 6 Ebenen erweitert, wenn / wenn die Nachfrage der Verbraucher besteht.

Ich bin mir nicht sicher, warum sie sich für ein physikalisches Adresslimit von 52 Bit entschieden haben. Dies kann in Zukunft auf bis zu 63 Bit erweitert werden. Bei Preisen von Oktober 2013 (ca. 1 US $ / Gigabit für 4-Gbit-Chips) würde der Aufbau eines 2 52- Byte-Speichers über 32.000.000,00 US $ kosten. Es wird also eine Weile dauern, bis eine signifikante Nachfrage nach einer Erhöhung des physischen Adresslimits besteht. Es gibt viele Gründe, warum Sie physische Adressen so klein wie möglich halten möchten: Die TLB- und Cache-Tags müssen beispielsweise physische Adressen enthalten.

Es ist nicht unbedingt rückwärts, dass es mehr physischen Speicher als virtuellen gibt. Der virtuelle Speicher ist pro Prozess, während der physische Speicher von allen Prozessen gemeinsam genutzt wird. Ein Server mit virtuellen 48-Bit-Adressen und 2 52 Byte Speicher kann also 16 gleichzeitige Prozesse unterstützen und garantiert, dass kein Austausch erforderlich ist.


Es könnte erwähnenswert sein, dass Computerarchitekten gelernt haben, die oberen Bits von der Hardware zu verwenden, normalerweise durch Vorzeichenerweiterung, um der allgemeinen Verwendung negativer Adressen für das Betriebssystem zu entsprechen ("Wofür werden die anderen Bits verwendet?"). Außerdem muss beim Zwischenspeichern von Ln-Verzeichniseinträgen eine Tabelle mit 5 Ebenen die meiste Zeit nicht vollständig durchlaufen werden. Die PTE-Bits 52:62 sind für Software reserviert und können daher nicht für physische Adressen verwendet werden, ohne die Kompatibilität zu beeinträchtigen. Dadurch werden 4-KB-Seiten auf 52-Bit-PA beschränkt. Auch Linus Torvalds tobt bekanntermaßen gegen PAE (VA> PA scheint das "traditionelle" OS-Design zu vereinfachen).
Paul A. Clayton

"Dies kann in Zukunft auf 63 Bit erweitert werden." Nein, nicht ohne die Seitentabellenstruktur zu ändern. Die Bits 52 bis 62 des PxE sind für die Verwendung durch das Betriebssystem reserviert. Und Betriebssysteme verwenden sie (Windows verwendet dieses Feld für einen "Arbeitsgruppenlistenindex"), sodass die Prozessorarchitekten nicht frei sind, das PFN-Feld in sie zu erweitern. Es wäre natürlich möglich, in Zukunft eine PAE-ähnliche Option zu haben, die die PT-Struktur ändert, um mehr PFN-Bits zuzulassen, aber das wäre eine signifikante architektonische Änderung.
Jamie Hanrahan

3

Ein paar Punkte zu beachten, ist physischer RAM teuer. Sicher, 16 GB sind jetzt billiger als 4 GB vor ein paar Jahren, aber 2 ^ 64 (16 Exabyte) sind lächerlich groß.

AMDs Erweiterungen von x86 für x64 "erlaubten" also bis zu 2 ^ 52, indem sie die Register einschränkten . Dies bewirkt zwei Dinge, senkt die Prozessorkosten und verbessert die Leistung. Mehr Register, die nicht verwendet werden, bedeuten, dass viel leerer Speicherplatz vorhanden ist, der während des Betriebs noch berücksichtigt werden muss.

Und falls Sie kein Mathematiker sind ... Der Unterschied zwischen drei Größen ist riesig! Ich bin kein Mathe-Guru, aber dezimal 52 Bit sind ungefähr 0,02% von 64 Bit. 48 Bit ist 6% von 52. (jemand überprüft meine Mathematik?)

In dem Artikel heißt es, warum AMD mehr physischen als virtuellen RAM zuließ, weil AMD an Server dachte. Server benötigen viel physischen RAM. Der virtuelle Arbeitsspeicher ist zu langsam, um die durchschnittlichen Serveranwendungen für Hunderte oder Tausende von Mitarbeitern zu unterstützen.

Meine eigenen Gedanken: Wir haben die Zeit verlassen, als der Arbeitsspeicher winzig war und Festplatten RAM unterstützen mussten. Der Preis im RAM ist auf einen Punkt gefallen, an dem die durchschnittliche Person mehr als genug RAM einsetzen kann. Nehmen Sie typische Anwendungen wie Office, für die 1-2 GB RAM erforderlich sind. Mein Computer vor 7 Jahren konnte damit umgehen. Obwohl mit Lese- und Schreibgeschwindigkeiten auf die Festplatte, würde ich hoffen, dass ich nie eine 7-GB-Datei aus dem virtuellen Speicher abrufen musste (unter Verwendung der alten PM * 2.5-Philosophie).

Ich kann auch nur davon ausgehen, dass AMD Platz für Register lassen wollte, die die physischen RAM-Register verwenden, wie z. B. RAM auf integrierten GPUs.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.