Compiler Construction - DPS, UIBK

Betriebssysteme für
Multiprozessorsysteme
Radu Prodan
Institut für Informatik, Universität Innsbruck
Verteilte und Parallele Systeme
http://dps.uibk.ac.at
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
1
Inhalt
 Einführung
 Multiprozessoren
o Aufbau, Programmierung
o Betriebssystem-Typen, Synchronisation, Scheduling
 Multicomputer
o Aufbau, Programmierung
o Lastausgleich
 Virtualisierung
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
2
Moore’sche Gesetz
 Moderne Rechner
o Enthalten Mikroprozessoren mit
vielen Millionen Transistoren
o Enthalten Arbeitsspeicher mit
Millionen von Speicherplätzen
(GigaBytes)
o Bewältigen Millionen von
Operationen pro Sekunde
 Das Moore’sche Gesetz besagt,
dass sich die Packungsdichte der
Transistoren auf einem
Mikroprozessor in etwa alle 18
Monate verdoppelt
 Kleiner – Schneller – Billiger
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
3
Warum Multiprozessorsysteme ?
 Einzelprozessorsysteme erreichen Technologiegrenzen
o Physikalische Grenzen
o Signalausbreitungsgeschwindigkeit
o Verlustleistung
 Wunsch nach Rechnern mit immer höherer Rechenleistung
o Für Einzelanwendungen (oft numerische Simulationen)
 „Grand Challenge“ Probleme: Klimasimulation, Moleküldesign, Genomanalyse,
Supraleitung, Luftstrom um Flugzeugflügel, Weltwirtschaft, Gehirn, …
 Rechenleistung im Bereich TFlop/s bis PFlop/s
 http://www.top500.org
o Als Server für die gleichzeitige Bearbeitung vieler Anfragen
 z.B. Datenbankserver, WWW-Server, Suchmaschinen, ...
 Ausbreitung des Internets
o Verbindet Millionen von Rechnern weltweit
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
4
Multiprozessorsysteme
 Multiprozessoren: Rechner mit mehreren Prozessoren
 Multikernprozessoren: Prozessoren mit mehreren Kernen
 Multicomputer: Zusammenschluss mehrerer Rechner über eine
Netzwerk
o Siehe die Vorlesungen: „Netzwerke und Internettechnik“, „Verteilte
Systeme“ und „Parallele Systeme“
 Multiprozessorsysteme nur sinnvoll, wenn Parallelverarbeitung
möglich ist
o Bei Servern ist ein Prozess oder Thread pro Klient üblich
o Bei Einzelanwendungen ist Parallelisierung erforderlich
o Siehe das Wahlmodul: „Einführung in Parallelrechnen und Parallele
Algorithmen“
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
5
Art von Multiprozessorsystemen
Multiprozessorsystem mit
gemeinsamen Speicher
21.06.2012
Multicomputer mit
Nachrichtenaustausch
R. Prodan, Betriebssysteme, Sommersemester 2012
Großräumig
Verteiltes System
6
Ebenen der Parallelverarbeitung (1)
 Programmebene (Jobebene)
o Unabhängige Programme oder Prozesse
 Prozessebene (Taskebene)
o Kooperierende Prozesse (oder Threads)
o Meist mit Kommunikation durch Nachrichtenaustausch
 Blockebene
o Leichtgewichtige Prozesse (Threads)
o Kommunikation über gemeinsamen Speicher
o Häufig Aufteilung der Iterationen von Schleifen (manuell oder
automatisch durch Compiler)
 Diese Ebenen werden durch das Betriebssystem unterstützt und
gesteuert
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
7
Ebenen der Parallelverarbeitung (2)
 Anweisungsebene (Befehlsebene)
o Gleichzeitige Ausführung mehrerer elementarer
in der Sprache nicht weiter zerlegbare
Anweisungen oder Datenoperationen
o Scheduling erfolgt statisch durch Compiler
und/oder zur Laufzeit durch Hardware
o Prozessoren mit mehreren Ausführungseinheiten
(ALUs) wie superskalaren Prozessoren und VLIW
(EPIC)
 Suboperationsebene
o Befehle werden durch Compiler oder
Prozessoren in Suboperationen aufgebrochen,
die parallel ausgeführt werden
o Vektorbefehle, Streaming SIMD Extensions (SSE)
 Diese Ebenen werden durch Hardware (ohne
Betriebssystem) unterstützt
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
8
Shared-Memory-Multiprozessoren
 Zwei oder mehrere CPUs oder CPU-Kerne haben Zugriff auf einen
gemeinsamen Speicher
o Globaler physischer Adressraum
 Auch alle E/A-Ressourcen sind von allen CPUs aus zugreifbar
 Prozesse oder Threads sehen dieselben Betriebsmittel (inkl. Virtueller
Adressraum), egal auf welcher CPU sie ausgeführt werden
 Nur eine Betriebssystem-Instanz für den gesamten Rechner
o Single System Image
o Nutzung und Administration ist fast wie bei Einzelprozessorsystem
 Besondere Aufgaben des Betriebssystems
o Synchronisation, Scheduling und Ressourcenverwaltung
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
9
Uniform Memory Access (UMA)
Multiprozessoren
 Alle CPUs greifen über das Verbindungsnetz
(Bus) auf den gemeinsamen Speicher zu
o Zugriff für jede CPU gleich schnell bzw. langsam
 Bus und Speicher sind gemeinsame
Betriebsmitteln und werden schnell zum
Engpass
 Begrenzte Skalierbarkeit
o System wird durch Bandbreite des Buses
beschränkt
o Maximal 32 – 64 CPUs
 Beispiele
o PCs mit Multikernprozessoren
o Mehrprozessor-PCs
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
10
Caches in Multiprozessorsystemen
 Cache ist ein schneller, prozessornaher Zwischenspeicher
 Speichert Kopien der zuletzt am häufigsten benutzten Daten aus dem
Hauptspeicher
o Falls Daten im Cache ist kein Hauptspeicherzugriff nötig
 Caches sind in Multiprozessorsystemen essentiell
o Cachezugriff 10 – 1000 Mal schneller als Hauptspeicherzugriff
o Entlastung von Verbindungsnetz und Speicher
 Caches nutzen Lokalitätseigenschaft von Programmen aus
