Wie findet die CPU Daten im RAM? Adressübersetzung

Symptom: Sie sehen eine virtuelle Adresse im Debugger und vermuten, die CPU greife damit direkt auf einen bestimmten RAM-Chip zu.

Schnellste Lösung: Verfolgen Sie die Adresse in vier Stufen: virtuelle Adresse, physische Adresse, Cache-Entscheidung und DRAM-Adresszuordnung. Die CPU spricht nicht direkt mit einer bestimmten DRAM-Zelle; TLB, Seitentabellen, Cache und Speichercontroller teilen sich diese Aufgabe.

Dieser Artikel ist für Sie gedacht, wenn Sie beim Lernen von Betriebssystemen oder Rechnerarchitektur virtuelle und physische Adressen vermischen. Auch bei Performanceanalysen hilft die Kette, TLB-Fehler, Cache-Misses und echte Speicherlatenz getrennt zu betrachten. Für Sicherheitsentwickler ist sie relevant, wenn es um Seitentabellen, Rowhammer, Adressraumisolation oder verschachtelte Übersetzungen in virtuellen Maschinen geht.

Die entscheidende Trennung: Adresse, Übersetzung und Speicherzelle

Nehmen wir eine einzelne Load-Anweisung:

mov rax, [buffer]

Das Programm arbeitet mit einem Zeiger auf buffer. Dieser Zeiger enthält eine virtuelle Adresse. Sie gehört zum Adressraum des laufenden Prozesses und ist nicht automatisch eine Leitung zu einem RAM-Modul.

Die CPU übergibt die Adresse an die Memory Management Unit, kurz MMU. Diese Hardware übersetzt die virtuelle Seitennummer in eine physische Seitennummer. Der Offset innerhalb der Speicherseite bleibt erhalten. Bei einer Seitengröße von 4 KiB entspricht der Offset beispielsweise den unteren 12 Bit der Adresse. Linux beschreibt diese Trennung zwischen Seitennummer und Offset in seiner Dokumentation zur Seitentabellenverwaltung. Linux-Dokumentation zu Seitentabellen

Damit entstehen drei unterschiedliche Fragen:

1. Welche virtuelle Adresse erzeugt die Load-Anweisung?
2. Auf welchen physischen Adressbereich zeigt die Seitentabelle?
3. Wie verteilt der Speichercontroller diesen physischen Bereich auf die DRAM-Struktur?

Diese Fragen dürfen nicht zu einer einzigen „RAM-Adresse“ zusammengezogen werden.

Dass zwei Prozesse dieselbe virtuelle Adresse verwenden können, ist kein Widerspruch. Jeder Prozess besitzt einen eigenen virtuellen Adressraum und normalerweise eine eigene Seitentabellenstruktur. Die Adresse 0x7fff... kann in Prozess A auf einen anderen physischen Seitenrahmen zeigen als in Prozess B. Beim Kontextwechsel lädt das Betriebssystem beziehungsweise die Architektur die passende Übersetzungsbasis.

Für die Praxis bedeutet das:

• Ein Zeigerwert aus dem Debugger verrät noch nicht die RAM-Position.
• Eine physische Adresse verrät noch nicht die DRAM-Bank.
• Ein Cache-Miss bedeutet noch nicht automatisch, dass die Anwendung auf eine langsame DRAM-Zeile wartet.

Wie der TLB den häufigsten Übersetzungsweg abkürzt

Bei jedem Speicherzugriff wäre ein vollständiger Zugriff auf die Seitentabelle zu teuer. Deshalb besitzen moderne Prozessoren einen Translation Lookaside Buffer, kurz TLB. Er speichert bereits verwendete Übersetzungen virtueller Seiten auf physische Seitenrahmen.

Bei einem TLB-Treffer läuft der relevante Teil der Load-Anweisung vereinfacht so ab:

1. Die CPU berechnet die virtuelle Adresse aus Basis, Index und Offset.
2. Die MMU sucht die virtuelle Seitennummer im TLB.
3. Der TLB liefert die physische Seitennummer.
4. Der unveränderte Seitenoffset wird angehängt.
5. Daraus entsteht die physische Adresse für die nächste Zugriffsstufe.

