Betriebssysteme

Speicher
Betriebssysteme
Hermann Härtig
TU Dresden
Aufgaben der Speicherverwaltung
!
!
Bereitstellung von Adressräumen
Aufbau von Adressräumen durch Zuordnung logischer
Objekte
!
Verwaltung des Betriebsmittels Hauptspeicher
!
Schutzmechanismen
!
Organisation gemeinsamer Nutzung („Sharing“)
physischen Speichers und logischer Objekte
Betriebssysteme WS 2014, Speicher
2
Hermann Härtig, TU Dresden
Wegweiser
Einführung
Elementare Techniken
Virtueller Speicher (Paging)
!
!
!
!
Anliegen - Begriffe - Vorgehen
Adressumsetzung
Seitenersetzung
Arbeitsmengenmodell
Ergänzungen
!
!
Betriebssysteme WS 2014, Speicher
Segmentierung
Caches
3
Hermann Härtig, TU Dresden
Statisch
!
➔
‣
‣
!
!
Statische Speicherverwaltung
d. h. keine Ein-/Auslagerung von Programmen/Daten
Einfachrechner (MS-DOS Version ??)
Gerätesteuerungen (embedded systems)
Monoprogramming (ein Programm gleichzeitig)
Programme werden nacheinander geladen und
ausgeführt
0xFF..
BIOS (Gerätetreiber)
Benutzerprogramm
0x0
Betriebssysteme WS 2014, Speicher
BS
4
Hermann Härtig, TU Dresden
„Multiprogramming“
Mehrere Benutzer-Programme gleichzeitig im Rechner; für
jedes Benutzerprogramm gibt es einen oder mehrere
Prozesse
Motivation (vgl. Kapitel zu Threads):
• mehrere Benutzer eines Rechners (multiuser)
• mehrere Benutzerprozesse eines Benutzers
• Benutzerprozesse und Systemprozesse
Multiprogramming vs. parallele Threads/Prozesse:
• parallele Prozesse Voraussetzung für Multiprogramming (mit oder ohne erzwungenen Prozesswechel)
• denkbar ist Monoprogramming mit vielen parallelen
Prozessen
z. B.: die ersten BS für Parallelrechner erlaubten nur ein
Benutzerprogramm zur gleichen Zeit, das aber aus vielen Prozessen/Threads bestehen konnte
Betriebssysteme WS 2014, Speicher
5
Hermann Härtig, TU Dresden
Feste oder Variable Speicher-Partitionierung
Fragestellungen
!
Programm4
Relokation
Programme verwenden unterschiedliche Adressen, wenn sie in
unterschiedlichen Partitionen
ablaufen
➔
Abhilfe: Umsetzen der Adressen
‣ beim/vor dem Laden (Software)
‣ zur Laufzeit (Hardware)
!
Schutz der Partitionen voreinander
Abhilfe:
‣ Überprüfung der Adressen zur
Laufzeit (Hardware)
➔
Betriebssysteme WS 2014, Speicher
leer
Programm2
leer
Programm1
Betriebssystem
Limitationen
• Menge und Größe der
Programme durch Real-Speicher
• Auslastung
6
Hermann Härtig, TU Dresden
Einfaches Modell: Basis- und Limit-Register
CPU
Programm4
LR
leer
BR
Programm2
leer
gesamte Adressierung relativ
zu Basis-Register
z. B.:
load R, 100
Zugriff auf: BR+100
!
Programm1
Betriebssystem
Unterbindung aller Zugriffe auf Bereiche außerhalb [BR,LR]
!
➔
Konsequenz für Implementierung eines Prozess-Systems:
bei Umschaltung müssen auch BR und LR umgeschaltet
werden
Betriebssysteme WS 2014, Speicher
7
Hermann Härtig, TU Dresden
Wachsen von Partitionen
B
B
A
A
Algorithmen zur „Minimierung“ des Verschnitts
!
First fit, Best fit, Buddy, ...
Verwaltung
!
Bitmaps, Listen
Betriebssysteme WS 2014, Speicher
8
Hermann Härtig, TU Dresden
Swapping: Ein-/Auslagern ganzer Prozesse
Vorgehen
Partitionen von blockierten Prozessen werden auf
persistenten Speicher ausgelagert (z. B. auf Platte) und bei
Gelegenheit wieder eingelagert.
Mehrebenen-Scheduling
auch bereite Prozesse werden ausgelagert
Fragestellungen
• wachsende Partitionen
• Speicherverschnitt (externe Fragmentierung)
Betriebssysteme WS 2014, Speicher
9
Hermann Härtig, TU Dresden
Partitionen: Nachteile und Probleme
!
Verschnitt hoch
!
Programmstartzeiten
!
!
!
Limitation der Größe eines Prozesses durch verfügbaren Hauptspeicher
Ein-/Auslagerungszeit
„ruhende“ Teile
Platzbedarf auf Externspeicher
Betriebssysteme WS 2014, Speicher
10
Hermann Härtig, TU Dresden
Overlays − Überlagerungstechnik
Beliebig große Programme → „Overlays“
Programmierer organisiert seine Programme und Daten in
Stücken, von denen nicht zwei gleichzeitig im Hauptspeicher
sein müssen
Hauptspeicher
Hauptprogramm
Overlaytabelle
Overlay1
Overlay2
Overlay3
Betriebssysteme WS 2014, Speicher
11
Hermann Härtig, TU Dresden
Wegweiser: Virtueller Speicher
Anliegen – Begriffe - Vorgehen
Adressumsetzung
Seitenersetzung
Arbeitsmengenmodell
Betriebssysteme WS 2014, Speicher
12
Hermann Härtig, TU Dresden
Adressraum: Virtuell ./. Physisch
Begriff allgemein
!
Menge direkt zugreifbarer Adressen und deren Inhalte
!
Größe bestimmt durch Rechner-Architektur
Physischer Adressraum (manchmal auch “Realer AR”):
!
durch Adressleitungen gebildeter AR, z. B. am Speicher- oder Peripherie-bus eines Rechners
!
Abbildung der Prozessor-Adressen auf die vorhandenen
Speicherbausteine und E/A-Controller
!
Adressumsetzung statisch durch HW-Adressdecoder
Virtueller (logischer) Adressraum eines Prozesses
!
dem Prozess zugeordneter Adressraum
!
Adressumsetzung durch MMU, veränderliche Abbildungsvorschrift
Betriebssysteme WS 2014, Speicher
13
Hermann Härtig, TU Dresden
Physische Adressräume
CPU
Bridge
I/O
I/O
MEM
Betriebssysteme WS 2014, Speicher
14
Hermann Härtig, TU Dresden
Beispiele für die Nutzung virtueller Adressräume
Unix-Prozesse (konventionell)
Programm Daten
➔
➔
Keller BS
Logisch zusammenhängende Adressbereiche
nennen wir Regionen
Speicherobjekte werden Regionen zugeordnet
(„Mapping“)
Betriebssysteme WS 2014, Speicher
15
Hermann Härtig, TU Dresden
Virtueller Speicher
Wünsche an Adressräume und ihre Implementierung
!
groß (soweit die Hardware zulässt, z. B. jeder bis zu 4 GB)
!
frei teilbar und nutzbar
!
Fehlermeldung bei Zugriff auf nicht belegte Bereiche
!
Schutz vor Zugriffen auf andere Adressräume
!
Einschränken der Zugriffsrechte auf bestimmte Bereiche
(z. B. Code nur lesen)
!
sinnvoller Einsatz des (Haupt-)Speichers
‣ damit Speicher anderweitig nutzbar
‣ wegen kurzer Ladezeiten
‣ ohne großen Aufwand für Programmierer
Betriebssysteme WS 2014, Speicher
16
Hermann Härtig, TU Dresden
Prinzipien der virtuellen Speichers
Idee
Zuordnen von Speicherobjekten (z. B. Segmente, Dateien,
Datenbanken, Bildwiederholspeicher) bzw. Ausschnitten
davon zu Regionen von Adressräumen
Basis: Partitionierung
• des Adressraums in Seiten (Pages)
• der Hauptspeichers in Kacheln
(auch Rahmen oder Page Frames genannt)
• des Hintergrundspeichers in Blöcke (Blocks)
in Stücke gleicher Größe
➔
Organisation der Zuordnung der Stücke zueinander durch
Hardware und Betriebssystem
Betriebssysteme WS 2014, Speicher
17
Hermann Härtig, TU Dresden
Voraussetzung: Lokalitätsprinzip
Beobachtung
Der von einem Prozess innerhalb eines bestimmten
Zeitintervalls benötigte Teil seines Adressraumes verändert
sich nur mehr oder weniger langsam.
Ursachen
• sequentielle Arbeit eines VON-NEUMANN-Rechners
• Programmcode enthält Schleifen
• Programmierung in Modulen
• Zugriff auf gruppierte Daten
Betriebssysteme WS 2014, Speicher
18
Hermann Härtig, TU Dresden
Virtueller Speicher − Begriff
Der virtuelle Speicher ist eine Technik, die jedem Prozess
einen eigenen, vom physischen Hauptspeicher
unabhängigen logischen Adressraum bereitstellt,
basierend auf
!
einer Partitionierung von Adressräumen in Einheiten
einheitlicher Größe
!
einer Adressumsetzung durch Hardware (und
Betriebssystem)
!
der Nutzung eines externen Speichermediums
!
einer Ein- und Auslagerung von Teilen des logischen
Adressraumes eines Prozesses durch Betriebssystem
Betriebssysteme WS 2014, Speicher
19
Hermann Härtig, TU Dresden
Eine denkbare Situation
Programm
Daten
BSS
Keller BS
unbenutzt, ungültig
gerade im Hauptspeicher
gerade nicht im Hauptspeicher, aber ein
gültiger Bereich – z. B. ausgelagert auf Platte
Betriebssysteme WS 2014, Speicher
20
Hermann Härtig, TU Dresden
Virtueller Speicher im Betriebssystem
Teilaufgaben
• Seitenfehler-Behandlung
• Verwaltung des Betriebsmittels Hauptspeicher
• Aufbau der Adressraumstruktur (Speicherobjekte und Regionen)
• Bereitstellung spezifischer Speicherobjekte
• Interaktion Prozess- und Speicher-Verwaltung
Betriebssysteme WS 2014, Speicher
21
Hermann Härtig, TU Dresden
Wegweiser: Virtueller Speicher
Anliegen – Begriffe - Vorgehen
Adressumsetzung
Seitenersetzung
Arbeitsmengenmodell
Betriebssysteme WS 2014, Speicher
22
Hermann Härtig, TU Dresden
Seiten, Kacheln, Blöcke
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Hauptspeicher
z. B. 4 GB
Betriebssysteme WS 2014, Speicher
BS
Software
Plattenspeicher
z. B. 500 GB
23
Hermann Härtig, TU Dresden
Rechnerarchitektur: Addressumsetzung etc.
CPU
E/AGeräte
V virtuelle Adresse
MMU
MEM
IO MMU
P physische Adresse
Aufgaben einer MMU (Memory Management Unit)
!
Abbildung: virtuelle → physische Adresse
!
Schutz bestimmter Bereiche (lesen/schreiben)
!
Betriebssystemaufruf bei abwesenden/geschützten Seiten
→ Seitenfehler (page fault)
!
Schutz der Adressräume untereinander
Betriebssysteme WS 2014, Speicher
24
Hermann Härtig, TU Dresden
Prinzipielle Arbeitsweise MMU (Tanenbaum)
V 001010010110
physische Adresse
P
Betriebssysteme WS 2014, Speicher
virtuelle Adresse
25
Hermann Härtig, TU Dresden
Prinzipielle Arbeitsweise einer MMU
CPU
T4
V 001010010110
Seiten#
Offset
Seitentabelle
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Kachel# Present Rechte
010
1
0
001
1
0
110
1
0
000
1
0
100
1
1
011
1
1
000
0
1
000
0
1
000
0
1
101
1
1
000
0
1
111
1
1
000
0
1
000
0
1
000
0
1
000
0
1
virtuelle Adresse
Zeiger
physische Adresse
P
Betriebssysteme WS 2014, Speicher
26
Hermann Härtig, TU Dresden
Prinzipielle Arbeitsweise einer MMU
CPU
T4
V 001010010110
Seiten#
Offset
Seitentabelle
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Kachel# Present Rechte
010
1
0
001
1
0
110
1
0
000
1
0
100
1
1
011
1
1
000
0
1
000
0
1
000
0
1
101
1
1
000
0
1
111
1
1
000
0
1
000
0
1
000
0
1
000
0
1
virtuelle Adresse
Zeiger
Tabellenindex
110
physische Adresse
P
Betriebssysteme WS 2014, Speicher
27
Hermann Härtig, TU Dresden
Prinzipielle Arbeitsweise einer MMU
CPU
T4
V 001010010110
Seiten#
Offset
Seitentabelle
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Kachel# Present Rechte
010
1
0
001
1
0
110
1
0
000
1
0
100
1
1
011
1
1
000
0
1
000
0
1
000
0
1
101
1
1
000
0
1
111
1
1
000
0
1
000
0
1
000
0
1
000
0
1
virtuelle Adresse
Zeiger
Tabellenindex
110
Kopie
Kachel#
Offset
P 1 1 0 1 0 0 1 0 1 1 0 physische Adresse
Betriebssysteme WS 2014, Speicher
28
Hermann Härtig, TU Dresden
Aufbau eines Seitentabelleneintrags
caching disabled modified present
page frame number
referenced
protection
Seiten-Attribute
!
present
Seite befindet sich im Hauptspeicher
!
modified
schreibender Zugriff ist erfolgt („dirty“)
!
referenced irgendein Zugriff ist erfolgt
!
caching
ein/aus (z. B. wegen E/A)
!
protection erlaubte Art von Zugriffen in Abhängigkeit von CPU-Modus
Betriebssysteme WS 2014, Speicher
29
Hermann Härtig, TU Dresden
Virtueller Speicher: Hardware-Anteil
➔
Bei jedem Speicherzugriff: Überprüfung von Präsenz und Rechten
Ablauf eines Seitenfehlers (exception):
• Zurücksetzen des auslösenden Befehls
• Umschaltung des Prozessormodus und des Kellers
• Ablegen einer Beschreibung des Zustandes, der
auslösenden Adresse und der Zugriffsart auf dem Keller
• Sprung in den Kern
→ Seitenfehlerbehandlung durch Betriebssystem
• iret (letzte Instruktion des Handlers)
Betriebssysteme WS 2014, Speicher
30
Hermann Härtig, TU Dresden
Beispiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
MMU
Hardware
SI
CX: 4096
LDS
LES
MOV
REP
Hauptspeicher
z. B. 512 MB
Betriebssysteme WS 2014, Speicher
DI
31
SI, [Adr. 1]
DI, [Adr. 2]
CX, Length
MOVSB
Hermann Härtig, TU Dresden
MMU-Probleme: Größe und Geschwindigkeit
Problem 1: Größe – ein Beispiel
Realspeicher :
256 MB
virtuelle Adressen:
32 Bit
Seitengröße:
4 KB
Aufteilung virt. Adr.: 20 Bit Index in der Seitentabelle
12 Bit innerhalb einer Seite (Offset)
➔
➔
Größe der Seitentabelle für einen Adressraum:
220 *4B → 4 MB
Bei 32 Prozessen 4*32 MB für die Seitentabellen !
Problem 2: Geschwindigkeit der Abbildung – ein Beispiel
CPU-Takt :
1 GHz → 2 Instruktionen in 1ns
(4 Speicherzugriffe)
Speichertakt:
256 MHz → 4ns ( ... 70ns)
Betriebssysteme WS 2014, Speicher
32
Hermann Härtig, TU Dresden
Problem 1: Baumstrukturierte Seitentabellen
CPU
T7
V PageDirIdx
Seitennummer
PageTableIdx
P
Kachelnummer
Zeiger
Betriebssysteme WS 2014, Speicher
Tabellenindex
33
Offset
Offset
Kopie
Hermann Härtig, TU Dresden
Eigenschaften baumstrukturierter Seitentab.
●
●
●
●
●
beliebig schachtelbar
→ 64-Bit-Adressräume!
Seitentabellen nur bei Bedarf im Hauptspeicher
bei Zugriff auf Seitentabelle kann Seitenfehler auftreten
Zugriff auf Hauptspeicher wird noch langsamer
2 oder mehr Umsetzungsstufen
Hierarchiebildung möglich (nächste Folie)
z. B. durch Schreibsperre in höherstufiger Tabelle ist
ganzer Adressbereich gegen Schreiben schützbar
Gemeinsame Nutzung („Sharing“)
Seiten und größere Bereiche in mehreren Adressräumen
gleichzeitig
Betriebssysteme WS 2014, Speicher
34
Hermann Härtig, TU Dresden
Hierchiebildung baumstrukturierte Seitentab.
CPU
T7
V PageDirIdx
PageTableIdx
Schreibschutz
sperrt eine
einzelne Seite
Schreibschutz
sperrt gesamten
durch eine
Untertabelle
definierten Bereich
P
Kachelnummer
Zeiger
Betriebssysteme WS 2014, Speicher
Offset
Tabellenindex
35
Offset
Kopie
Hermann Härtig, TU Dresden
Problem 2: Schnellere Abbildung
CPU
TLB
V virtuelle Adresse
V
P
1100
0110
1110
0001
1001
1000
MMU
P physische Adresse
0000
1101
1100
0010
0110
1101
MEM
Translation Look Aside Buffer (TLB)
!
!
schneller Speicher für schon ermittelte Abbildungen
virtueller auf physische Adressen
wird vor Durchsuchen der Seitentabellen inspiziert
Betriebssysteme WS 2014, Speicher
36
Hermann Härtig, TU Dresden
Per SW implementierte Seitentabellen
z. B. Alpha
!
Zugriff nur über TLB, bei TLB-Fehler („TLB-miss“) →
Seitenfehler
!
Seitenfehlerbehandlung in SW lädt TLB neu
➔
Vorteil:
total flexibel
➔
Nachteil:
häufigere SW-Seitenfehlerbehandlung
Betriebssysteme WS 2014, Speicher
37
Hermann Härtig, TU Dresden
Nochmal Problem 1
Problem: riesige Seitentabellen auch bei
baumorientierten Seitentabellen
●
bei CPU mit großen Adressräumen (64-Bit-Adressen)
●
bei lose besetzten Adressräumen
●
V
CPU
P
T7
Betriebssysteme WS 2014, Speicher
38
Hermann Härtig, TU Dresden
Seitentabellen
Adressräume
Seite
Kachel / Rahmen
MMU
Hardware
Hauptspeicher
Betriebssysteme WS 2014, Speicher
39
Hermann Härtig, TU Dresden
Inverse Seitentabellen (Hashtabelle )
Adressräume
Seite
Kachel / Rahmen
MMU
Hardware
Hauptspeicher
Betriebssysteme WS 2014, Speicher
Zu jeder Kachel wird
gespeichert, welches virtuelle
Adresse sie gerade enthält.
Bei Zugriff auf virtuelle Adresse
muss die Tabelle durchsucht
werden um herauszufinden, in
welcher Kachel die Seite steht.
40
Hermann Härtig, TU Dresden
Vergleich der zwei Konzepte
Seiten-Kachel-Tabelle
Kachel-Seiten-Tabelle
Seiten#
0
1
2
3
4
5
6
7
8
Seiten#
Rahmen# Attribs
0001
0000
1001
0110
0111
1100
1101
0110
0010
...
Betriebssysteme WS 2014, Speicher
0
1
2
3
4
5
6
7
8
41
PID
1
1
1
2
7
1
1
2
Seiten# Attribs
0001
0000
1000
1000
0001
0000
!
0100
0010
...
Hermann Härtig, TU Dresden
Inverse Seitentabelle
Grundidee
!
zu jeder Kachel wird Prozess-Id, Seitennummer geführt
!
bei Zugriff („TLB-miss“) wird gesucht
Implementierung als Hash-Tabellen (Hashed Page Tables)
!
!
Vorteile:
‣ kleine Seitentabellen
‣ abhängig von Anzahl Kacheln
unabhängig von Größe des Adressraums
Nachteile:
‣ keine Hierarchiebildung (z. B. Schreibschutz für 4 MB)
‣ Sharing aufwändig
‣ Suchaufwand
Betriebssysteme WS 2014, Speicher
42
Hermann Härtig, TU Dresden
Überlappende Adressräume - „Sharing“
Seite
Kachel / Rahmen
Block
MMU
Hardware
Betriebssysteme WS 2014, Speicher
BS
Software
43
Hermann Härtig, TU Dresden
Sharing bei mehrstufigen Seitentabellen
identische
Inhalte der
Seitentabellen
Betriebssysteme WS 2014, Speicher
44
Hermann Härtig, TU Dresden
Sharing bei mehrstufigen Seitentabellen
Betriebssysteme WS 2014, Speicher
45
Hermann Härtig, TU Dresden
Spezieller Einsatz von Sharing
Verzögertes Kopieren (lazy copying, copy on write)
●
●
„Kopieren“:
●
Eintragen des zu kopierenden Bereichs an Zieladresse
●
beide gegen Schreiben schützen
„faules“ Kopieren:
●
beim ersten schreibenden Zugriff → Seitenfehler
●
Behandlung:
●
neue Kachel allokieren
●
physisch kopieren
●
neue Kachel ohne Schreibschutz in Seitentabelle
eintragen
●
sehr wichtig für effiziente Botschaften, Rücksetzpunkte etc.
●
gemeinsame Nutzung von Daten/Programmen
Betriebssysteme WS 2014, Speicher
46
Hermann Härtig, TU Dresden
Gemeinsames Nutzen von Daten
share
A
X
A
#
2
Attrib
p, rw
Y
Z
#
Attrib
2
p, rw
!
neuen MMU Eintrag an
Zieladresse
X
A
Z
Betriebssysteme WS 2014, Speicher
47
Hermann Härtig, TU Dresden
Echtes Kopieren
copy
A
X
Z
A
#
Attrib
p, rw
22 p, rw
#
!
neue Kachel besorgen
!
Kacheln kopieren
Attrib
!
5
p, rw
neuen Eintrag in die
Seitentabelle für Zieladresse
copy
Y
X A
A
Z
Betriebssysteme WS 2014, Speicher
48
Hermann Härtig, TU Dresden
Verzögertes Kopieren
lazy copy
A
X
A
#
2
Attrib
p,p,
r, cow
rw
Y
Z
#
Attrib
2
p, r, cow
!
!
Ändern des MMU-Eintrags an
der Quelladresse: rw → (r, cow)
neuen MMU-Eintrag an
Zieladresse: (r, cow)
X
A
Z
Betriebssysteme WS 2014, Speicher
49
Hermann Härtig, TU Dresden
Verzögertes Kopieren
write
A
X
A
#
2
Attrib
p, r, cow
Y
Z
#
Attrib
2
p, r, cow
!
schreibender Zugriff →
Seitenfehler
X
A
Z
Betriebssysteme WS 2014, Speicher
50
Hermann Härtig, TU Dresden
Verzögertes Kopieren
write
A
X
A
#
2
Attrib
p, r, cow
Z
#
Attrib
5
p, rw
!
!
!
schreibender Zugriff →
Seitenfehler
Das cow-Attribut bewirkt, dass
eine neue Kachel allokiert und
der Inhalt physisch kopiert wird
neuen MMU-Eintrag an
Zieladresse: rw
copy
Y
X A
A
Z
Betriebssysteme WS 2014, Speicher
51
Hermann Härtig, TU Dresden
Verzögertes Kopieren
write
A
X
B
#
2
Attrib
p, r, cow
Z
#
Attrib
5
p, rw
!
!
!
!
Y
X B
A
schreibender Zugriff →
Seitenfehler
Das cow-Attribut bewirkt, dass
eine neue Kachel allokiert und
der Inhalt physisch kopiert wird
neuen MMU-Eintrag an
Zieladresse: rw
danach erfolgt der
Schreibzugriff
Z
Betriebssysteme WS 2014, Speicher
52
Hermann Härtig, TU Dresden
Verzögertes Kopieren
write
A
X
B
#
2
Attrib
p, r, cow
Y
Z
#
Attrib
5
p, rw
!
➔
schreibender Zugriff →
Seitenfehler
ist der Prozess der alleinige
Besitzer der Kachel, wird lediglich
das Schreibrecht gesetzt
X B
A
Z
Betriebssysteme WS 2014, Speicher
53
Hermann Härtig, TU Dresden
Verzögertes Kopieren
write
C
X
B
#
2
Attrib
p, rw
Z
#
Attrib
5
p, rw
!
➔
!
Y
schreibender Zugriff →
Seitenfehler
ist der Prozess der alleinige
Besitzer der Kachel, wird lediglich
das Schreibrecht gesetzt
danach erfolgt der Schreibzugriff
X B
C
Z
Betriebssysteme WS 2014, Speicher
54
Hermann Härtig, TU Dresden
Verzögertes Kopieren großer Bereiche
lazy copy
Betriebssysteme WS 2014, Speicher
55
Hermann Härtig, TU Dresden
Verzögertes Kopieren großer Bereiche
cow
Betriebssysteme WS 2014, Speicher
cow
56
Hermann Härtig, TU Dresden
Verzögertes Kopieren großer Bereiche
cow
cow
cow
cow
cow
cow
Betriebssysteme WS 2014, Speicher
57
Hermann Härtig, TU Dresden
Verzögertes Kopieren großer Bereiche
cow
cow
r
cow
cow
Betriebssysteme WS 2014, Speicher
cow
58
Hermann Härtig, TU Dresden
Sharing und inverse Seitentabellen
Adressräume
Seite
Kachel / Rahmen
MMU
Hardware
schwierig, wenn nur eine
virtuelle Adresse pro Kachel
Hauptspeicher
Betriebssysteme WS 2014, Speicher
59
Hermann Härtig, TU Dresden
MMU-Ansteuerung: einige wichtige Details
Aufgaben
●
●
●
Manipulation und Interpretation der MMU-Daten
Atomare Operationen:
●
Eintrag einer Seite in einen Adressraum
●
Verdrängung einer Seite aus einem oder mehreren
Adressräumen
Propagieren von Attributen
Betriebssysteme WS 2014, Speicher
60
Hermann Härtig, TU Dresden
Propagieren von Attributen
!
!
➔
Kacheln können mehreren
Seiten mehrerer Adressräume
zugeordnet sein
Attribute used, modified
werden durch Hardware für
Seiten (nicht Kacheln) gesetzt
notwendig:
!
Propagation der Attribute
von Seiten zu Kacheln
!
Rückkehrabbildung:
welchen Seiten ist eine
gegebene Kachel
zugeordnet
!
!
➔
Betriebssysteme WS 2014, Speicher
61
Seite in Adressraum A:
used, not modified
Seite in Adressraum B:
not used, modified
Kachel:
used, modified
Hermann Härtig, TU Dresden
Propagation der Seitenattribute
R M
R M
OR
R M
Betriebssysteme WS 2014, Speicher
62
Hermann Härtig, TU Dresden
Umkehrabbildung: Kacheln zu Adressraum
●
●
●
für Attributpropagation
bei Verdrängung einer Kachel:
●
Auffinden der Seitentabellen, aus denen Kachel
ausgetragen werden muss
Später:
●
Identifizierung des Speicherobjektes, damit Inhalt
weggeschafft werden kann
Betriebssysteme WS 2014, Speicher
63
Hermann Härtig, TU Dresden
Prozesse und Speicher
Prozess-Zustand
●
Seitentabellen
●
mehrere parallele Aktivitäten je Adressraum: Threads
Prozess-Umschaltung
●
TLB behandeln (falls kein Prozess-Identifier in TLB → löschen)
●
Caches
●
Botschaftenimplementierung
Betriebssysteme WS 2014, Speicher
64
Hermann Härtig, TU Dresden
Wegweiser: Virtueller Speicher
Anliegen – Begriffe – Vorgehen
Adressumsetzung
Seitenersetzung
Arbeitsmengenmodell
Betriebssysteme WS 2014, Speicher
65
Hermann Härtig, TU Dresden
Virtueller Speicher im Betriebssystem
Teilaufgaben
●
Seitenfehler-Behandlung
●
Verwaltung des Betriebsmittels Hauptspeicher
●
Aufbau der Adressraumstruktur
(Speicherobjekte und Regionen)
●
Bereitstellung spezifischer Speicherobjekte
●
Interaktion Prozess- und Speicher-Verwaltung
Betriebssysteme WS 2014, Speicher
66
Hermann Härtig, TU Dresden
Seitenfehlerbehandlung (Überblick)
trap (HW) {
!
!
!
!
!
!
!
!
rette Register
Ermittlung der Seitenfehleradresse
Regionmanager: Speicherobjekt bestimmen
freie Kachel beschaffen
falls nötig, alten Kachelinhalt
zurückschreiben (Prozess wartet)
Seiteninhalt in Kachel laden
(Prozess wartet)
Seitentabelle aktualisieren
return from trap
(Instruktion wird wieder aufgesetzt)
}
Betriebssysteme WS 2014, Speicher
67
Hermann Härtig, TU Dresden
Hauptspeicher: Betriebsmittelverwaltung
Aufgaben
●
gewährt und entzieht bei Knappheit Kacheln
●
Buchführung → wo sind welche Kacheln?
●
welche Kacheln werden verdrängt?
Seitenaustauschverfahren
●
Seitenverdrängung
●
Seitenersetzung
Betriebssysteme WS 2014, Speicher
68
Hermann Härtig, TU Dresden
Seitenersetzung allgemein
BS-seitig
BS-seitig
void init(Kachel) {
Kachel.modified = 0;
Kachel.referenced = 0;
}
void pagefault(Seiten_NR) {
XXX siehe Folie 67 …
NewK = getFreePageframe();
if (!NewK) {
//keine Kachel mehr frei
NewK = ReplacementPolicy();
Hardwareseitig
... Prozesse arbeiten ...
HW setzt referenced- und
modified-Flag
}
//NewK ist jedoch noch in
//Benutzung
if (NewK.modified)
writeToDisk(NewK, ...);
removeFromPT(NewK);
//aus alten AddrRäumen entfernen
NewContent(NewK);
//z.B. fillWithZero
//oder readFromDisk(Seiten_Nr,NewK)
insertIntoPT(Seiten_NR, NewK);
//Kachel im richtigen AR, bei der
//richtigen SeitenNR einfügen
Betriebssysteme WS 2014, Speicher
69
Hermann Härtig, TU Dresden
Seitenersetzungsverfahren
Problem
Eine Kachel wird benötigt, eine Seite ist zu verdrängen.
➔
wie und welche ??
Wie wird verdrängt?
Kachel aus Seitentabelle austragen (TLB-Eintrag löschen)
falls modifiziert → zurückschreiben auf persistenten Speicher
Welche Seite wird verdrängt?
!
optimal: die Seite wird verdrängt, die am spätesten in der Zukunft benutzt werden wird
!
stattdessen:
!
!
Betrachtung der Vergangenheit
(verschiedene Algorithmen)
Ausnutzung des Lokalitätsverhaltens („Arbeitsmengen-Modell“)
Betriebssysteme WS 2014, Speicher
70
Hermann Härtig, TU Dresden
Generelle Überlegung
!
!
wähle beliebige Kachel im
System nach folgender
Priorität:
Inspektionsintervalle für
„benutzt“ und
„modifiziert“
Zurücksetzen des
“benutzt” in jedem
Intervall
1) nicht benutzt,
nicht modifiziert
2) benutzt,
nicht modifiziert
3) nicht benutzt,
modifiziert
Betriebssysteme WS 2014, Speicher
4) benutzt, modifiziert
71
Hermann Härtig, TU Dresden
FIFO: First in first out
Verdränge älteste Seite
●
d.h. Inhalt der Kachel, die schon am längsten ihren
jetzigen Inhalt hat
Vorteil
●
●
keine Information über tatsächliches Referenzverhalten
nötig
einfach implementierbar
Nachteil
●
ignoriert Lokalitätsverhalten
●
BELADY's Anomalie
Betriebssysteme WS 2014, Speicher
72
Hermann Härtig, TU Dresden
LRU: Least Recently Used
Verdränge am längsten nicht genutzte Seite
Vorteil
●
gilt als gute Näherung für optimalen Algorithmus
Nachteil
●
●
●
aufwendige Realisierung
jeder Speicherzugriff müsste berücksichtigt werden
‣ HW-Unterstützung wird benötigt
Annäherungen per Software
Betriebssysteme WS 2014, Speicher
73
Hermann Härtig, TU Dresden
LRU Annäherung: Clock-Algorithmus
L
A
B
C
K
while (Kachel[i].referenced) {
Kachel[i].referenced = 0;
//Flag löschen
i = (i + 1) % FRAME_COUNT;
//Zeiger weiterdrehen
}
//Seite in Kachel Nummer i
//verdrängen
Betriebssysteme WS 2014, Speicher
74
D
J
E
I
H
G
F
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
●
Kachel mit ältestem Inhalt wird verdrängt
●
bessere Näherung: statt „0“ „1“ → feineres Altersraster
●
●
Analogie: Geburtsjahr
●
1992
●
1995
●
1996
niedrige Zahl → hohes Alter
Betriebssysteme WS 2014, Speicher
75
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
void init(Kachel) {
Kachel.modified = 0;
Kachel.referenced = 0;
}
Hardware
... Prozesse arbeiten ...
HW setzt referenced- und
modified-Flag
Betriebssysteme WS 2014, Speicher
BS-Thread:
// at every „Tick“ call:
void Aging(){
for(i = 0; i < maxK; i++) {
SetAge(Kachel[i].referenced);
// nächste Folien
Kachel[i].referenced = 0;
}
}
76
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
Betriebssysteme WS 2014, Speicher
77
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
A
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
D
0 0 0 0 0
Betriebssysteme WS 2014, Speicher
78
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
Tick 1
A
1 0 0 0 0
0 0 0 0 0
0 0 0 0 0
D
1 0 0 0 0
Betriebssysteme WS 2014, Speicher
79
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
A
1 0 0 0 0
B
0 0 0 0 0
C
0 0 0 0 0
D
1 0 0 0 0
Betriebssysteme WS 2014, Speicher
80
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
Tick 2
A
0 1 0 0 0
B
1 0 0 0 0
C
1 0 0 0 0
D
1 1 0 0 0
Betriebssysteme WS 2014, Speicher
81
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
A
0 1 0 0 0
B
1 0 0 0 0
C
1 0 0 0 0
D
1 1 0 0 0
Betriebssysteme WS 2014, Speicher
82
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
Tick 3
A
1 0 1 0 0
B
0 1 0 0 0
C
1 1 0 0 0
D
0 1 1 0 0
Betriebssysteme WS 2014, Speicher
83
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
Seitenersetzung
Age
A
1 0 1 0 0
20
B
0 1 0 0 0
8
C
1 1 0 0 0
24
D
0 1 1 0 0
12
Betriebssysteme WS 2014, Speicher
84
Hermann Härtig, TU Dresden
LRU Annäherung: Aging
Seitenersetzung
Age
A
1 0 1 0 0
20
X
0 1 0 0 0
8
C
1 1 0 0 0
24
D
0 1 1 0 0
12
Betriebssysteme WS 2014, Speicher
85
Hermann Härtig, TU Dresden
Wegweiser: Virtueller Speicher
Anliegen – Begriffe – Vorgehen
Adressumsetzung
Seitenersetzung
Arbeitsmengenmodell
Betriebssysteme WS 2014, Speicher
86
Hermann Härtig, TU Dresden
Das Arbeitsmengenmodell (Working Set)
Problem
●
Seitenfehlerhäufung bei Prozessaktivierungen
Grundgedanken
●
●
Lokalitätsprinzip
Betrachtung der Seitenreferenzfolge eines Prozesses durch
ein „Fenster“ der Länge T (sog. Arbeitsmengen-Parameter)
Betriebssysteme WS 2014, Speicher
87
Hermann Härtig, TU Dresden
Das Arbeitsmengenmodell (Working Set)
Arbeitsmenge w(t, T) zum Zeitpunkt t bzgl. T:
Menge der im Intervall [t – T, t] referenzierten Seiten
Erfahrung
●
max (Z(T)):
theoretisch mögliche Maximalzahl von
benutzten Seiten in T Zeiteinheiten
●
|w(t, T)| << max (Z(T))
Betriebssysteme WS 2014, Speicher
88
Hermann Härtig, TU Dresden
Das Arbeitsmengenmodell (Working Set)
Vorgehen
●
●
Bestimmung der Arbeitsmenge bei jeder Seitenreferenz
für aktive und bereite Prozesse muss sich mindestens die
Arbeitsmenge im Speicher befinden
●
Swapping, falls Rahmen fehlen
●
Prepaging bei Wiedereinlagerung
Probleme
●
Fenstergröße
●
Implementierung (prozesseigene Uhr benötigt)
●
„Seitenflattern“ (Thrashing)
●
globale/lokale Ersetzung
Betriebssysteme WS 2014, Speicher
89
Hermann Härtig, TU Dresden
Seitenfehlerrate
●
●
Begrenzung der Anzahl von Prozessen und globaler
Seitenaustausch
Ermittlung der Kachelanzahl:
abhängig von Seitenfehlerrate
Seitenfehlerrate r
A
B
Kachelanzahl
Betriebssysteme WS 2014, Speicher
90
Hermann Härtig, TU Dresden
Wegweiser
Seitentausch
Speicherobjekte und Regionen
(Adressraumstruktur)
Segmentierung
Caches
Betriebssysteme WS 2014, Speicher
91
Hermann Härtig, TU Dresden
Speicherobjekte
●
Text- (Code-), Daten-, ... -Segment eines Prozesses
●
Dateien
●
Grafikspeicher
●
●
BS-Datenstrukturen
●
Thread Control Blocks
●
Seitentabellen
Netzwerkobjekte
Betriebssysteme WS 2014, Speicher
92
Hermann Härtig, TU Dresden
Speicherobjekte und Regionen
Datei, D47
Datei, D08
Betriebssysteme WS 2014, Speicher
93
Hermann Härtig, TU Dresden
Speicherobjekte und Regionen
Datei, D47
Datei, D08
Betriebssysteme WS 2014, Speicher
94
Hermann Härtig, TU Dresden
Speicherobjekte und Regionen
Datei, D47
Datei, D08
Betriebssysteme WS 2014, Speicher
95
Hermann Härtig, TU Dresden
Speicherobjekte und Regionen
Datei, D47
Datei, D08
Betriebssysteme WS 2014, Speicher
96
Hermann Härtig, TU Dresden
Speicherobjekte und Regionen
Regionmanager
Datei, D47
Datei, D08
Betriebssysteme WS 2014, Speicher
97
Hermann Härtig, TU Dresden
Aufbau der Adressraumstruktur
!
!
Regionen im Adressraum:
explizites oder implizites Einbinden („Mappen“) von
Speicherobjekten in den virtuellen Adressraum eines
Prozesses
Operationen:
map(Adresse, Länge, Speicherobjekt,
Zugriffsrechte);
lookup(Adresse, Zugriffart) ->
●
Speicherobjekt
●
Seitennummer innerhalb Objekt
●
oder nicht definiert
●
oder Rechteverletzung
Betriebssysteme WS 2014, Speicher
98
Hermann Härtig, TU Dresden
Aufbau der Adressraumstruktur
!
z. B.
map( ... , ... , Datei, R);
map( ... , ... , Gerätespeicher, RW);
!
implizit: bei Prozesserzeugung werden Programm-, Keller-,
Daten-Regionen gebildet (in Unix: „Segmente“)
Betriebssysteme WS 2014, Speicher
99
Hermann Härtig, TU Dresden
Regionen-Manager
●
●
●
Verwaltung der Adressraum-Struktur
●
repräsentiert z. B. als verkettete Liste
Aufgabe bei Seitenfehler: Bestimmen von
●
Fehlerart
●
Speicherobjekt
●
Speicherseite
Fehlerarten
●
Zugriff auf ungültigen Bereich (z.B. Pointerfehler)
●
Rechteverletzung (z.B. Schreiben in Code-Bereich)
●
Copy On Write Fault
●
sonst: Seite nicht in MMU eingetragen
Betriebssysteme WS 2014, Speicher
100
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Dateisysteme
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
101
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Dateisysteme
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
102
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
103
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
D47, 11 ??
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
104
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
D47, 11 ??
JA
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
105
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
eintragen ST
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
106
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
D47, 11 ??
NEIN
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
107
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
Kachel frei ??
JA
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
108
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
Datei.read
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
109
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
eintragen ST
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
110
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
Kachel frei ??
NEIN
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
111
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
auswählen
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
112
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
austragen ST
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
113
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
zu Objekt ??
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
114
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
Datei, D08, 15
Datei.write
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
115
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
Datei.read
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
116
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
Adressräume z. B. 4 GB
Seite
Kachel/Rahmen
Block
MMU
Hardware
Netz
Datei, D47, 11
eintragen ST
Hauptspeicher
Regionmanager
Seitenersetzung
Betriebssysteme WS 2014, Speicher
117
Dateisysteme
Platte
Anonyme
Speicher
Hermann Härtig, TU Dresden
Das Zusammenspiel
●
Fehler
●
Finde Objekt + Seite (Offset-Behandlung)
●
Suche ob Kachel schon vorhanden
●
Falls ja: Seite in Seitentabelle eintragen → fertig
●
Falls nein: freie Kachel vorhanden?
●
Falls freie Kachel vorhanden: Inhalt lesen → Seite eintragen
●
Falls keine freie Kachel → verdrängen
●
Aus allen Seitentabellen austragen
●
Zu welchem Objekt gehört verdrängte Kachel?
●
Inhalt sichern, wenn er verändert wurde
●
dann wie oben: neuen Inhalt lesen, Seite eintragen
Betriebssysteme WS 2014, Speicher
118
Hermann Härtig, TU Dresden
Speicherobjekte im Netz
Botschaften
über Internet
Rechner in einem
verteilten System
Betriebssysteme WS 2014, Speicher
119
Hermann Härtig, TU Dresden
Systemstrukturen für Speicherobjekte
Unix, Windows: „monolithisch“
●
●
teilweise durch Prozesse (mit eigenem Adressraum) im
User-Mode
großenteils aber fest in Betriebssystem integriert
Mikrokernbasiert
●
alle Speicherobjekte bereitgestellt durch „Server“-Prozesse
mit eigenem Adressraum und im User-Mode
Betriebssysteme WS 2014, Speicher
120
Hermann Härtig, TU Dresden
Wegweiser
Arbeitsmengenmodell
Speicherobjekte und Regionen
(Adressraumstruktur)
Segmentierung
Caches
Betriebssysteme WS 2014, Speicher
121
Hermann Härtig, TU Dresden
Segmentierung
Ausgangspunkt
●
logisch zusammenhängende, aber untereinander
unabhängige Bereiche
Beispiele
●
Bibliotheken
●
Keller, Halde, Programm
Heute
●
kaum noch für ursprüngliche Bestimmung verwendet
●
Hardware-Unterstützung in aktuellen x86-CPUs
●
„kreative“ Anwendung für Betriebssystem-Bausteine wie
Thread-lokalen Speicher
Betriebssysteme WS 2014, Speicher
122
Hermann Härtig, TU Dresden
Zweidimensionale Adressierung
Eigenschaften
●
Segmentnummer
●
Adresse innerhalb Segment
●
beliebige Länge
Folgen/möglicher Einsatz
●
Länge und Zugriffsart können überwacht werden
●
Relokation einfach
●
Schutz
●
„Shared Libraries“
Betriebssysteme WS 2014, Speicher
123
Hermann Härtig, TU Dresden
Segmentierung und Paging (z. B. i386)
Segmente
!
!
!
!
Segmentdeskriptortabellen
Codesegment:
CS
Datensegment: DS
Stacksegment:
SS
weitere:
ES, FS, GS
Aufbau eines Deskriptors:
!
!
per Prozess (local desc. table)
per System (global desc. table)
32 Bits
Base 0-15
Base 24-31
0: Li is in bytes
1: Li is in pages
0: 16-Bit segment
1: 32-Bit segment
GD0
Relative
address
0
Limit 0-15
Limit 16-19
P DPL
Type
Base 16-23 4
Segment type and
protection
]
Privilege
level (0-3)
]
Betriebssysteme WS 2014, Speicher
124
[
Hermann Härtig, TU Dresden
Die vollständige Abbildung
16
0
32
0
SELECTOR
OFFEST
DESCRIPTOR TABLE
SEGMENT
DESKRIPTOR
LINEAR
ADDRESS
DIR
+
PAGE
OFFSET
PHYSICAL
ADDRESS
PAGE DIRECTORY
DIR ENTRY
PAGE FRAME
PG TBL ENTRY
CR3
Betriebssysteme WS 2014, Speicher
125
Hermann Härtig, TU Dresden
Wegweiser
Arbeitsmengenmodell
Speicherobjekte und Regionen
(Adressraumstruktur)
Segmentierung
Caches
Betriebssysteme WS 2014, Speicher
126
Hermann Härtig, TU Dresden
Rechnerarchitektur : Caches
Ziel
●
größtmöglicher Speicher + schnellstmöglicher Speicher
Grundlage
●
Lokalitätsverhalten bei Speicherzugriffen
Idee
●
●
Anordnung von schnelleren, kleineren Speichern zwischen
größeren, langsameren Speichern und Nutzer
bei jedem Zugriff auf langsameren Speicher wird auch in
schnellerem Speicher eine Kopie angelegt und genutzt
Betriebssysteme WS 2014, Speicher
127
Hermann Härtig, TU Dresden
Beispiele für Caches
●
●
●
●
Adressumsetzung:
Assoziativspeicher für langsame Seitentabellenspeicher
Platten:
schneller, aber nicht persistenter Speicher in Laufwerk oder
Controller
Verteilte Dateisysteme:
Kopien von entfernten Dateien auf lokalem Rechner
schneller Speicher zwischen CPU und Hauptspeicher
Betriebssysteme WS 2014, Speicher
128
Hermann Härtig, TU Dresden
Caches für Hauptspeicher
CPU
Adresse1
Adresse2
Adresse3
Adresse4
MEM
Inhalt
Inhalt
Inhalt
Inhalt
Characteristika
!
!
➔
Größe, Geschwindigkeit, Cachelinegröße
Organisation: Austauschverfahren, Zugriffsart,
physisch vs. virtuell ...
Tag: im Cache gespeicherte Adresse
Betriebssysteme WS 2014, Speicher
129
Hermann Härtig, TU Dresden
Organisation von Caches
Zugriffsarten
!
direkt: aus Adresse wird Index in Cache berechnet
Vergleich zwischen Zugriffsadresse und Tag
Zugriffsadresse
Index
Adresse1
Adresse2
Adresse3
Adresse4
Inhalt
Inhalt
Inhalt
Inhalt
=
Betriebssysteme WS 2014, Speicher
130
Hermann Härtig, TU Dresden
Organisation von Caches
Zugriffsarten
!
n-Wege-assoziativ:
zu jedem Index gibt es n Tag-Inhalt-Paare
Zugriffsadresse
Index
Adresse1
Adresse2
Adresse3
Adresse4
=
Betriebssysteme WS 2014, Speicher
Inhalt Adresse5
Inhalt Adresse6
Inhalt Adresse7
Inhalt Adresse8
Inhalt
Inhalt
Inhalt
Inhalt
=
131
Hermann Härtig, TU Dresden
Organisation von Caches
Virtuelle vs. physische Tags und Indizes
●
●
●
virtuelle Tags und Indizes (VIVT)
●
schnell (spart MMU-Umsetzung)
●
sharing problematisch
physische Tags und Indizes (PIPT)
●
langsamer
●
auch außerhalb CPU-Chip
●
sharing einfach
physiche Tags, virtuelle Indizes
(VIPT)
●
längere Tags, da Tag-Adresse
verschieden vom Index
Betriebssysteme WS 2014, Speicher
132
CPU
V virtuelle Adresse
MMU
P physische Adresse
Hermann Härtig, TU Dresden
Pentium III vs. Pentium IV
Pentium III
●
virtuell indiziert / physische Tags
Pentium IV
●
●
virtuelle Tags
trace cache: dekodierte Instruktionen werden in einem
Cache abgelegt
Heute
●
L1 meist virtuell indiziert
●
größere Caches physisch indiziert
Betriebssysteme WS 2014, Speicher
133
Hermann Härtig, TU Dresden
Zusammenfassung Speicher
●
Ziele von virtuellem Speicher: Schutz, Abstraktion
●
Adressumsetzung in der MMU
●
Vorwärts-, inverse Seitentabellen, mehrstufig, TLB
●
logischer Aufbau des Adressraums: Regionen
●
Behandlung von Seitenfehlern
●
Seitenersetzung vor Verwaltung des Hauptspeichers
Betriebssysteme WS 2014, Speicher
134
Hermann Härtig, TU Dresden