o Jeder Prozess oder Thread rechnet meist nur auf „seinen“ Daten
 Im Allgemeinen werden nicht einzelne Speicherwörter sondern ganze Blöcke oder
Cachezeile zwischengespeichert (32 – 64 Bytes)
 Cache-Kohärenz-Problem
o Existenz mehrerer Kopien von Daten kann zu Inkonsistenzen führen
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
11
Drei Busbasierte Multiprozessoren
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
12
„Write-back“ Cache-Kohärenz-Problem
 Hauptspeicher wird beim Schreiben im Cache nicht
aktualisiert
 Drei Prozessoren greifen auf dasselbe Speicherwort zu
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
13
„Write-back“ Cache-Kohärenz-Problem
 Hauptspeicher wird beim Schreiben im Cache nicht
aktualisiert
 Drei Prozessoren greifen auf dasselbe Speicherwort zu
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
14
„Write-back“ Cache-Kohärenz-Problem
 Hauptspeicher wird beim Schreiben im Cache nicht
aktualisiert
 Drei Prozessoren greifen auf dasselbe Speicherwort zu
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
15
„Write-back“ Cache-Kohärenz-Problem
 Hauptspeicher wird beim Schreiben im Cache nicht
aktualisiert
 Drei Prozessoren greifen auf dasselbe Speicherwort zu und
erhalten verschiedene Ergebnisse!
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
16
„Write-through“ Cache-Kohärenz-Problem
 Beim Schreiben wird immer auch Hauptspeicher
aktualisiert
 Drei Prozessoren greifen auf dasselbe Speicherwort
zu
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
17
„Write-through“ Cache-Kohärenz-Problem
 Beim Schreiben wird immer auch Hauptspeicher
aktualisiert
 Drei Prozessoren greifen auf dasselbe Speicherwort
zu
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
18
„Write-through“ Cache-Kohärenz-Problem
 Beim Schreiben wird immer auch Hauptspeicher
aktualisiert
 Drei Prozessoren greifen auf dasselbe Speicherwort
zu
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
19
„Write-through“ Cache-Kohärenz Problem
 Beim Schreiben wird immer auch Hauptspeicher
aktualisiert
 Drei Prozessoren greifen auf dasselbe Speicherwort
zu
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
20
„Write-through“ Cache-Kohärenz Problem
 Beim Schreiben wird immer auch Hauptspeicher
aktualisiert
 Drei Prozessoren greifen auf dasselbe Speicherwort
zu und erhalten verschiedene Ergebnisse!
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
21
Cache-Kohärenz-Definition
 Informell: Jede Leseoperation auf ein Speicherwort gibt den
gemäß dem ausgeführten Programm „zuletzt“ auf dieses
Speicherwort geschriebenen Wert zurück
 Formaler: ein (Cache-)Speichersystem ist kohärent genau dann,
wenn
o Jeder Prozessor eigene Schreiboperationen sofort sieht
o Jede Schreiboperation irgendwann von jedem anderen Prozessor
gesehen wird („write propagation“)
o Alle Prozessoren Schreiboperationen auf dasselbe Speicherwort in
derselben Reihenfolge sehen („write serialization“)
 Eine Schreiboperation „sehen“ bedeutet, dass der geschriebene
Wert gelesen werden kann bevor er wieder überschrieben wird
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
22
Sicherstellung der Cache-Kohärenz
 Bei einem Schreibzugriff müssen alle betroffenen Caches die
Kopien enthalten benachrichtigt werden
o Invalidierung der betroffenen Cachezeile in diesen Caches
o Bei write-back muss anderer Cache vorher seine veränderte
Cachezeile in den Hauptspeicher zurückschreiben
 Einfachste Möglichkeit ist die Benachrichtigung aller Caches
über Broadcast
o Sehr einfach mit Bus als Verbindungsnetz
o Häufige Broadcasts machen Verwendung skalierbarerer
Verbindungsnetze relativ sinnlos
 Für bessere Skalierbarkeit werden nur die betroffenen Caches
(einzeln) benachrichtigt
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
23
CC-NUMA Multiprozessoren
 Cache Coherent Non Uniform Memory Access (CC-NUMA)
 Speicher ist auf die einzelnen Knoten verteilt
o Ein einziger Adressraum, der für alle CPUs sichtbar ist
o Jede CPU kann auf alle Systemressourcen zugreifen aber
unterschiedlich schnell
o Zugriff auf lokalen Speicher erfolgt direkt und schnell
 Verwendung skalierbarer Verbindungsnetze, die mehrere
gleichzeitige Speicherzugriffe erlauben
o z.B. Koordinatenschalter („Crossbar-Switches“)
 Programmierer und Betriebssysteme müssen die
unterschiedlichen Zugriffszeiten berücksichtigen
o Scheduling
o Speicherzuteilung
o ...
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
24
CC-NUMA Verzeichnisbasierte CacheKohärenz
 Pro Knoten wird ein Verzeichnis mit Einträgen für jede
lokale Cachelinie verwaltet
 Verzeichnis-Eintrag speichert
o „Dirty bit“ zeigt, ob die Cachelinie modifiziert ist und wer
die aktuelle Version hat
o Welche Knoten Kopien im Cache besitzen (für gezielte
Invalidierungsnachrichten bei Schreibzugriff)
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
25
Beispiel






Anzahl Knoten: 256 = 28
Speicher pro Knoten: 16 MB = 24 ∙ 220 = 224 B
Gesamtspeicher: 28 ∙ 224 = 232 B
Cachelinie Größe: 64 = 26 B
Gesamtanzahl Cachelinien: 232 : 26 = 226 B
Cachelinien pro Knoten: 226 : 28 = 218 B
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
26
LOAD-Befehl von CPU-20 (1)
 LOAD-Befehl von CPU-20
 MMU generiert die physische Adresse: 0x24000108
o Knoten 36, Cachezeile 4, Offset 8




CPU-20 schickt Anfrage an die Heim-CPU-36
CPU-36 hat nicht in Cache, weil der Verzeichniseintrag leer ist
Cachezeile 4 wird in aus dem lokalen RAM bezogen und an CPU-20 zurückgesandt
CPU-36 setzt den Verzeichniseintrag 4 auf 20
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
27
LOAD-Befehl von CPU-20 (2)
 LOAD-Befehl von CPU-20: 0x24000088
 MMU generiert die physische Adresse: 0x24000108