Der Offset bleibt unverändert, weil die Seitentabelle Seiten und nicht einzelne Bytes übersetzt. Eine virtuelle Seite wird auf einen physischen Seitenrahmen abgebildet; die Position innerhalb dieser Seite bleibt gleich. Bei 4-KiB-Seiten sind das 4.096 Byte pro Seite. Linux nennt für x86 unter anderem 2-MiB- und 1-GiB-Seiten, die über höhere Seitentabellenebenen abgebildet werden können. Linux-Dokumentation zu Speicherverwaltung und Seitengrößen

Der TLB ist allerdings begrenzt. Ein Programm mit einem großen, ständig wechselnden Arbeitssatz kann Übersetzungen aus dem TLB verdrängen. Dann entstehen TLB-Misses, obwohl die eigentlichen Daten möglicherweise bereits im CPU-Cache liegen. Diese Unterscheidung ist für Performanceanalysen wichtig: Die Übersetzung kann langsam sein, während der Datentransfer schnell bleibt.

Für Sie als Entwickler folgt daraus eine klare Prüfreihenfolge:

• Sind die Speicherzugriffe räumlich lokal?
• Werden viele unterschiedliche Seiten in kurzer Zeit angesprochen?
• Sind große Seiten für den konkreten Workload sinnvoll?
• Entstehen die Verzögerungen im TLB, im Cache oder erst beim DRAM-Zugriff?

Große Seiten können den TLB-Druck senken, erhöhen aber den Verwaltungs- und Belegungsaufwand. Für bestimmte Workloads kann dadurch weniger Übersetzungsarbeit entstehen; bei kleinen oder unregelmäßig genutzten Datenstrukturen kann der größere Belegungsbereich jedoch unpraktisch sein.

Was bei einem TLB-Miss tatsächlich geschieht

Ein TLB-Miss ist zunächst kein Fehler der Anwendung. Er bedeutet nur, dass die benötigte Übersetzung nicht im TLB liegt. Die MMU startet dann einen Page Walk durch die mehrstufige Seitentabelle.

Die oberste Adresse der Seitentabelle steht nicht beliebig im Speicher. Die Architektur verwendet dafür ein spezielles Register beziehungsweise eine definierte Übersetzungsbasis. Bei x86 übernimmt diese Rolle im klassischen Paging-Modell das CR3-Register. Die CPU verwendet diese Basis, um die oberste Ebene der Seitentabelle zu erreichen.

Eine Seitentabelle besteht aus mehreren Ebenen. Die virtuelle Adresse wird in mehrere Indexbereiche und den Seitenoffset aufgeteilt. Die CPU verwendet den ersten Index, um einen Eintrag der obersten Ebene zu lesen, danach den nächsten Index für die folgende Ebene und so weiter, bis ein Eintrag den physischen Seitenrahmen beschreibt.

Ein Seitentabelleneintrag enthält mehr als nur eine Seitennummer. Typische Informationen sind:

• Gültigkeit oder Präsenz der Seite
• Schreibschutz
• Ausführbarkeit
• User- oder Kernel-Zugriffsrechte
• Statusbits wie „accessed“ oder „dirty“
• physische Seitennummer oder Rahmeninformation

Ist der Eintrag gültig und die Seite vorhanden, aktualisiert die MMU den TLB. Der aktuelle Zugriff kann anschließend mit der neu erzeugten Übersetzung fortgesetzt werden.

Anders sieht es bei einem Page Fault aus. Ein Page Fault kann auftreten, wenn:

• die Seite noch nicht physisch angelegt wurde,
• die Seite ausgelagert wurde,
• Copy-on-Write eine neue Zuordnung benötigt,
• der Zugriff gegen Berechtigungen verstößt,
• die Anwendung eine ungültige Adresse verwendet.

Der Begriff „Fault“ bedeutet daher nicht automatisch „Speicher defekt“. Ein erwarteter Demand-Paging-Fall kann vom Betriebssystem behoben werden. Ein Zugriffsfehler kann dagegen in einem Prozessabbruch enden. Für die Diagnose müssen Sie deshalb zwischen TLB-Miss und Page Fault unterscheiden: Der erste betrifft primär den Übersetzungscache, der zweite löst eine Betriebssystembehandlung aus.

