Werden Seitentabellengänge zwischengespeichert?

Wenn bei einem Mikroprozessor mit Hardware - TLB - Verwaltung (z. B. Intel x86-64) ein TLB - Fehler auftritt und der Prozessor die Seitentabelle durchläuft, durchlaufen diese (chipexternen) Speicherzugriffe die Cache - Hierarchie (L1, L2 usw.) )?

Ja, soweit ich das beurteilen kann, werden bei Intel x86-64-Prozessoren die Speicherzugriffe außerhalb des Chips durch die Cache-Hierarchie geleitet, wenn ein TLB-Fehler auftritt und der Prozessor die Seitentabelle durchläuft.

Ich bin immer noch ein bisschen verwirrt in ein paar Details, und ich hoffe, eine andere Antwort wird sie ergänzen - gibt es nicht ein Intel- oder AMD-Handbuch, das den Seitenrundgang mit unglaublichen Details beschreibt? Mein Verständnis ist, dass:

• Die virtuelle Adresse in einem Adressregister wird zuerst an einen schnellen TLB übergeben, um in eine physikalische Adresse umgewandelt zu werden - die Adresse im PC wird an den L1-ITLB übergeben, die Adresse in einem anderen Register wird an den L1-DTLB übergeben .
• Wenn diese erste Suche fehlschlägt, wird versucht, einen langsameren, größeren TLB zu ermitteln. (Ist dieser L2-TLB auch in einen ITLB und einen DTLB aufgeteilt, oder handelt es sich um einen einheitlichen TLB-Cache? Gibt es weitere TLB-Ebenen - L3? L4?)
• Wenn die TLB-Suche vollständig fehlschlägt und der x86- und x86-64-VHPT-Walker deaktiviert ist, meldet die CPU einen TLB-Fehler, der vom Betriebssystemkern abgefangen wird. Ich verstehe, dass praktisch alle Nicht-x86-CPUs dasselbe tun - TLB-Fehler vollständig in Software behandeln. Wenn aktiviert, verfügen x86- und x86-64-Prozessoren über einen hardwaregestützten VHPT-Table-Walker, der die nächsten Schritte ausführt. (Haben die x86- und x86-64-Chips ein Bit, das VHPT vollständig deaktiviert, oder gibt es viele Bits, die VHPT für einige Adressbereiche und VHPT für andere Adressbereiche aktivieren können? Wo befinden sich diese Bits?)
• Wenn die TLB-Suche vollständig fehlschlägt, wird die ursprüngliche virtuelle Adresse V1 (wahrscheinlich im Benutzermodus) in die virtuelle Adresse V2 des Seitentabelleneintrags PTE konvertiert, der die physikalische Seitennummer für V1 enthält.
• Da V2 wieder eine virtuelle Adresse ist, durchläuft die CPU die normale Umwandlung von virtueller in physische Adresse, außer dass L1 übersprungen und direkt zu L2 übergegangen wird.
• Die Hardware sucht parallel zum Abrufen des PTE aus dem (virtuell indizierten) L2-Cache nach der virtuellen Adresse V2 im TLB.
• Da V2 nicht die Adresse eines Befehls ist, durchläuft es nicht den L1-Befehls-Cache. und weil V2 nicht die Adresse normaler Benutzerdaten ist, geht es nicht durch den L1-Datencache. V2 wird anfänglich in den L2-Unified-Cache eingespeist (ein Unified-Befehl + Daten + PTE-Cache). Siehe "Beispiel für eine Cache-Hierarchie" .
• Wenn der L2-Cache (oder L3 oder ein anderer virtuell indizierter Cache) den PTE enthält, ruft der VHPT den PTE aus dem Cache-Speicher ab und installiert den PTE für V1 im TLB, und die physikalische Adresse in diesem PTE wird zum Übersetzen des PTE verwendet Die ursprüngliche virtuelle Adresse V1 wird in die physikalische RAM-Adresse eingegeben, und diese Daten oder Befehle werden schließlich vollständig in Hardware ohne Unterstützung des Betriebssystems abgerufen.
• Wenn alle Ebenen des virtuell indizierten Caches fehlschlagen, diese zweite TLB-Suche jedoch für V2 erfolgreich ist, ruft der VHPT den PTE aus dem physisch indizierten Cache oder aus dem Hauptspeicher ab, installiert den PTE für V1 im TLB und die physische Adresse in diesem PTE wird verwendet, um die ursprüngliche virtuelle Adresse V1 in die physikalische RAM-Adresse zu übersetzen und diese Daten oder Befehle schließlich vollständig in Hardware abzurufen, ohne Unterstützung durch das Betriebssystem.
• Wenn diese zweite TLB-Suche fehlschlägt, gibt der Hardware-VHPT-Walker mit einem VHPT-ÜBERSETZUNGSFEHLER auf.
• Wenn ein VHPT TRANSLATION FAULT auftritt, ruft die CPU das Betriebssystem auf. Das Betriebssystem muss herausfinden, was schief gelaufen ist, und die folgenden Probleme beheben:
• (a) Möglicherweise wird die Seite mit V2 gerade auf die Festplatte ausgelagert, sodass das Betriebssystem sie in den RAM einliest und den fehlgeschlagenen Befehl erneut startet, oder
• (b) Möglicherweise versucht ein fehlerhaftes Programm, einen ungültigen Speicherort zu lesen, zu schreiben oder auszuführen, und das Betriebssystem bricht den Prozess ab
• (c) eine Vielzahl anderer Tricks, die die OS-Schreiber anwenden, um mit diesem Mechanismus verschiedene Arten von Zugriffen abzufangen. Laden Sie die Seite mit V1, die möglicherweise auf die Festplatte ausgelagert wurde. verschiedene Traps zum Debuggen neuer Programme; "W ^ X" auf CPUs simulieren, die es nicht direkt unterstützen; Unterstützung von Copy-on-Write; etc.