o Knoten 36, Cachelinie 2, Offset 8





CPU-20 schickt die Anfrage an die Heim-CPU-36
CPU-36 sieht, dass die Cachezeile bei CPU-82 zwischengespeichert ist
CPU-36 setzt den Verzeichniseintrag 2 auf 20
CPU-36 schickt Anfrage an die CPU-82, die Cachezeile 2 an CPU-20 zu übermitteln
CPU-82 schickt Cachezeile 4 an CPU-20 und setzt den Verzeichniseintrag 2 auf 20
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
28
Speicherkonsistenz
 Cache-Kohärenz stellt nur „korrektes“ Verhalten in Bezug auf jeweils
ein Speicherwort sicher
o Wird ein Speicherwort verändert, sieht jede CPU irgendwann diese Änderung
 Bleibt die Frage, wann eine CPU den neuen Wert sieht
o In welcher Reihenfolge sieht eine CPU Schreiboperationen auf verschiedene
Speicherworte?
 Intuitive Erwartung: in der Reihenfolge der Schreiboperationen!
o Was heißt das, wenn Schreiboperationen auf verschiedenen Knoten (mehr oder
weniger gleichzeitig) stattfinden?
 Insbesondere CC-NUMA Systeme bieten oft nur abgeschwächte
Speicherkonsistenz
o Siehe Bakery-Beispiel in den Übungen
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
29
Ein Betriebssystem pro CPU

Jede CPU hat ihre eigene Betriebssystem-Instanz (einfachste Möglichkeit)

Hauptspeicher wird statisch partitioniert und Partitionen voreinander geschützt

System arbeitet prinzipiell wie n unabhängige Rechner
o Jede CPU hat ihre festen Prozesse
o Betriebssystem-Aufrufe werden von lokaler CPU behandelt

Gemeinsame E/A, flexible Speicheraufteilung
o Problem eventuell bei Datei-/Festplatten-Caching (Cache-Kohärenz)

Partitionierung in unabhängige Systeme wird heute von vielen Multiprozessoren unterstützt
o Partitionen können aber auch mehrere CPUs umfassen
o Einsatz vor allem für (mehrere) Servers
o Vorteile: einfachere Systemverwaltung, flexible Konfiguration
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
30
Master-Slave-Multiprozessoren
 Betriebssystem wird nur von einer festen Master CPU ausgeführt
 Andere Slaves CPUs führen nur Benutzerprozesse aus
o Master kann auch Benutzerprozesse ausführen
 Systemaufrufe werden (über Interrupt) an Master umgeleitet
 Slaves besitzen nur einen Dispatcher, der aus gemeinsamer Bereitliste den
nächsten Prozess oder Thread auswählt
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
31
Master-Slave-Multiprozessoren (2)
 Betriebssystem muss nur sehr geringfügig angepasst werden
o Scheduler-Bereitliste ist einzige gemeinsame Datenstruktur
o Zugriff muss über Mutex geschützt werden
o Alle anderen Betriebssystem-Datenstrukturen werden nur vom
Master genutzt
 CPUs und Speicher können dynamisch an Prozesse oder
Threads verteilt werden
 Nachteil ist, dass der Master leicht zum Engpass wird
 Verwendung (noch) bei Hochleistungsrechnern für
numerische Anwendungen, da kaum Systemaufrufe
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
32
Symmetrische Multiprozessoren
 Nur eine Instanz des Betriebssystems im Speicher, ausführbar von jeder CPU
 CPUs und Speicher dynamisch balancierbar
o Nur ein Satz von Betriebssystem-Datenstrukturen
 Kein Flaschenhals durch Master
 Problem: Zugriff auf Betriebssystem-Daten durch Betriebssystem-Code auf
mehreren CPUs benötigt wechselseitiger Ausschluss für alle
Datenstrukturen notwendig
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
33
Symmetrische Multiprozessoren (2)
 Einfachste Möglichkeit: gesamtes Betriebssystem ist kritischer
Abschnitt
o Benötigt nur eine einzige Sperre („Giant Lock“ Betriebssystem)
o Nachteil: genauso schlecht skalierbar wie Master/Slave
 Feiner granulare Sperren für bessere Skalierbarkeit
o Eine Sperre für jedes Subsystem des Betriebssystems (Scheduler,
Speicherverwaltung, E/A)
o Eigene Sperre für jede Datenstruktur
 Deadlock-Gefahr bei mehreren Sperren
o Deadlock-Prevention durch Definition einer Reihenfolge auf den Sperren
 Korrekte Verwendung von Sperren ist wesentliche
Herausforderung bei der Entwicklung von SMP-Betriebssystemen
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
34
Test-and-Set (TSL)
 Wechselseitiger Ausschluss innerhalb des Betriebssystem-Kerns
 Hardwarebefehl, der mehrere Aktionen auf einer einzelnen Speicherstelle atomar
ohne Unterbrechung mit nur einem Befehlszyklus ausführt („Read-Modify-Write“)
o TSL RX, lock
int TSL(int *lock) {
int old = lock;
*lock = 1;
return old;
}
int lock = 0;
. . .
while (TSL(lock) == 1);
. . .
lock = 0;
21.06.2012
// Globale Initialisierung
// Spin-Lock
// Kritische Region
// Region freigeben
R. Prodan, Betriebssysteme, Sommersemester 2012
35
Multiprozessor-Synchronisation
 Auf Einzelprozessorsystemen ist die Unterbrechungssperre
atomare TSL Operationen ausreichend
 Auf Mehrprozessorsysteme
o
o
o
o
21.06.2012
Mehrere CPUs können echt gleichzeitig auf Daten zugreifen
Unterbrechungssperre nicht mehr ausreichend
Geeignetes Mutex-Protokoll notwendig
TSL ohne Zusatzmaßnahmen ist keine Lösung, weil es zwei
Speicherzugriffe benötigt (Lesen, Schreiben)
R. Prodan, Betriebssysteme, Sommersemester 2012
36
Atomarer TSL in Multiprozessoren
 Peterson-Algorithmus in alten Multiprozessor-Systemen
 Heutige Systeme