Aus Sicherheitssicht ist diese Trennung ebenfalls wichtig. Betriebssysteme können Seitentabellen so verwalten, dass User- und Kernel-Bereiche stärker getrennt sind. Linux Page Table Isolation verwendet dafür getrennte beziehungsweise eingeschränkte Seitentabellenansichten, um bestimmte Angriffswege zu erschweren. Linux-Dokumentation zu Page Table Isolation

Warum die physische Adresse noch keinen DRAM-Ort beschreibt

Nach erfolgreicher Übersetzung liegt eine physische Adresse vor. Das ist die Adresse, die der Prozessor beziehungsweise der Speicherbus im physischen Adressraum verwendet. Sie ist aber noch keine direkte Beschreibung wie „Chip 2, Bank 3, Zeile 418“.

Der Grund ist der Speichercontroller. Er nimmt die physische Adresse und ordnet bestimmte Adressbestandteile verschiedenen Speicherkomponenten zu. Je nach Plattform können dazu gehören:

• Speicherkanal
• Rank oder Chip-Select
• Bankgruppe
• Bank
• Zeile
• Spalte
• Byte- oder Burst-Position

Die DRAM-Adresszuordnung ist deshalb eine weitere Verteilungsstufe. Herstellerdokumentationen zu Speichercontrollern zeigen, dass physische Adressbits auf Zeilen-, Bank- und Spaltenbits abgebildet werden können. Welche Zuordnung gilt, hängt jedoch von der konkreten Plattform ab. AMD-Dokumentation zur DRAM-Adresszuordnung

Daraus folgt die wichtigste Warnung dieses Artikels: Eine physische Adresse ist nicht gleichbedeutend mit einem konkreten RAM-Chip oder einer bestimmten DRAM-Zeile.

Ein Controller kann beispielsweise niedrige Adressbits für die Byteposition und Spaltenauswahl nutzen, mittlere Bits für Bank- oder Kanalinterleaving und höhere Bits für die Zeile. Ein anderer Controller kann diese Reihenfolge verändern. Auch Speicherbestückung, Rank-Struktur, Firmwareeinstellungen und Plattformgeneration können die Abbildung beeinflussen.

Ein festes Diagramm wie „Bit 6 bis 8 ist immer die Bank, Bit 12 bis 22 ist immer die Zeile“ ist deshalb ohne konkrete Plattformquelle nicht belastbar. Selbst offizielle SoC-Dokumentationen zeigen, dass einzelne DRAM-Adressbits über konfigurierbare Zuordnungen verschiedenen Busbits zugewiesen werden können. Dokumentation zur Zuordnung von Zeile, Bank und Spalte

Für eine belastbare Analyse benötigen Sie daher mindestens:

• das genaue Prozessor- und Plattformmodell,
• die Speicherbestückung und Rank-Struktur,
• die Firmware- oder Controllerkonfiguration,
• Informationen zur NUMA-Topologie,
• eine reproduzierbare Messmethode.

Ohne diese Angaben sollten Sie nur von einer allgemeinen DRAM-Adresszuordnung sprechen, nicht von einer sicher bekannten Bank- oder Zeilenposition.

Cache-Treffer, Cache-Miss und echte Speicherlatenz

Die physische Adresse wird nicht sofort an den DRAM weitergereicht. Vorher prüft die CPU ihre Cache-Hierarchie. Je nach Architektur existieren mehrere Cache-Stufen mit unterschiedlichen Größen, Latenzen, Assoziativitäten und gemeinsamen oder privaten Eigenschaften.

Für die Load-Anweisung ergeben sich dadurch drei verschiedene Fälle.

Fall 1: Die Daten liegen bereits im Cache

Dann kann die CPU die angeforderten Daten aus einer Cache-Stufe übernehmen. Der DRAM wird bei diesem Zugriff nicht angesprochen. Die Adresse muss trotzdem korrekt übersetzt werden, sofern der konkrete Cache und die Architektur die Übersetzung benötigen.

Fall 2: Die Übersetzung fehlt, die Daten liegen aber im Cache

