Werden Page Table Walks zwischengespeichert?

Ja, soweit ich das beurteilen kann, durchlaufen diese Off-Chip-Speicherzugriffe auf Intel x86-64-Prozessoren, wenn ein TLB-Fehler auftritt und der Prozessor die Seitentabelle durchläuft, diese Off-Chip-Speicherzugriffe durch die Cache-Hierarchie.

Ein paar Details sind mir noch ein wenig unklar, und ich hoffe, dass eine andere Antwort sie ausfüllen wird – gibt es nicht ein Intel- oder AMD-Handbuch, das den Seitengang in qualvollen Details beschreibt? Mein Verständnis ist folgendes:

• 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 jedem anderen Register wird an den L1 DTLB übergeben .
• Wenn diese erste Suche fehlschlägt, wird eine weitere Ebene mit langsamerem, größerem TLB versucht. (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, signalisiert die CPU einen TLB-Miss-Fehler, der vom OS-Kernel abgefangen wird. Mein Verständnis ist, dass praktisch alle Nicht-x86-CPUs dasselbe tun - TLB-Fehler vollständig in der Software behandeln. Wenn aktiviert, verfügen x86- und x86-64-Prozessoren über einen hardwareunterstützten VHPT-Tablewalker, der die nächsten Schritte übernimmt. (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 aktivieren und VHPT für andere Adressbereiche deaktivieren können? Wo befinden sich diese Bits?)
• Wenn die TLB-Suche vollständig fehlschlägt, wird die ursprüngliche (wahrscheinlich Benutzermodus-) virtuelle Adresse V1 in V2 umgewandelt, die virtuelle Adresse des Seitentabelleneintrags PTE, der die physikalische Seitennummer für V1 enthält.
• Da V2 wieder eine virtuelle Adresse ist, durchläuft die CPU die normale Übersetzung von virtuellen in physische Adressen, außer dass sie L1 überspringt und direkt zu L2 geht.
• Die Hardware sucht die virtuelle Adresse V2 im TLB parallel zum Abrufen dieser PTE aus dem (virtuell indizierten) L2-Cache.
• Da V2 nicht die Adresse einer Anweisung ist, geht sie nicht durch den L1-Anweisungscache; und da V2 nicht die Adresse normaler Benutzerdaten ist, geht es nicht durch den L1-Datencache. V2 wird anfänglich in den einheitlichen L2-Cache (einen einheitlichen Befehls- + Daten- + PTE-Cache) eingespeist. Siehe "Cache-Hierarchiebeispiel" .
• 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 verwendet ursprüngliche virtuelle Adresse V1 in die physische RAM-Adresse, um diese Daten oder Befehle schließlich vollständig in Hardware ohne Unterstützung durch das Betriebssystem abzurufen.
• Wenn alle Ebenen des virtuell indizierten Caches fehlschlagen, aber diese zweite TLB-Suche für V2 erfolgreich ist, ruft das 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 darin PTE wird verwendet, um die ursprüngliche virtuelle Adresse V1 in die physische RAM-Adresse zu übersetzen, um diese Daten oder Befehle schließlich vollständig in Hardware ohne Unterstützung durch das Betriebssystem abzurufen.
• Wenn diese zweite TLB-Suche fehlschlägt, gibt der Hardware-VHPT-Walker mit einem VHPT TRANSLATION FAULT auf.
• Wenn ein VHPT-ÜBERSETZUNGSFEHLER auftritt, springt die CPU zum Betriebssystem. Das Betriebssystem muss herausfinden, was schief gelaufen ist, und die Dinge beheben:
• (a) Vielleicht ist die Seite, die V2 enthält, derzeit auf die Festplatte ausgelagert, sodass das Betriebssystem sie in den RAM liest und die fehlgeschlagene Anweisung neu startet, oder
• (b) vielleicht versucht ein fehlerhaftes Programm, eine ungültige Position zu lesen oder zu schreiben oder auszuführen, und das Betriebssystem beendet den Prozess, oder
• (c) eine Vielzahl anderer Tricks, die die OS-Schreiber anwenden, um diesen Mechanismus zu verwenden, um verschiedene Zugriffsarten abzufangen – Laden der Seite, die V1 enthält, die auf die Platte ausgelagert werden kann; verschiedene Traps zum Debuggen neuer Programme; um "W^X" auf CPUs zu simulieren, die es nicht direkt unterstützen; um Copy-on-Write zu unterstützen; usw.

Das Diagramm auf Seite 2 von Thomas W. Barr, Alan L. Cox, Scott Rixner. "Translation Caching: Skip, Don't Walk (the Page Table)" , das eine Linie zieht zwischen "Einträge, die vom MMU-Cache gespeichert werden" und "Einträge, die vom L2-Datencache gespeichert werden". (Dies kann ein nützliches Papier für Leute sein , die neue CPUs entwerfen , was völlig zum Thema "Elektronikdesign" gehört).

Stéphane Eranian und David Mosberger. „Virtueller Speicher im IA-64-Linux-Kernel“ und Ulrich Drepper. "Was jeder Programmierer über Speicher wissen sollte" (Dies könnte ein nützliches Papier für Leute sein, die Betriebssysteme schreiben, die sich mit der IA-64-Seitentabelle befassen, die für ED etwas off-topic ist -- vielleicht Stack Overflow mit dem "operating- system"-Tag oder das "osdev"-Tag oder das OSDev.org-Wiki wäre ein besserer Ort für dieses Thema).

Tabelle A-10 auf Seite 533 von Intel. "Intel® 64 and IA-32 Architectures Software Developer's Manual" "PAGE_WALKS.CYCLES ... kann darauf hinweisen, ob die meisten Page-Walks von den Caches erfüllt werden oder einen L2-Cache-Miss verursachen."

Ich stimme eher zu, dass dies in einen Stapelaustausch für Computerarchitekturen gehört, nicht in einen Austausch von Elektronikstapeln, aber da dies hier ist:

@davidcary hat recht.

Einige Geschichten:

Intel x86 Page Table Walks wurden NICHT bis zu P5, auch bekannt als Pentium, zwischengespeichert. Genauer gesagt wurden die Zugriffe auf den Page Table Walk-Speicher nicht zwischengespeichert, sondern der Cache umgangen. Da die meisten Maschinen bis zu diesem Zeitpunkt Write-Through waren, erhielten sie Werte, die mit dem Cache konsistent waren. Aber sie haben die Caches nicht ausspioniert.

P6, auch bekannt als Pentium Pro, und AFAIK allen nachfolgenden Prozessoren war es erlaubt, auf den Cache zuzugreifen und einen aus dem Cache gezogenen Wert zu verwenden. Daher arbeiteten sie mit Write-Back-Caches. (Sie könnten die Seitentabellen natürlich in nicht zwischenspeicherbaren Speicher platzieren, der z. B. durch die MTRRs definiert ist. Dies ist jedoch ein großer Leistungsverlust, obwohl es zum Debuggen von Betriebssystemen nützlich sein kann.)

Übrigens ist dieses "Zugriffe auf den Seitentabellendurchgangsspeicher können auf die Daten-Caches zugreifen" getrennt von "Seitentabelleneinträge können in einem TLB-Ttranslation-Lookaside-Puffer gespeichert (cachegespeichert) werden". Auf manchen Rechnern wird der TLB als „Übersetzungscache“ bezeichnet.

Ein weiteres damit zusammenhängendes 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 ausspioniert. Aber die TLB- und PDE-Caches werden nicht snooped, dh sind nicht kohärent. Das Fazit ist, dass, da die Seitentabellen in nicht kohärenten TLBs und PDE-Caches usw. zwischengespeichert werden können, die Software explizit entweder einzelne Einträge oder Massengruppen (wie den gesamten TLB) löschen muss, wenn Seitentabelleneinträge, die dies gewesen sein könnten, explizit gelöscht werden zwischengespeichert werden geändert. Zumindest wenn auf "gefährliche" Weise geändert, von RW->R->I gewechselt oder Adressen geändert werden.

Ich denke, es ist fair zu sagen, dass jedes Mal, wenn eine neue Art von nicht kohärentem TLB-ähnlichem Caching hinzugefügt wurde, ein Betriebssystem kaputt gegangen ist, weil es implizit angenommen hatte, dass dies nicht getan wurde.