o Korrekte Implementierung atomarer TSL-Operationen mit
Hardware Unterstützung durch Verbindungsnetz oder
Speichersystem
o Möglichkeit, den Bus oder einen Speicherblock über mehrere
Zugriffe hinweg zu sperren
o Eine Spezielle Leitung des Buses wird auf 1 gesetzt
o Atomare TSL-Transaktionen
 Wechselseitiger Ausschluss in Multiprozessoren ist damit
im Endeffekt immer durch Bus- bzw. Speicherarbiter
realisiert
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
37
Spin-Locks und Caches
 Wechselseitiger Ausschluss benutzt einen Spin-Lock
o Extreme Belastung des Busses (bzw. Verbindungsnetzes)
o Verschwendet wertvolle Rechenzeit der CPUs
 Kann das Cache-Kohärenz Protokoll das Problem beheben?
o Lege eine Kopie der Sperre in eigenem Cache und ab warte auf ein Invalidierungssignal
o Die CPU, die die Sperre freigibt schickt die Invalidierungsnachricht
o Wenn die Invalidierungsnachricht auftritt, kann die abwartende CPU es wieder
versuchen
 Problem: Caches arbeiten nicht mit einzelnen Bytes sondern mit
Cachelinien von 32 oder 64 Bytes
o TSL ist eine schreibende Operation, macht die Cachelinie des Halters der Sperre ungültig
und liest eine private exklusive Kopie
o Gewöhnlich werden Wörter, die die Sperre umgeben von der CPU benötigt, die diese
Sperre hält, und geändert (Lokalität)
o Betroffener Cachezeile wird zwischen Inhaber der Sperre und anfragender CPU laufend
invalidiert
o Hohe unnötige Bus-Belastung
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
38
Test und TSL
 Einfache Abfrage des Locks vor dem Sperrversuch mit TSL
while (lock == 1 || TSL(&lock) == 1);
. . .
// kritischer Abschnitt
lock = 0;
 Während des Wartens wird Lock nur gelesen (aus dem Cache)
o Verbesserung gegenüber einfacher Sperre
 Bei Freigabe: Invalidierung der Caches
o Mehrere Threads können lock == 0 sehen und versuchen, mit der TSL
Operation die Sperre zu bekommen
o Dadurch viele weitere überflüssige Invalidierungen
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
39
Exponential Backoff
 Ethernet-Protokoll (Anderson, 1990)
 Zeitliche Entzerrung der Sperrversuche
o Warteschleife zwischen zwei Abfragen der Sperre
o Falls Sperre belegt wird die Wartezeit verdoppelt (bis zu
einem Maximum)
 Kombiniert mit test und TSL
 Busbelastung wird (auch bei Freigabe) geringer
 Erhöhte Reaktionszeit bei Freigabe der Sperre
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
40
Load Linked und Store Conditional
 Spezielle Maschinenbefehle zur Realisierung von Spin-Locks
li r2,#1
 Load Linked
o Laden aus dem Speicher (bzw. Cache)
wt: ll r1,flag
o Adresse wird in Link Register vermerkt
bnz wt
o Link Register wird bei Invalidierung der Cachezeile gelöscht
 Store Conditional
o Speichert einen Wert, falls die Adresse mit der im Link
Register übereinstimmt
o Scheitert sonst
 Maximal eine Invalidierung bei Store Conditional
sc flag,r2
beqz wt
... ; k.R.
st flag,#0
 Immer noch viele Invalidierungen bei Befreiung der Sperre
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
41
Listenbasierte Sperren
 Mellor-Crummey und Scott, 1991
 Sperre als Liste mit lokalen Sperr-Variablen realisiert
o
o
o
o
Jede CPU wartet nur an ihrer lokalen Sperre
Falls gesperrt fügt die CPU ein Listenelement mit lokaler Sperre an
Belegen oder freigeben des Locks mit O(1) Speichertransaktionen
Garantiert FIFO-Reihenfolge
Zeigen auf Listenende
(globale Sperre)
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
42
Implementierung einer Listenbasierten
Sperre
struct qnode { bool locked; qnode *next };
lock(qnode *l, qnode *n) {
n−>next = NULL;
qnode pred = fetch_and_store(l,n);
if (pred != NULL) {
n−>locked = true;
pred−>next = n;
while (n−>locked);
}
}
unlock(qnode *l, qnode *n) {
if (n−>next == NULL) {
if (compare_and_swap(l,n,NULL))
return;
while (n−>next == NULL);
}
n−>next−>locked = false;
}
21.06.2012
//
//
//
//
//
//
//
//
//
//
locked = true: Lock ist von einem
anderen Prozess belegt
l zeigt auf das Ende der Liste
n zeigt auf lokales Listenelement
n als Listenende setzen: pred = l; l = n;
Liste nicht leer, falls Lock belegt ist
Lock ist von einem Vorgänger belegt
Einfügen in die Liste
Spin Lock: warte auf Freigabe
durch Vorgänger
// Falls kein Nachfolger in der Liste
// if (l == n) l = NULL;
// Warten bis Nachfolger eingetragen ist
// Freigabe an Nachfolger
R. Prodan, Betriebssysteme, Sommersemester 2012
43
Aktives Warten oder Threadwechsel?
 Aktives Warten ist bei Multiprozessoren möglich und oft sinnvoll
o In Einzelprozessorsystemen führt es zur Verklemmung oder extrem
schlechter Leistung
 In einigen Fällen ist aktives Warten auch unvermeidlich
o z.B. beim Zugriff auf die Threadliste
 Threadwechsel bedeutet immer zusätzlichen Overhead
o Zeit für Kontextwechsel selbst, Umladen von Caches, …
 Optimale Entscheidung daher abhängig von mittlerer Wartezeit
 Praxis: Mutex wartet einige Zeit aktiv, dann Threadwechsel
o Zeit für aktives Warten ist davon abhängig, wie lange die Sperre bei den
letzten Versuchen blockiert war
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
44
Multiprozessor-Scheduling
 Zwei Dimensionen
o Welcher Thread soll als nächstes ausgeführt werden?
o Auf welcher CPU soll er ausgeführt werden?
 Zusätzliche Schwierigkeit
o Threads sind eventuell nicht unabhängig
o Kommunikation oder Synchronisation zwischen den
Threads
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
45
Timesharing
 Präemptives Scheduling