Ein TLB-Miss und ein Cache-Treffer können zusammen auftreten. Die CPU muss zunächst die physische Zuordnung ermitteln, findet die Daten danach aber in einer Cache-Stufe. Die Verzögerung ist dann nicht mit einer vollständigen DRAM-Latenz gleichzusetzen.

Fall 3: TLB und Cache verfehlen

Dann muss die CPU nach dem Page Walk auch die nächste Speicherstufe anfordern. Erst wenn kein Cache die Daten liefert, wird der Speichercontroller aktiv und startet die DRAM-Transaktion.

Diese Fälle erklären, warum ein Speicherbenchmark nicht einfach „CPU gegen RAM“ misst. Er misst eine Kombination aus:

• Adressberechnung
• TLB-Verhalten
• Seitentabellenzugriff
• Cache-Hierarchie
• Prefetching
• Speichercontrollerplanung
• DRAM-Bank- und Zeilenstatus
• Parallelität anderer Kerne und Geräte

Für Performance- und Sicherheitsanalysen sind Cache und TLB getrennte Beobachtungsebenen. Ein Benchmark, der nur die Gesamtlatenz misst, zeigt Ihnen nicht automatisch, welche Ebene den Ausschlag gibt. Intel beschreibt Cache- und Übersetzungsstrukturen als mögliche mikroarchitektonische Ressourcen, aus denen sich indirekte Beobachtungen ableiten lassen. Intel-Leitfaden zu mikroarchitektonischen Nebenkanälen

Beim Linux-Betriebssystem kommt außerdem hinzu, dass Änderungen an Seitentabellen oder Speicherattributen TLB- und Cache-Verwaltung auslösen können. Linux dokumentiert verschiedene Wege, wie Übersetzungen gezielt oder umfassender invalidiert werden. Linux-Dokumentation zu Cache- und TLB-Invalidierung

Eine Load-Anweisung als vollständige Ablaufkette

Verfolgen Sie nun die Anweisung mov rax, [buffer] ohne die Ebenen zu vermischen:

1. Adressberechnung: Die CPU berechnet aus dem Registerinhalt und dem Displacement die virtuelle Adresse von buffer.
2. Adressraumprüfung: Die MMU verarbeitet die Adresse im Kontext des aktuell laufenden Prozesses.
3. TLB-Suche: Die virtuelle Seitennummer wird im TLB gesucht.
4. TLB-Treffer: Die physische Seitennummer wird gefunden; der Seitenoffset bleibt unverändert.
5. TLB-Fehler: Die MMU nutzt die Seitentabellenbasis und liest die mehrstufigen Einträge.
6. Berechtigungsprüfung: Die Einträge werden auf Präsenz, Schreibbarkeit, Ausführbarkeit und User-/Kernel-Rechte geprüft.
7. Page Fault: Ist die Seite nicht verfügbar oder unzulässig, übernimmt eine Betriebssystemroutine.
8. Cache-Prüfung: Mit der ermittelten Adresse wird geprüft, ob die Daten in einer Cache-Stufe liegen.
9. Cache-Treffer: Die Daten werden aus dem Cache in das Zielregister geladen.
10. Cache-Miss: Die Anfrage geht an den Speichercontroller.
11. DRAM-Zuordnung: Der Controller verteilt relevante Adressbestandteile auf Kanal, Rank, Bank, Zeile und Spalte.
12. Datenrückgabe: Die DRAM-Daten laufen zurück durch die Speicher- und Cache-Hierarchie zur CPU.

In einer virtuellen Maschine kann vor der tatsächlichen Host-Speicheradresse eine zweite Übersetzung liegen. Die Gast-CPU verwendet eine gastseitige virtuelle Adresse. Daraus entsteht zunächst eine gastseitige physische Adresse. Der Hypervisor beziehungsweise die Hardware für verschachtelte Seitentabellen übersetzt diese anschließend in eine hostseitige physische Adresse. Erst danach kann der Host-Speichercontroller die DRAM-Zuordnung vornehmen.

Das ist ein häufiger Grund, warum Messungen in einer VM nicht ohne Weiteres mit Messungen auf Bare Metal verglichen werden können. Zusätzlich beeinflussen vCPU-Zuordnung, Hypervisor-Planung und gemeinsam genutzte Cache-Ressourcen das Ergebnis.

