Page‐Faults
Page‐Fault: die Page muss in eine freie Page im Speicher geladen werden. Was, wenn keine Page mehr frei ist?
Andere Page im Speicher muss ausgelagert werden. Mögliche Ersetzungsstrategie: LRU (siehe voriges Thema Caching).
Woher weiß man eigentlich, welche Page schon lange nicht mehr adressiert wurde?
Manche Prozessoren können die Page‐Table mit einem
Reference/Use‐Bit taggen. Den Rest muss das Betriebssystem übernehmen (mehr dazu in der Vorlesung Betriebssysteme)
Wie groß ist die Page‐Table?
Im vorigen (typischen) Beispiel verwenden wir 20 Bits zum
indizieren der Page‐Table. Typischerweise spendiert man 32 Bits pro Tabellen‐Zeile (im Vorigen Beispiel brauchten wir mindestens 18
Bits). Damit benötigen wir insgesamt:
Anzahl Page‐Table‐Einträge:
Größe der Page‐Table:
Wir benötigen so eine Page‐Table pro Prozess!
Noch gravierender ist es natürlich für 64‐Bit‐Adressen!
Größe der Page‐Table:
Techniken zur Reduktion der Page‐Table‐Größe
Page‐Table‐Größe ist limitiert durch ein spezielles Limit‐Register:
Adressen erst mal nur bis maximal dem Inhalt des Limit‐Registers erlaubt. Limit‐Register wird nur bei Bedarf (also überschreiten) erhöht. Sinnvoll, wenn Speicher nur in eine Richtung wächst.
Page‐Table ist in zwei Segmenten organisiert:
Beide Segmente wachsen wie vorhin beschrieben mittels eines Limit‐
Registers nur bei Bedarf. Ein Segment wird für den Stack verwendet und wächst von oben nach unten. Das andere Segment wird für den Heap verwendet und wächst von unten nach oben. Höchstes Adress‐
Bit bestimmt welches der beiden Segmente verwendet wird. (Also:
Speicher in zwei gleich große Teile unterteilt)
Techniken zur Reduktion der Page‐Table‐Größe
Invertierte Page‐Tables:
Es wird eine Hash‐Funktion auf die virtuelle Adresse angewendet.
Die Größe der Page‐Table entspricht der Anzahl Seiten im
physikalischen Speicher. Jeder Eintrag speichert die aktuellen High‐
Order‐Bits der Adressen zu den die aktuelle Page gehört.
Mehrere Level von Page‐Tables:
Oberster Level zeigt zunächst auf sehr große Blöcke (auch als
Segmente bezeichnet). Innerhalb eines Segments wird wiederum mittels Page‐Table feiner (dann als Pages bezeichnet) unterteilt.
Referenzieren einer Page: High‐Order‐Bits bestimmen das Segment (wenn vorhanden); die nächsten Bits dann die richtige Page in
diesem Segment. Nachteil dieses Verfahrens: Adress‐Translation ist aufwendiger.
Techniken zur Reduktion der Page‐Table‐Größe
Paged‐Page‐Tables:
Page‐Table befindet sich selber im virtuellen Speicher. Mögliche rekursive Page‐Faults müssen durch geeignete Betriebssystem‐
Mechanismen verhindert werden. (Keine weiteren Details hier)
Schreiben von Pages
Schreiben einer Page in den Swap‐Space ist sehr teuer (kostet millionen von CPU‐Zyklen).
Write‐Through‐Strategie (siehe Abschnitt über Caching) ist hier
somit nicht sinnvoll. Eine sinnvolle Strategie ist Write‐Back, d.h. nur, wenn die Seite von einer anderen in den Swap‐Space verdrängt
wird, wird diese auch in den Swap‐Space geschrieben.
Auch das ist immer noch gleich so teuer, kommt aber seltener vor.
Muss man eine verdrängte Seite eigentlich immer zurückschreiben?
Nur, wenn diese verändert wurde.
CPU muss bei jedem schreibenden Zugriff auf eine Page in der Page‐
Table ein Dirty‐Bit setzen.
Beobachtung für jeden Speicherzugriff
Bildquelle: David A. Patterson und John L. Hennessy, „Computer Organization and Design“, Fourth Edition, 2012
Virtueller Speicher ist aufwendiger als direkter physikalischer Zugriff
• Erst nachschlagen der Page im Speicher.
• Dann Zugriff auf den Speicher.
Wie kann man das soweit wie möglich beschleunigen?
Der Translation‐Lookaside‐Buffer (TLB)
Bildquelle: David A. Patterson und John L. Hennessy, „Computer Organization and Design“, Fourth Edition, 2012
Protection mittels virtuellem Speicher
Virtueller Speicher erlaubt, dass mehrere Prozesse auf denselben physikalischen Speicher zugreifen.
Es ist unter Umständen sinnvoll, den Speicherbereich vor Schreibzugriff zu schützen.
TLB und Page‐Table speichern ein extra RW‐Bit.
(1) Wer setzt dieses RW‐Bit? (2) Wie setzt man dieses Bit?
Zu (1): Ein Betriebssystem‐Prozess.
Zu (2): Einfache Maschineninstruktionen?
Problem: Jeder kann dann das Bit setzen.
Page
Prozess 1 Prozess 2
Betriebsmodi einer CPU
Häufig zwei unterschiedliche Betriebsmodi:
• Normaler Betriebsmodus
• Kernel‐ (oder auch Supervisor)‐Mode
CPU erlaubt die Ausführung bestimmter Maschinen‐Instruktionen nur im Kernel‐Mode.
Page‐Tables werden im physikalischen Speicher abgelegt, auf den kein anderer virtueller Adressraum zeigt.
Wie erreicht man den Kernel‐Mode? Es muss verhindert werden, dass jeder die CPU in diesen Modus versetzen kann.
Üblicher Weg: System‐Call.
Erinnerung: damit kann man eine Betriebssystemfunktion aufrufen.
Mit System‐Call wird eine Exception ausgelöst und an eine
Speicherstelle gesprungen, die nur in Kernel‐Mode zugreifbar ist.
Was passiert bei einem Page‐Fault noch?
Aktueller Prozess kann die Instruktion, die den Page‐Fault ausgelöst hat, nicht weiter ausführen.
Betriebssystem kann einem anderen Prozess die CPU zur Verfügung stellen.
Sobald die Page geladen ist, kann dem ursprünglichen Prozess die CPU wieder zur Verfügung gestellt werden.
Hierzu muss der ursprüngliche Prozesskontext wieder hergestellt werden; unter anderem natürlich der PC auf die Instruktion gesetzt werden, die den Page‐Fault verursacht hatte.
Segmentierung – Motivation
Bisher haben wir feste Blockgrößen betrachtet. Ziel: Paging stellt
dem Anwender einen großen (eindimensionalen) Speicher von 0 bis 2b‐1 (b = Bit‐Tiefe) bereit.
Annahme Programm benötigt mehrere Speicherbereiche deren Längen im Programmablauf variabel sind. Beispiel Compiler:
Für solche Anwendungsfälle ist es besser dem Anwender sichtbar mehrere unabhängige Speicherbereiche zur Verfügung zu stellen.
Symbol‐
tabelle
Source‐
Code
Kon‐
stanten
Parse‐
Tree Call‐Stack
0 … A … B … C … D … E … 2b‐1
Segmentierung ‐ Grundidee
Voriges Beispiel Compiler:
Dieses Konzept mit variablen Blockgrößen nenn man Segmentierung.
Im Gegensatz zu Paging: explizit sichtbare zweidimensionale Adressierung (n,k) mit Segment‐Nummer n und Segment‐Offset k
• Anfang kann auf einen beliebigen Startpunkt im Speicher zeigen.
• Die physikalische Adresse ergibt sich aus Anfang + Offset.
• Segmente können beliebig lang sein; benötigt auch „Bounds‐Check“.
Segmentierung ermöglicht auch einfaches Sharing von Code (und natürlich auch Daten) zwischen Prozessen. Alle können die gleiche Adresse (n,k) verwenden. Protection kann explizit erfolgen. [Paging: virtueller Adressbereich muss verfügbar sein; Protection implizit]
Symbol‐
Tabelle Source‐
Code
Kon‐
stanten
Parse‐
Tree Call‐
Stack
0K 4K 8K 12K 16K 20K 24K
0K 4K 8K 12K 16K
0K 4K
0K 4K 8K 12K 16K 20K
0K 4K 8K 12K
Implementierung über Segment‐Tabelle
Segment‐Nummer
(Selector) Offset
Basis‐Adresse Limit
Andere Felder (z.B.
Priviledge, Protection,…) Adressierung im virtuellen Addressraum
Eintrag in Segmenttabelle Segmenttabelle
+
N‐Bit lineare Adresse
Damit geeigneter Zugriff auf physikalischen Speicher
Segmentierung versus Paging
Paging Segmentierung
Für den Programmierer sichtbar Nein Ja
Anzahl verfügbarer linearer Adressbereiche
1 Viele
Mehr als der physikalische Speicherbereich verfügbar
Ja Ja
Trennung von Programm und Daten mit unterschiedlichem Protection möglich
Nein Ja
Unterstützung mehrerer
Speicherbereiche mit dynamischer Größe
Nein Ja
Unterstützung von Code‐Sharing Nein Ja
Motivation für die
Einführung/Verwendung
Bereitstellung eines großen Adressraumes bei limitiertem
physikalischem Speicher
Trennung von Programm und Daten in logische unabhängige
Adressbereiche.
Unterstützung von Sharing und Protection
Pure Segmentierung: Jedes Segment belegt ab einer Basisadresse einen aufeinander‐
folgenden physikalischen Speicherbereich. (z.B. Ausgangspunkt (a)) Mit der Zeit entsteht eine sog. externe Fragmentierung (z.B. (b), (c), (d)) Mögliche Lösung: Compactation (z.B. (e))
Problem mit purer Segmentierung
Segment 0 (4K) Segment 1
(8K) Segment 2
(5K) Segment 3
(8K) Segment 4
(7K)
Segment 0 (4K) Segment 7
(5K) Segment 2
(5K) Segment 3
(8K) Segment 4
(7K)
Segment 0 (4K) Segment 2
(5K) Segment 3
(8K) Segment 5
(4K)
(3K)
(3K)
Segment 7 (5K) (3K)
Segment 0 (4K) Segment 2
(5K) Segment 6
(4K) Segment 5
(4K) (3K)
Segment 7 (5K) (3K) (4K)
Segment 0 (4K) Segment 2
(5K) Segment 6
(4K) Segment 5
(4K) (10K)
Segment 7 (5K)
(a) (b) (c) (d) (e)
Lösung: Segmentierung mit Paging (1)
Beispiel Intel Pentium:
• Es gibt zwei Segment‐Tabellen (mit 8K+8K Einträgen)
• GDT (Global Descriptor Table) – eine globale Tabelle für alle Prozesse
• LDT (Local Descriptor Table) – für jeden Prozess eine individuelle Tabelle
• Es gibt 6 sog. Segment‐Register
(u.a. CS als Selector für Code und DS als Selector für Daten)
• Selector‐Format 16‐Bit
• Mittels Index: Zugriff auf Segment‐Descriptor in LDT oder GDT (Privilege‐Level gleich)
Index 0=GDT1=LDT Level (0‐3)Privilege‐
15 14 … 3 2 1 0
Lösung: Segmentierung mit Paging (2)
Beispiel Intel Pentium:
• Aufbau eines Segment‐Descriptors (8 Bytes)
• Base: 32‐Bit‐Basis‐Adresse des Segments (Format bzgl. Base und Limit ist Downward‐
Kompatibilität mit 24‐Bit‐Base des 286 geschuldet)
• (Privilege Level, Segement‐Type und Protection siehe gleich)
• Limit: mittels Granularity‐Bit entweder in Bytes (max. Segmentgröße 220=1MB) oder in 4K‐Pages (max. Segmentgröße 4K*220=4GB)
• Damit zunächst also: Zugriff auf physikalischen Speicher mittels Basis‐Adresse plus Offset (Segemente dürfen sogar überlappen)
• Wo ist denn Paging als Lösung angewendet???
Bildquelle: Andrew S. Tanenbaum, „Modern Operating Systems“, Second Edition, 2001
Lösung: Segmentierung mit Paging (3)
Beispiel Intel Pentium:
• Bit in globalem Control‐Register kann man Paging dazuschalten
• Lineare Adresse wird dann nicht direkt als physikalische Adresse verwendet
• Stattdessen wird die Adresse als virtuelle Adresse des Pagings verwendet
• Virtuelle 32‐Bit‐Adresse: es wird zweistufiges Paging verwendet
• Bemerkung: Pentium verwendet selbstverständlich TLB zwecks Performancesteigerung
• Bemerkung: Pentium erlaubt auch nur Paging ohne Segmentierung (setze alle
Segmentregister auf denselben Segment‐Selector, Descriptor Base=0 und Limit=max)
Dir Page Offset
Lineare Adresse
Bildquelle: Andrew S. Tanenbaum, „Modern Operating Systems“, Second Edition, 2001
Zum Abschluss: Protection
Beispiel Intel Pentium:
• Vier Protection Level (0 bis 3; Level 0 hat höchste Privilegien)
• Zu jedem Zeitpunkt befindet sich ein Programm in einem der Level
• Jedes Segment ist ebenfalls einem Level zugeordnet.
• Unmittelbarer Zugriff auf Segment nur aus gleichem Level oder aus Level mit höheren Privilegien möglich; ansonsten Trap/Exception!
• Aufruf von Prozeduren ist aber auf kontrollierte Weise über call‐Instruktion möglich
• call verwendet anstatt Adresse einen Segment‐Selector
• Dieser beschreibt einen sogenannten call‐Gate (welcher die Aufrufadresse festlegt)
• Damit Sprung an beliebige Stelle nicht möglich; nur offizielle Eintrittspunkte können verwendet werden
• Typisches Beispiel (siehe Grafik)
• Type‐Feld wird zur Unterscheidung
zwischen Code‐Segment, Daten‐Segment und verschiedene Typen von Gates
verwendet
Bildquelle: Andrew S. Tanenbaum, „Modern Operating Systems“, Second Edition, 2001
Parallelität und Caches
Cache‐Kohärenz‐Problem
CPU 1 (oder Core 1) Cache
CPU 2 (oder Core 2) Cache
Speicher
Zeitschritt Event Cache‐Inhalt für CPU A
Cache‐Inhalt für CPU B
Speicherinhalt für Adresse X
0 0
1 CPU 1 liest X 0 0
2 CPU 2 liest X 0 0 0
3 CPU 1 speichert 1 nach X
1 0 1
Wann gilt ein Cache als kohärent?
1. Lesen von Speicherstelle X nach schreiben in Speicherstelle X sollte den geschriebenen Wert zurück geben, wenn kein
weiterer Prozess auf die Stelle X geschrieben hat.
2. Nachdem ein Prozess in Speicherstelle X geschrieben hat, sollte
„nach einer gewissen Zeit“ jeder Prozess den geschriebenen Wert in X vorfinden.
3. Zwei Schreiboperationen von zwei Prozessen in die
Speicherstelle X sollte von jedem Prozess in der gleichen Reihenfolge gesehen werden. (Schreiben ist serialisiert)
Wie erreicht man Kohärenz?
Write‐Invalidate‐Protokoll: Wenn ein Prozess in einen Speicherstelle schreibt wird die Speicherstelle in den Caches aller anderen Prozesse invalidiert.
Wie wird das Invalidieren technisch erreicht? Snooping: Jeder Cache‐Controller überwacht den gemeinsamen Bus, ob auf einen eigenen gecachten Inhalt
geschrieben wird.
Prozessor‐
aktivität
Busaktivität Inhalt des Caches von CPU A
Inhalt des Caches von CPU B
Speicher‐
inhalt für X 0
CPU A liest X Cache‐Miss für X 0 0
CPU B liest X Cache‐Miss für X 0 0 0
CPU A schreibt 1 nach X
Cache‐
Invalidierung für X
1 1
CPU B liest X Cache‐Miss für X 1 1 1