o Jeder Thread kann für die Dauer einer Zeitscheibe seine Aufgaben ausführen, dann wird
wieder in der Warteliste geschickt
 Systemweite Liste rechenbereiter Threads
o Mehrere Teil-Listen mit unterschiedlicher Prioritäten
 Jede CPU wählt und entfernt aus der Liste einen Thread mit der höchsten Priorität
o Dazu wird die Liste durch ein Mutex gesperrt (Nachteil)
 Lastausgleich (Vorteil)
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
46
Timesharing und Spin Locks
 Bei Multiprozessoren tritt häufiger der Einsatz von SpinLocks auf
 Falls Thread x, der Sperre besitzt, unterbrochen wird
o Andere Threads verschwenden Zeit mit Warten, bis Thread x
wieder die CPU bekommt
 Smart Scheduling
o Thread, der Sperre hält, setzt ein systemweites Flag
o Scheduler gewährt diesem Thread dann zusätzliche Zeit, um
Sperre wieder freizugeben
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
47
Timesharing und Caches
 Thread kann nacheinander auf verschiedenen CPUs laufen
o Ineffizient, da jedes Mal der Cache wieder geladen werden muss
 Cache-Affinität oder Affinity-Scheduling
o Thread möglichst immer dieselbe CPU zuteilen
 Realisierbar durch zweistufiges Scheduling
o Bei Thread-Erzeugung wird ihn eine CPU zugewiesen
o Danach führt jede CPU das Scheduling „ihrer“ Threads durch
o Nur falls eine CPU keine bereiten Threads hat, wählt sie einen Thread
einer anderen CPU aus
 Weiterer Vorteil
o Jede CPU greift auf lokale Threadliste zu und ist damit weniger
Synchronisation nötig
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
48
Scheduling Interagierender Threads
 Kommunikation zwischen zwei Threads die phasenweise verschoben sind
o A0 und A1
o B0 und B1
 Jeder Thread bekommt die Nachricht erst dann, wenn er in seinem 100ms
Zeitabschnitt gestartet wird
o Jedes Anfrage-Antwort-Paar dauert 200ms!
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
49
Scheduling Interagierender Threads
 Interagierende Threads sollten möglichst gleichzeitig laufen
 Bei unabhängigem Scheduling ist das nicht gewährleistet
o Kann Geschwindigkeit des Programms drastisch reduzieren
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
50
Space-Sharing
 Stellt sicher, dass die Threads eines Prozesses immer gleichzeitig rechnen
 Prozess bekommt eine Partition (Menge von CPUs) exklusiv zugeteilt
o
o
o
o
Für jeden Thread eine CPU
Prozess wird nur gestartet, falls genügend CPUs frei sind
Jeder Thread bleibt so lange seiner CPU zugeordnet bis er terminiert
Bei Blockierung eines Threads bleibt die CPU unbenutzt (Nachteil)
 Batch-Scheduling der Prozesse
o z.B. First Come First Serve, Shortest Job First, …
 Kein Multiprogramming, kein Overhead für Kontextwechsel
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
51
Gang-Scheduling
 Betrachtet Gruppe verwandter Threads als Einheit oder Gang
 Alle Mitglieder einer Gang
o Laufen (möglichst) zeitgleich auf verschiedenen CPUs mit Timesharing
o Beginnen und beenden ihre Zeitabschnitte gemeinsam
 Synchrones Scheduling aller CPUs
o Scheduling nur am Ende festgelegter Zeitscheiben
o Bei Blockierung wird die CPU bis zum Ende der Zeitscheibe unbenutzt
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
52
Besonderheiten bei Betriebssystemen
für CC-NUMA Parallelrechner
 Speicherverwaltung
o Zuteilung von Kacheln auf möglichst nahem Knoten
o Auslagerung von Seiten pro Speicherzone (Knoten)
o Jeder Knoten lagert nur lokale Seiten aus
 Scheduling mit hoher Prozessor-Affinität
o Prozess oder Thread möglichst nahe bei seinen Daten starten
o Processor Pinning: feste Zuordnung einer CPU
 Teilweise statische Ressourcenzuteilung möglich
o Threads und Bereichen des logischen Adressraums können
bei Programmstart (über Konfigurationsdatei) feste Knoten
zugeordnet werden
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
53
Multicomputer
 Vernetzte Rechner
o Network of Workstations (NOW)
o Cluster of Workstations (COW)
 Skalierbar bis über 100.000 Knoten
o Häufig Multiprozessorsysteme als Knoten
 Kommunikation und Synchronisation nur über Nachrichtenaustausch
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
54
Kommunikationssystem
a. Einzelner Schalter
b. Ring
c. Gitter
d. Doppelter Torus
e. Würfel
f. 4D-Hyperwürfel
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
55
Netzwerkschnittstellen
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
56
Low-Level Kommunikationssoftware
 Klassisch: Netzwerkkarte im Betriebssystem-Adressraum
o Senden/Empfangen muss über Systemaufruf erfolgen
o Betriebssystem muss zwischen Benutzer- und BetriebssystemAdressraum kopieren
 Bei modernen Multicomputern: Netzwerkkarte wird in den
Benutzeradressraum abgebildet
o Benutzerprozess kann den Auftrag direkt an Netzwerkkarte geben
o Daten per DMA aus/in Benutzeradressraum gelesen/geschrieben
o DMA nutzt physische Adressen und Seiten müssen im Speicher
verriegelt werden
o Einfachster Fall: nur ein Prozess darf die Netzwerkkarte nutzen
o Eigene Netzwerkkarte für Betriebssystem-Kommunikation
o Netzwerkkarte mit Virtual Interface Architecture (VIA)
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
57
Kommunikation auf Benutzerebene
 Nachrichtenversand mit send und receive
 send(dest, &mptr)
 receive(source, &mptr)
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
58
Blockierendes Senden
 Synchrones Senden
o Befehl nach dem Send wird erst dann ausgeführt, wenn
die Nachricht vollständig gesendet wurde
o Erlaubt direktes Kopieren in Speicher des Empfängers
o Sender wird blockiert, bis Empfänger bereit ist
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
59
Nicht-blockierendes Senden
 Asynchrones Senden