Typische Fehlannahmen und die bessere Erklärung

„Der Programmzeiger zeigt auf die RAM-Adresse.“
Der Programmzeiger zeigt auf die nächste auszuführende virtuelle Adresse. Erst die MMU bildet sie auf einen physischen Seitenrahmen ab.

„Eine physische Adresse benennt den RAM-Chip.“
Sie benennt zunächst eine Position im physischen Adressraum. Der Speichercontroller entscheidet, wie diese Position auf die DRAM-Struktur verteilt wird.

„Ein TLB-Miss bedeutet, dass der RAM langsam ist.“
Ein TLB-Miss betrifft die Übersetzung. Die angeforderten Daten können danach noch im Cache liegen.

„Ein Cache-Miss führt immer direkt zu einer DRAM-Zeile.“
Vor dem DRAM-Zugriff können weitere Cache-Stufen, Prefetcher, Speicherwarteschlangen und Controllerentscheidungen beteiligt sein.

„Das Bitdiagramm einer Plattform gilt für alle CPUs.“
Das ist besonders riskant. DRAM-Adresszuordnungen sind implementierungs- und plattformabhängig. Verwenden Sie für Reverse Engineering, Rowhammer-Analysen oder Performance-Tuning nur dokumentierte oder reproduzierbar ermittelte Informationen.

Für sichere Experimente sollten Sie zuerst die Plattform eindeutig identifizieren. Notieren Sie CPU-Modell, Betriebssystem, Hypervisor, NUMA-Struktur und Speicherbestückung. Ohne diese Angaben lässt sich eine Beobachtung nur als allgemeines Verhalten, nicht als universelle Hardwareregel bewerten.

Welche Ebene verursacht die Verzögerung?

Die folgende Entscheidungstabelle hilft Ihnen, die Ursache einer auffälligen Load-Anweisung einzugrenzen:

Die Tabelle ist kein Ersatz für Messungen. Sie verhindert aber, dass Sie einen TLB-Miss vorschnell als DRAM-Problem oder eine physische Adresse als Chipposition interpretieren.

Für Systemdiagnosen sollten Sie die Umgebung reproduzierbar halten. Ein temporärer Entwicklungsrechner, wechselnde VM-Hosts oder unbekannte Speichercontroller können Messwerte verfälschen. Wenn Sie dafür eine entfernte Mac-Umgebung einsetzen, prüfen Sie neben der Rechenleistung auch Zugriffsrechte, Sitzungsstabilität und Datenschutz. Die Datenschutzinformationen von Kvmzen gehören deshalb ebenso in Ihre technische Abnahme wie CPU- und Speicherwerte. Für technische Fragen zu Zugriffsrechten, Sitzungsabläufen oder dokumentierten Testanforderungen können Sie die Kontaktinformationen von Kvmzen verwenden.

Was diese Adresskette für Performance und Sicherheit bedeutet

Für Performance Engineering ist die wichtigste Konsequenz die Ebenentrennung. Optimieren Sie nicht „den RAM“, wenn der eigentliche Engpass ein TLB-Druck durch ein ungünstiges Datenlayout ist. Umgekehrt hilft eine bessere Seitengröße wenig, wenn die Anwendung regelmäßig große Datenmengen aus dem DRAM nachladen muss.

Für die Sicherheit gilt eine ähnliche Regel. Virtuelle Adressen schützen Prozesse nicht allein; entscheidend sind Seitentabellenrechte, Kernelkonfiguration, Isolation und mikroarchitektonische Nebenkanäle. TLBs, Cache-Stufen und Seitentabellen-Caches können Informationen über Zugriffsverhalten preisgeben, obwohl die virtuelle Adresse selbst nicht direkt einer DRAM-Zelle entspricht.

Wenn Sie Rowhammer oder ähnliche Untersuchungen durchführen, benötigen Sie deshalb eine belastbare Plattformbeschreibung. Die Frage lautet nicht nur „Welche physische Adresse wurde angesprochen?“, sondern auch:

• Welche Speichercontrollerlogik ist aktiv?
• Welche Adressbits werden für Bank und Zeile verwendet?
• Gibt es Kanal- oder Rank-Interleaving?
• Welche ECC- und Refresh-Mechanismen greifen?
• Läuft der Test in einer VM oder direkt auf der Hardware?