Das Diagramm auf Seite 2 von Thomas W. Barr, Alan L. Cox und Scott Rixner. "Übersetzungs-Caching: Überspringen, nicht gehen (die Seitentabelle)" , mit der eine Linie zwischen "im MMU-Cache gespeicherten Einträgen" und "im L2-Daten-Cache gespeicherten Einträgen" gezogen wird. (Dies ist möglicherweise ein nützliches Dokument für Benutzer , die neue CPUs entwickeln. Dies ist ein Thema, das sich ausschließlich mit dem Thema "Elektronikdesign" befasst.)

Stephane Eranian und David Mosberger. "Virtueller Speicher im IA-64 Linux Kernel" und Ulrich Drepper. "Was jeder Programmierer über Speicher wissen sollte" (Dies ist möglicherweise ein nützliches Dokument für Leute, die Betriebssysteme schreiben, die sich mit der IA-64-Seitentabelle befassen, was für ED ein wenig unangebracht ist - vielleicht ein Stapelüberlauf mit dem "Betriebssystem". System "-Tag oder das " osdev "-Tag oder das OSDev.org-Wiki wären ein besserer Ort für dieses Thema.

Tabelle A-10 auf Seite 533 von Intel. "Intel® 64- und IA-32-Architekturen - Software-Entwicklerhandbuch" "PAGE_WALKS.CYCLES ... kann anzeigen, ob die meisten Page-Walks von den Caches befriedigt werden oder einen L2-Cache-Miss verursachen."

Ich stimme eher zu, dass dies in einer Computerarchitektur zu Stackexchange gehört, nicht zu einem Electronics Stackexchange, aber da dies hier ist:

@davidcary ist richtig.

Einige Geschichten:

Intel x86 Page Table Walks wurden NICHT bis zu P5, auch bekannt als Pentium, zwischengespeichert. Genauer gesagt wurden die Seitentabellen-Durchlaufspeicherzugriffe nicht zwischengespeichert, und der Cache wurde umgangen. Da die meisten Maschinen bis zu diesem Zeitpunkt durchgeschrieben wurden, erhielten sie Werte, die mit dem Cache übereinstimmen. Aber sie haben die Caches nicht beschnüffelt.

P6, auch bekannt als Pentium Pro, und AFAIK, alle nachfolgenden Prozessor-Seitentabellengänge, durften auf den Cache zugreifen und einen aus dem Cache abgerufenen Wert verwenden. Daher arbeiteten sie mit Write-Back-Caches. (Sie können die Seitentabellen natürlich in einem nicht zwischenspeicherbaren Speicher ablegen, der z. B. durch die MTRRs definiert wird. Dies ist jedoch ein großer Leistungsverlust, auch wenn dies beim Debuggen von Betriebssystemen hilfreich sein kann.)

Übrigens kann dieser "Seitentabellen-Durchlaufspeicherzugriff auf die Daten-Caches" getrennt von "Seitentabelleneinträgen können in einem TLB-Ttranslation-Lookaside-Puffer gespeichert (zwischengespeichert) werden". Auf einigen Computern wird der TLB als "Übersetzungs-Cache" bezeichnet.

Ein weiteres verwandtes Problem besteht darin, dass innere Knoten der Seitentabellen in noch mehr TLB-ähnlichen Datenstrukturen, z. B. dem PDE-Cache, zwischengespeichert werden können.

Ein wesentlicher Unterschied: Der Datencache ist kohärent und wird überwacht. Die TLB- und PDE-Caches werden jedoch nicht abgehört, dh sie sind nicht kohärent. Da die Seitentabellen in nicht kohärenten TLBs und PDE-Caches usw. zwischengespeichert werden können, muss die Software entweder einzelne Einträge oder Massengruppen (wie den gesamten TLB) explizit leeren, wenn dies bei Seitentabelleneinträgen der Fall war zwischengespeichert werden geändert. Zumindest, wenn es auf "gefährliche" Weise geändert wurde, von RW-> R-> I oder wenn Adressen geändert wurden.

Ich denke, das ist fair zu sagen, dass jedes Mal, wenn eine neue Art von nicht kohärentem TLB-ähnlichem Caching hinzugefügt wurde, einige Betriebssysteme kaputt gegangen sind, weil implizit davon ausgegangen wurde, dass dies nicht geschehen ist.