o Aufrufer bekommt die Kontrolle zurück bevor die Nachricht vollständig
gesendet wurde
o Puffer darf nicht verändert werden, bis die Nachricht gesendet wurde
 3 Lösungen
o Kopie in Zwischenpuffer beim Sender oder Empfänger
o Unterbrechung beim Sender wenn die Nachricht gesendet wurde
o Copy-on-Write
 Seiten des Sendepuffers werden schreibgeschützt
 Erst bei Schreibzugriff wird eine Kopie der Seite erstellt
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
60
Empfangen
 Blockierendes Empfangen hält den Aufrufer solange an, bis die
Nachricht empfangen wurde
 Nicht-blockierendes Empfangen teilt dem Kern mit, wo der
Empfangspuffer zu finden ist und gibt die Kontrolle zurück
o Unterbrechung wenn die Nachricht angekommen ist
o Polling um herauszufinden, ob eine wartende Nachricht gibt (+
get_message Aufruf)
o Pop-Up-Threads
 Bei Eingang der Nachricht wird neuer Thread im Empfängerprozess erzeugt
 Führt vordefinierte Prozedur aus, die die Nachricht behandelt
o Active Messages
 Empfängercode wird direkt im Interrupt-Handler aufgerufen
 Nachricht enthält Adresse des Handlers
 Handler liest Nachricht direkt aus der Netzwerkkarte und bearbeitet sie
 Nur möglich, wenn Empfänger dem Sender vertrauen kann
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
61
Entfernter Prozeduraufruf (RPC)
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
62
Distributed Shared Memory (DSM)
 Mögliche gemeinsame Speicher Implementierungsschichten
a.
b.
c.
21.06.2012
Hardware
Betriebssystem
Software auf der Benutzerebene
R. Prodan, Betriebssysteme, Sommersemester 2012
63
DSM Beispiel
a. Speicherseiten des auf
4 Maschinen verteilten
Adressraumes
b. Situation nachdem
CPU 1 die Seite 10
zugegriffen hat und die
Seite dorthin
verschoben wurde
c. Situation, wenn Seite
10 nur zum Lesen ist
und Replikation
verwendet wurde
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
64
False Sharing
 DSM
o 2 unabhängige Variablen, die zufällig auf derselben Seite sind,
werden von 2 unterschiedliche CPUs gleichzeitig benützt
 ccNUMA
o 2 unabhängige Variablen, die zufällig auf derselben Cachezeile
sind, werden von 2 unterschiedliche CPUs gleichzeitig benützt
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
65
False Sharing Beispiel: Cache Thrashing
gcc false-sharing.c -lpthread
#include <pthread.h>
#define N 30000000
#define M 0
time a.out
double s1[M], s2[M], s3[M], s4[M];
real
user
sys
void *arbeitsthread(void *arg) {
int i;
double *s = (double *) arg;
*s = rand();
for (i=0; i < N; i++)
*s = *s + i*(*s);
return NULL;
}
int main(void) {
pthread_t id1, id2, id3, id4;
pthread_create(&id1, NULL, &arbeitsthread,
pthread_create(&id2, NULL, &arbeitsthread,
pthread_create(&id3, NULL, &arbeitsthread,
pthread_create(&id4, NULL, &arbeitsthread,
pthread_join(id1, NULL);
pthread_join(id2, NULL);
pthread_join(id3, NULL);
pthread_join(id4, NULL);
return 0;
}
21.06.2012
0m3.427s
0m10.269s
0m0.000s
 Wichtig: das Programm ohne
Optimierungen kompilieren
&s1);
&s2);
&s3);
&s4);
o Ohne –O Option
 s1, s2, s3 und s4 werden in der
gleiche Cachezeile abgebildet
o Dadurch viele Überflüssige
Invalidierungen in jeder Iteration
R. Prodan, Betriebssysteme, Sommersemester 2012
66
False Sharing Beispiel: Sequentielle
Ausführung
#include <pthread.h>
gcc false-sharing.c -lpthread
#define N 30000000
#define M 0
time a.out
double s1[M], s2[M], s3[M], s4[M];
void *arbeitsthread(void *arg) {
int i;
double *s = (double *) arg;
*s = rand();
for (i=0; i < N; i++)
*s = *s + i*(*s);
return NULL;
}
real
user
sys
int main(void) {
pthread_t id1, id2, id3, id4;
pthread_create(&id1, NULL, &arbeitsthread,
pthread_join(id1, NULL);
pthread_create(&id2, NULL, &arbeitsthread,
pthread_join(id2, NULL);
pthread_create(&id3, NULL, &arbeitsthread,
pthread_join(id3, NULL);
pthread_create(&id4, NULL, &arbeitsthread,
pthread_join(id4, NULL);
return 0;
}
21.06.2012
&s1);
&s2);
&s3);
&s4);
0m0.959s
0m0.948s
0m0.000s
 Die sequentielle Ausführung ist
schneller als die parallele, weil
die Cache Invalidierungen nicht
mehr vorhanden sind
R. Prodan, Betriebssysteme, Sommersemester 2012
67
Dimension Einer Cachezeile
cat /proc/cpuinfo
processor
: 0
vendor_id
: AuthenticAMD
cpu family
: 15
model
: 33
model name
: Dual Core AMD Opteron(tm) Processor 880
stepping
: 2
cpu MHz
: 2400.000
cache size
: 1024 KB
physical id
: 0
siblings
: 1
core id
: 0
cpu cores
: 1
fpu
: yes
fpu_exception
: yes
cpuid level
: 1
wp
: yes
flags
: fpu tsc msr pae cx8 apic mtrr cmov pat clflush mmx fxsr sse sse2 ht syscall nx
mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips
: 5974.25
TLB size
: 1024 4K pages
clflush size
: 64
cache_alignment : 64
address sizes
: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
68
False Sharing Beispiel: Padding
#include <pthread.h>
gcc false-sharing.c -lpthread
#define N 30000000
#define M 8
time a.out
double s1[M], s2[M], s3[M], s4[M];
void *arbeitsthread(void *arg) {
int i;
double *s = (double *) arg;
*s = rand();
for (i=0; i < N; i++)
*s = *s + i*(*s);
return NULL;
}
real
user
sys
int main(void) {
pthread_t id1, id2, id3, id4;
pthread_create(&id1, NULL, &arbeitsthread,
pthread_create(&id2, NULL, &arbeitsthread,
pthread_create(&id3, NULL, &arbeitsthread,
pthread_create(&id4, NULL, &arbeitsthread,
pthread_join(id1, NULL);
pthread_join(id2, NULL);
pthread_join(id3, NULL);
pthread_join(id4, NULL);
return 0;
}
21.06.2012
&s1);
&s2);
&s3);
&s4);
0m0.261s
0m0.944s
0m0.000s
 s1[0], s2[0], s3[0] und