Ohne diese Angaben bleibt jede Aussage über konkrete DRAM-Zeilen eine Hypothese.

Fazit: Die CPU findet Daten über eine Kette, nicht über einen direkten Draht

Wenn Sie die Frage „Wie findet die CPU Daten im RAM?“ beantworten müssen, verwenden Sie diese Kurzform: Die Load-Anweisung erzeugt eine virtuelle Adresse. Der TLB oder ein Page Walk liefert die physische Seitennummer. Der Cache entscheidet, ob DRAM überhaupt benötigt wird. Erst bei einem passenden Cache-Miss verarbeitet der Speichercontroller die physische Adresse und ordnet sie plattformabhängig Kanal, Rank, Bank, Zeile und Spalte zu.

Das aktuelle Entwicklungsmodell ist dafür oft die schwierigste Vergleichsbasis: Eine lokale Maschine zeigt Ihnen zwar direkte Messwerte, aber Hardware, Speicherbestückung und Betriebssystemzustand sind nicht immer reproduzierbar. Eine VM fügt eine zweite Adressübersetzung, zusätzliche Scheduling-Effekte und möglicherweise unbekannte NUMA-Eigenschaften hinzu. Wenn Sie dagegen nur kurzfristig eine kontrollierte Entwicklungs- oder Testumgebung brauchen, kann eine gemietete Mac-Umgebung sinnvoller sein als ein eigener Umbau — vorausgesetzt, Sie benötigen keine direkten physischen Schnittstellen und keinen dauerhaft gleichbleibenden Hochlastbetrieb.

Für den nächsten Schritt verbinden Sie die Architekturtheorie mit einer konkreten Umgebungs- und Datenschutzprüfung. So prüfen Sie nicht nur, wohin eine Adresse logisch zeigt, sondern auch, ob die Umgebung für Ihre Entwicklungs-, Performance- und Sicherheitsmessungen ausreichend stabil und nachvollziehbar ist.

Häufige Fragen zur Adressübersetzung

Wie wird eine virtuelle Adresse in eine physische Adresse umgewandelt?

Die CPU übergibt die virtuelle Adresse an die MMU. Zuerst sucht der Prozessor die Übersetzung im TLB. Bei einem Treffer liefert der Eintrag die physische Seitennummer, während der Offset innerhalb der Speicherseite unverändert bleibt. Bei einem TLB-Fehler folgt ein Page Walk durch die mehrstufige Seitentabelle. Erst danach entsteht die vollständige physische Adresse.

Was passiert nach einem TLB-Fehler?

Ein TLB-Fehler bedeutet zunächst nur, dass die Übersetzung nicht im kleinen Übersetzungscache vorhanden ist. Die Hardware liest dann die Seitentabelleneinträge ausgehend vom Architekturregister für die oberste Ebene. Ist der Eintrag gültig, wird der TLB ergänzt. Fehlt die Seite im physischen Speicher oder verletzt der Zugriff die Rechte, entsteht zusätzlich ein Page Fault.

Ist eine physische Adresse gleichbedeutend mit einem bestimmten RAM-Chip?

Nein. Eine physische Adresse beschreibt zunächst eine Position im physischen Adressraum des Systems. Der Speichercontroller kann verschiedene Adressbits zur Auswahl von Kanal, Rank, Bank, Zeile und Spalte verwenden. Diese Zuordnung ist vom Prozessor, Mainboard, Speichercontroller und Firmwaredesign abhängig. Ohne Plattformdokumentation lässt sich aus der Adresse kein bestimmter DRAM-Chip sicher ableiten.

Wie werden DRAM-Bank und Zeilenadresse bestimmt?

Der Speichercontroller zerlegt oder remappt Teile der physischen Adresse in DRAM-Signale. Welche Bits für Bank, Bankgruppe, Zeile und Spalte verwendet werden, ist nicht universell festgelegt. Controller können die Abbildung beim Initialisieren konfigurieren oder herstellerspezifische Regeln verwenden. Deshalb sind feste Bitdiagramme nur für eine konkret dokumentierte Plattform belastbar.

Häufig gestellte Fragen