s4[0] werden jetzt auf
unterschiedliche Cachezeilen
abgebildet
R. Prodan, Betriebssysteme, Sommersemester 2012
69
Multicomputer-Scheduling und
Lastverteilung
 Jeder Knoten hat seinen eigenen Speicher und sein eigenes
Betriebssystem
o Jeder Knoten hat seine festen Prozesse
o Beliebige Scheduling-Verfahren möglich
 Prozessorzuteilung
o Welchem Knoten wird ein neuer Prozess zugewiesen?
o Ziele: Lastausgleich, Minimierung der Kommunikation, ...
o Realisiert in systemnaher Software bzw. Middleware
 Space Sharing: Knoten werden exklusiv an eine Anwendung
zugeteilt
 Auch Gang Scheduling ist möglich oder sinnvoll, erfordert aber
Synchronisation aller Knoten
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
70
Lastverteilungsalgorithmen
a. Senderinitiierter Algorithmus
b. Empfängerinitiierter Algorithmus
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
71
Lastverteilung durch GraphPartitionierung
 Gegeben ist ein Prozesssystem mit
o CPU und Speicheranforderungen
o Angabe der Kommunikationslast zwischen je 2 Prozessen (dargestellt als Graph)
 Gesucht ist eine Aufteilung (Partitionierung) des Graphen so, dass
o CPU- und Speicheranforderungen für jeden Knoten erfüllt wird
o Partitionen in etwa gleich groß sind (Lastausgleich)
o Gewichte-Summe der geschnittenen Kanten minimal (möglichst wenig Kommunikation
zwischen Knoten)
 NP-vollständig, daher viele heuristische Verfahren
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
72
Virtualisierung
 Unternehmen, die unterschiedliche Programme und Servern operieren
o E-Mail-Server, Webserver, FTP-Server, E-Commerce-Server, …
o Benötigt einen Multicomputer aus Performance- und Zuverlässigkeitsgründe
o Nachteil: teure, schwierig zu verwalten, und ineffiziente Lösung
 Lösung: Virtualisierung
o Eine Methode die es ermöglicht, auf einem einzigen Computer viele virtuelle Maschinen unterzubringen
o Jede virtuelle Maschine läuft potenziell unter einem anderen Betriebssystem
o Ein Softwarefehler in einer virtuellen Maschine bringt nicht automatisch die anderen Maschinen zu Fall
 Vorteile der Virtualisierung
o
o
o
o
o
o
Weniger Kosten: Hardwaregeld, Strom, einfachere Wartbarkeit, weniger Platz
Bessere und effizientere Nutzung der Ressourcen
Strenge Isolation der virtuellen Maschinen
Verwaltung heterogener Software (z.B. verschiedene Betriebssysteme, veraltete Programme, Versionen)
Softwareentwicklung von Programmen für mehrere Betriebssysteme
Virtualisierungssoftware hat 200 Mal weniger Codezeilen als ein vollständiges Betriebssystem
 Nachteil: alle virtuelle Maschinen sind auf einem Hardwareserver
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
73
Ursprung der Virtualisierung
 Scientific Center von IBM, Cambridge, Massachusetts (1970)
 VM/370 System
o Timesharing-System soll einen Mehrprogrammbetrieb und eine erweiterte
Maschine mit einer praktischeren Schnittstelle als die reine Hardware zur
Verfügung stellen
o Virtual Machine Monitor
 Trennt Multiprogrammierung von Bereitstellung einer erweiterten Maschine
 Stellt mehrere virtuelle Maschinen bereit, die eine exakte Kopie der blanken
Hardware sind (Kern-/Benutzermodus, Ein-/Ausgabe, Unterbrechungen, …)
o Unterschiedliche Betriebssysteme unterstützt
 OS/360, Conversational Monitor System (CMS)
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
74
Virtuelle Maschine Wiederentdeckt
 IBM setzt seit viel Jahrzehnten virtuelle Maschinen auf
seinen Produkten ein
o Heute werden auf z/VM mehrere virtuelle Linux- und
traditionellen IBM-Betriebssystemen ausgeführt
 Große Firmen haben unlängst ihre High-EndUnternehmensserver mit virtuellen Maschinen
ausgestattet
o Oracle, Sun Microsystems, Hewlett-Packard, etc.
 Webhosting: shared versus dedicated Hosting
 Virtualisierung in Bereich PC weitgehend ignoriert
o Linux und Windows-Systeme gleichzeitig laufen lassen
o Multicore-Technologien
 Virtual Machine Monitor wurde wiederentdeckt und in
Typ-1 Hypervisor umbenannt
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
75
Virtualisierbare Maschinen
 Jede CPU hat sensitive Befehle, die nur in Kernmodus
ausgeführt werden können
o Ein-/Ausgabe, MMU-Einstellungen, Process-Dispatching
o Popek und Goldberk, 1974
 Privilegierte Befehle lösen einen Sprung in Betriebssystem
aus, wenn sie in Benutzermodus ausgeführt werden
 Eine Maschine ist virtualisierbar wenn die sensitiven
Befehle eine Teilmenge der privilegierten Befehle sind
o Wenn man versucht, etwas illegales in Benutzermodus zu tun,
sollte die Hardware eine Unterbrechung auslösen
o Intel 386 hat diese Eigenschaft nicht
 e.g. POPF-Befehlt wurde in Benutzermodus ignoriert
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
76
Virtualisierbare CPUs
 Ab 2005 wurde Virtualisierung von CPUs eingeführt und
unterstützt
o Virtualisierungstechnologie (VT) auf Intel-Core-2-Reihe
o Secure Virtual Machine (SVM) auf den AMD-Pacific-CPUs
 Es wird ein Container erzeugt, in dem die virtuellen
Maschinen laufen
o In einem Container wird ein Gastbetriebssystem gestartet
o Das Gastbetriebssystem bleibt dort bis es eine Ausnahmesituation
erzeugt, die einen Sprung in den Hypervisor auslöst
 E.g. Ein-/Ausgabe Befehl
o Diese Operationen werden von einer Hardwarebitmap gesteuert,
die vom Hypervisor gesetzt wurde
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
77
Typ-1 Hypervisor
 Läuft direkt auf der Hardware
 Virtuelle Maschine läuft als Benutzerprozess im Benutzermodus
 Auf der virtuellen Maschine ist ein Gastbetriebssystem in virtuellen Kernmodus
aufgesetzt
o Glaubt in Kernmodus zu sein, ist aber nicht
 Wenn Gastbetriebssystem einen Systemaufruf ausführt findet ein Sprung in den
Kern statt
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
78
Typ-2 Hypervisor

1990er Jahren: VMware aus DISCO Forschungsprojekt der Universität von Stanford

Wird als Benutzerprogram oberhalb von Gastgeberbetriebssystem ausgeführt

Installiert Gastbetriebssysteme auf einer virtuellen Platte
o Große Datei in Dateisystem des Gastgeberbetriebssystems

Der Code wird nach Basisblöcken abgesucht
o Endet in einem Befehl, wo der Kontrollfluss unterbrochen wird
o Sprung, Aufruf, Unterbrechung, …
o Enthält keinen Befehl, der den Befehlszähler verändert

Basisblöcke ohne sensitive Befehle werden auf der realen Maschine ausgeführt
o Binärübersetzung falls andere Instruktionssatz
o Sensitive Befehle werden durch einer speziellen (VM-ware) Prozeduraufruf ersetzt und emuliert
o In Cache gespeichert um die Performanz zu verbessern

Nicht langsamer als Typ1-Hypervisors
o Viele Unterbrechungen sind auf moderner Hardware sehr teuer (Caches, TLBs)
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
79
Paravirtualisierung

Typ-1 und Typ-2 arbeiten mit nichtmodifizierten Gastbetriebssystemen
o
o
o
o

Müssen aber viele Hürde nehmen um annehmbare Performanz zu erreichen
Emulieren von Hardwarebefehle, Binärübersetzung, Unterbrechungen, …
Mangelnde Verfügbarkeit des Quellcodes für Gastbetriebssystem (Windows)
Enorme Anzahl von Linux-Varianten
Neuer Ansatz: Modifizierter Quellcode, so dass anstelle der Ausführung sensitiver Befehle
ein Hypervisor-Aufruf stattfindet
o Hypervisor muss eine Schnittstelle definieren, die das Gast-Betriebssystem benutzen kann

Wenn man alle sensitive Befehle aus dem Gastbetriebssystem entfernt hat und nur
Hypervisor-Aufrufe zulässt …
o Hat den Hypervisor in einem Mikrokern verwandelt
o Und das Gastbetriebssystem paravirtualisiert
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
80
Virtual Machine Interface
 2 Probleme der Paravirtualisierung
o Wie kann das Gastbetriebssystem auf der eigenen Hardware?
o Wie können mehrere Hypervisoren unterstützt werden?
 VMware, Xen, Viridian, …
 Virtual Machine Interface (VMI)
o Amsden et al., 2006
o Generische maschinennahe Schichte, die eine Schnittstelle zur Hardware des
Hypervisors darstellt
o Nicht an die Hardware oder an einen bestimmten Hypervisor gebunden
 Paravirt Ops
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
81
Speichervirtualisierung

Moderne Betriebssysteme unterstützten fast alle virtuelle Speicher
o Zuordnung von Seiten des virtuellen Adressraumes auf Seiten des physikalischen Speichers
o Erfolgt durch (mehrstufige) Seitentabellen
o CPU Steuerregister wird mit einem Zeiger auf die Seitentabelle der ersten Stufe gesetzt

Hypervisor muss für jede virtuelle Maschine eine Schattenseitentabelle erzeugen
o Abbildung der virtuellen Seiten auf die aktuellen Seiten, die Hypervisor zugewiesen hat
o Jedes Mal wenn das Gastbetriebssystem seine Seitentabellen ändert, muss auch der Hypervisor die
Schattenseitentabellen ändern

Problem für Typ-1 und Typ-2 Hypervisors: Seitentabellen in Gastbetriebssystem werden über
ein normales Schreiben in den Speicher geändert
o Kein sensitiver Befehl, der den Hypervisor darüber informiert

Zukünftige CPU-VT-Versionen sollen das bei der zweistufigen Zuordnung in der Hardware
unterstützen
o Virtuelle Seiten sollen zuerst auf die physische Seite des Gast abgebildet werden
o Seiten des Gastes (immer noch virtuell für Hardware) sollen auf physische Seite der Hardware abbilden

In paravirtualisierten Betriebssystemen informiert der Gastbetriebssystem den Hypervisor
durch einen Aufruf nachdem er seine Seitentabellen geändert hat
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
82
Ein- / Ausgabevirtualisierung

Gastbetriebssystem testet die Hardware um herauszufinden, welche Ein-/Ausgabegeräte
angeschlossen sind
o Sensitiver Befehl, der einen Spring in Hypervisor auslöst

Treiber laden um die Geräte zu benützen
o Sensitive Befehle, um die Geräteregister lesen und schreiben zu dürfen

Problem: jedes Gastbetriebssystem denkt, dass eine ganze Plattenpartition besitzt

Lösung: Hypervisor erzeugt eine Datei oder einen Bereich auf der realen Platte für die
physischen Platten aller virtuellen Maschinen
o Die Blocknummer wird in einen Offset innerhalb der Datei oder des Bereichs umgeformt

Gastbetriebssystem könnte eine andere Platte benutzen als wirklich vorhanden ist
o Vorhanden: Hochleistung oder RAID-Platte
o Hypervisor bietet dem Gast-Betriebssystem eine alte IDE-Platte und wandelt die Kommandos um

Spezielle I/O MMU Hardware für virtualisierte DMA Ein-/Ausgabe

Xen Ansatz: Domain 0 virtuelle Maschine ist für alle Ein-/Ausgabe Aufrufe zuständig
21.06.2012
R. Prodan, Betriebssysteme, Sommersemester 2012
83