Systeme 1 Kapitel 8.3 Betriebssystemaufgaben Kapitel 9.1 Betriebssysteme auf aktueller Hardware WS 2009/10

Letzte Vorlesung Vergleich Seitenersetzungsstrategien Algorithmus Bewertung Optimal Unrealisierbar, gedacht für Vergleiche NRU (Not Recently Used) Sehr primitiv FIFO (First-In, First-Out) Wichtige Seiten können entfernt werden. Second Chance Enorme Verbesserung gegenüber FIFO Clock Realistisch LRU (Least Recently Used) Exzellent, schwierig zu implementieren NFU (Not Frequently Used) Unoptimiert mit LRU vergleichbar Aging Optimierter Algorithmus, der fast LRU erreicht. Working set Etwas aufwändig in der Implementierung WSClock Guter und effizienter Algorithmus In der Realität wird insbesondere WSClock eingesetzt. WS 2009/10

Letzte Vorlesung Beladys Anomalie: Beispiel LRU Zusammenfassung Wenn auf eine Seite zugegriffen wird, wird sie nach oben geschoben. Wenn die Seite vorher schon in M war, verschieben sich alle Einträge über ihr um eine Zeile nach unten. Die Einträge unterhalb bleiben unverändert. 2 1 3 5 4 6 7 P WS 2009/10

Keller-Algorithmen Der LRU Algorithmus aus dem vorherigen Beispiel zeigte eine besondere Eigenschaft: wobei m die Anzahl der verfügbaren Seitenrahmen, und r der Index der Referenzkette ist. D.h., wenn das Programm ein zweites Mal auf einem Interpreter mit m + 1 Seitenrahmen gestartet wird, so sind zu jedem Zeitpunkt alle Seiten im Speicher, die beim ersten Durchlauf im Speicher waren und zusätzlich eine weitere. Eine ganze Klasse von Algorithmen erfüllt diese Eigenschaften, die sogenannten Keller-Algorithmen (Stack-Algorithmen). Diese Klasse von Algorithmen ist nicht anfällig für die Belady Anomalie! WS 2009/10

Distanzkette Abstraktere Art der Repräsentation einer Referenzkette Eine Distanzkette ist definiert als Abstand einer Seite zum oberen Tabellenende bei deren Zugriff. Ist eine Seite noch nicht in M, so ist ihr Abstand ∞. 2 1 3 5 4 6 7 P ∞ Distanzkette für M WS 2009/10

Distanzkette Eine Distanzkette wird verwendet, um die Anzahl der Seitenfehler für verschiedene Speichergrößen vorherzusagen. Dazu wird die Distanzkette durchlaufen und das Vorkommnis jedes auftretenden Abstands gezählt. 2 1 3 5 4 6 7 P ∞ Abstand Anzahl 1 4 2 3 5 6 7 ∞ 8 WS 2009/10

Distanzkette Die Formel Beispiel: beschreibt dann die Anzahl der Seitenfehler Fm einer gegebenen Distanzkette, wobei Di die Häufigkeit des Abstands i bezeichnet, n die Anzahl der virtuellen Seiten und m die Anzahl der verfügbaren Seitenrahmen ist. Beispiel: F1 F2 F3 F4 F5 F6 F7 F∞ 20 17 16 11 9 8 WS 2009/10

Lokale und Globale Strategien Seitenersetzungsalgorithmen wurden bisher nur für einzelne Prozesse betrachtet (lokale Strategien). In der Praxis laufen jedoch meist mehrere Programme (quasi-)parallel. D.h. der zur Verfügung stehende physikalische Speicher, muss unter den Prozessen aufgeteilt werden: Bekommt beispielsweise ein Prozess für die komplette Laufzeit eine feste Speichergröße zugeordnet, die kleiner als die maximal benötigte ist, so erzeugt der Prozess ständig Seitenfehler, obwohl u.U. noch freie Seitenrahmen auf dem System zur Verfügung stehen. D.h. eine dynamische Aufteilung des Speichers wird notwendig. WS 2009/10

Globale Paging Strategien Eine globale Paging Strategie sollte den Prozess mit einer sinnvollen Speichergröße ausstatten und diese während der Ausführung dynamisch anpassen. Beispiel: Der Page Fault Frequency (PFF) Algorithmus: Dieser Algorithmus misst die Anzahl der Seitenfehler eines Prozesses in einem Zeitintervall. Ist die Seitenfehlerrate eines Prozesses über Whigh, bekommt der Prozess einen zusätzlichen Seitenrahmen. unter Wlow, verliert der Prozess einen Seitenrahmen. Der Prozess nutzt dabei die Eigenschaften der Keller-Algorithmen (monoton fallende Seitenfehlerrate bei zusätzlichen Speicherrahmen)‏. WS 2009/10

Gemeinsame Seiten Führen zwei Prozesse das selbe Programm aus, ist es effizienter, Seiten gemeinsam zu nutzen, als mehrere Kopien der selben Seite im Speicher zu halten. Seiten auf die nur lesend zugegriffen wird, können gemeinsam genutzt werden. Seiten auf die auch schreibend zugegriffen wird, ist eine gemeinsame Nutzung in der Regel nicht möglich. Einfache Lösung: Zwei getrennte Adressräume für Daten und Programmcode. Zwei getrennte Seitentabellen pro Prozess. Gemeinsame Nutzung von Programmcode recht einfach möglich. WS 2009/10

Gemeinsame Seiten Gemeinsame Nutzung von Datenseiten ebenfalls möglich aber komplizierter. Beispiel: UNIX-Befehl fork() fork() erstellt eine exakte Kopie eines laufenden Prozesses. Beide Prozesse verfügen über eine eigene Seitentabelle, deren Einträge zeigen zunächst auf die selben Seitenrahmen. D.h. es werden zunächst keine Daten kopiert. Alle Datenseiten werden als READ_ONLY markiert. Sobald ein Prozess schreibend auf eine Seite zugreift, wird eine Schutzverletzung erkannt und diese Seite kopiert. Das READ_ONLY Flag gelöscht. Dieses Verfahren wird copy-on-write genannt und erhöht die Systemleistung, da in der Regel weniger Seiten kopiert werden müssen. WS 2009/10

Kapitel 9.1 Betriebssysteme auf aktueller Hardware WS 2009/10

Zukünftige Bedeutung von NUMA-Hardware Interview J. Goslin, Java Magazin, Februar 2008 „ … es ist ziemlich eindeutig, dass Moore‘s Law nicht mehr die Taktrate sondern die Zahl der Kerne misst. Es scheint so, als ob sich die Anzahl der Kerne alle paar Jahre verdoppelt. In zehn Jahren etwa werden wir bei 128 CPUs liegen. In so einer Umgebung muss man ganz anders über Programmierung an sich denken.“ James Goslin, Sun Microsystems Erfinder der Programmiersprache Java Konsequenz: Forschung- und Entwicklungsschwerpunkt von allgemeinen Betriebssystemen verlagert sich. Betriebssysteme werden spezifischer auf Hardware mit einer großen Zahl von Prozessorkernen angepasst. WS 2009/10

Moore‘s Gesetz Das Mooresche Gesetz (Moore, 1965, 1975 Korrektur) Die Komplexität integrierter Schaltkreise (mit minimalen Komponentenkosten) verdoppelt sich etwa alle zwei Jahre. Komplexitätsmaß: Zahl elementarer Schaltkreise auf Chip (auch pro Fläche) Moore, 2007 (Intel Forum): Gesetz hat wahrscheinlich noch 10 bis 15 Jahre Bestand, bevor fundamentale Grenze erreicht ist. Gordon Moore Intel Mitbegründer WS 2009/10

Moore‘s Gesetz WS 2009/10

Moore‘s Law und Multiprozessor-Systeme Während Moores Gesetz mit enormen Geschwindigkeitszuwächsen für Computersysteme im allgemeinen einherging, konnten Multiprozessor-Systeme nur begrenzt davon profitieren: Elektrische Effekte begrenzen die Geschwindigkeiten zwischen den CPUs und erhöhen die Latenz zwischen CPU und Speicher. Größerer Hauptspeicher erhöht die Komplexität für die Umsetzung von logischen in physikalische Adressen und erhöht damit die Zugriffszeit auf Speicher. Speicherlatenz kann von manchen Prozessoren mit „out-of-order“ bzw. spekulativer Ausführung von Befehlen kompensiert werden. Auf Shared Memory Multiprocessor Systemen SMMP muss aber ein streng sequentieller Ablauf garantiert werden. WS 2009/10

Aufbau eines modernen PCs PC-Architektur wurde an immer höhere Taktraten angepasst Northbridge liegt zwischen CPU und Southbridge und kommuniziert mit RAM. Southbridge kommuniziert mit Northbridge und externen Devices mit Schnittstellen, z.B. PCI, PCI-Express, USB, SATA. Bei Mehrkern Prozessoren (z.B. Dualcore) mehrere Memory Controller Intel: Northbridge mit Memory-Crtl. , AMD: CPU mit lokalem Speicher CPU Northbridge Southbridge RAM PCI-E SATA USB CPU Northbridge Southbridge MC1 PCI-E SATA USB MC2 MC3 MC4 RAM WS 2009/10

Aufbau eines modernen PCs Verschiedene Ansätze reduzieren den sogenannten Flaschenhals, die Transferzeiten z.B. zwischen RAM u. CPU Mehrere Memory-Controller kommunizieren mit Northbridge. Jede CPU kommuniziert direkt mit einem Memory Controller. Nachteil: jede CPU sieht nur ihren Speicherausschnitt, Transfers CPU<->CPU nötig Bezeichnung dieser Architekturen: NUMA non-uniform memory architecture Einige Speicherbereiche liegen physikalisch an anderen Bussen, daher gibt es unterschiedliche Zugriffskosten. NUMA-Factor: Kommunikationskosten einer Architektur Spezielle NUMA-Hardware muss vom OS geeignet behandelt werden. WS 2009/10

NUMA – Hardware und ihre OS-Integration Betriebssystemunterstützung von NUMA-Hardware CPU mit lokalem RAM sollte möglichst Prozesse auf lokalem RAM ausführen Das Code-Segment (Text-Segment, enthält auszuführende Maschineninstruktionen) wird von mehreren CPUs verwendet Lösung: Spiegelung des Code-Segmentes in den lokalen RAM-Bereich jeder CPU Prozess-Migration Ein Prozess sollte möglichst nicht auf eine andere CPU migriert werden (Transfer-Kosten). Falls Migration nötig: Wahl eines Prozessors mit geringerer Last Wahl eines Prozessors mit niedrigen RAM-Zugriffs-/Transferkosten (z.B. Nachbar-CPU) Größe des lokalen Speicherbereich Kann – bei unterschiedlichem Prozessbedarf – variieren Der Speicherbedarf jeder CPU muss dynamisch angepasst werden. WS 2009/10

Probleme beim konkurrierenden Speicherzugriff Thread1 Thread2 Thread3 P1 P2 P3 Shared-memory multiprocessors (SMMP) können nebenläufig mehrere Threads ausführen, die mit Datenstrukturen im gemeinsam genutzten Speicher (shared memory) kommunizieren und synchroni- siert werden müssen. Concurrent data structures Shared Memory Beim Design entsprechender Datenstrukturen müssen folgende Eigenschaften berücksichtigt werden: Nebenläufigkeit (Concurrency) Performanz Korrektheit Skalierbarkeit WS 2009/10

Beispiel: Datenstruktur shared counter Operation fetch-and-inc Ein Wert wird aus einer Speicherzelle gelesen und um 1 erhöht. Beispielszenario Threads T1, T2 (verschiedene CPUs) Sequentielles fetch-and-inc Lock-basiertes fetch-and-inc Richtige Ergebnisse, jedoch Sequentieller Flaschenhals Blockierung Contention (Konkurrenzsituation) oldval = X; X = oldval+1; return oldval; aquire(lock(X)); oldval = X; X = oldval+1; release(lock(X)); return oldval; 00 11 T1 0+1 Return 0 T2 00 12 T1 0+1 Release Lock Return 0 T2 1+1 Release lock Return 1 Require lock Rejected lock Fehler: beide liefern 0! Schlechtes Interleaving WS 2009/10

Probleme einfacher lock-basierter shared counter 1. Sequentielles Flaschenhalsproblem – zunächst: der Idealfall Die Beschleunigung skalierbarer Datenstrukturen steigt mit P Beispiel: Applikation benötigt 1 s auf einem Prozessor Auf 10 Prozessoren benötigt diese 0.1 sec. Die Beschleunigung ist B=1 sec / 0.1 sec = 10 WS 2009/10

Sequentielles Flaschenhalsproblem Amdahls Gesetz: Sei b der prozentuelle Anteil eines Programms, der nur sequentiell ausgeführt werden kann (seq. bottleneck). Die Beschleunigung B bei P Prozessoren ist: Beispiel: b=10%, P=10 Es wird also wegen b=10% nur etwa die Hälfte der möglicher Maschinenkapazität genutzt. WS 2009/10

Probleme einfacher lock-basierter shared counter Steigerung der Performance durch: Reduzierung Länge des sequentiell bottlenecks Reduzierung der Lockgranularität Reduzierung der Anzahl der Locks Weitere Probleme: (Memory-) Contention: Ein Overhead im Datenaustausch der zugrundeliegenden Hardware, da viele Threads nebenläufig z.B. auf die selbe Speicheradresse zugreifen. (auch Cache-Probleme). Blockierung (Lock-Contention): Wenn der Thread, der gegenwärtig einen Lock hält, verzögert wird, werden alle anderen Threads, die versuchen auf dieselbe Ressource zuzugreifen ebenfalls verzögert. WS 2009/10

Nichtblockierende Techniken mit Operationen Der einfache Lock-freie shared Counter hat das Problem, dass bei ungünstigem Interleaving unkorrekte Ergebnisse entstehen können. Lösung mit Operation CAS (Compare And Swap): Hardware Operation, die atomar das Laden und Speichern kombiniert. CAS-Operation im Pseudocode: Bool CAS(L, E, N) { // L Speicheradresse, E Referenzwert, N neuer Wert atomically { if (*L == E) { // Vergl. Wert an Adresse L mit E *L = N; // Zuweisung: Wert an Adresse L jetzt N return true; } else return false; WS 2009/10

Umsetzung nicht-blockierender Counter mit CAS Einfache Umsetzung Counter jeweils T1, T2: while (!CAS(X,*X,X+1)); Lockfreie Alternative für fetch-and-inc Herlihy 1991: Operationen, wie CAS oder LL/SC (load-linked/ stored-conditional) sind universell. Jede nebenläufige Datenstruktur kann wait-free realisiert werden, falls ein System diese Operationen unterstützt. wait-free bedeutet: eine Operation terminiert - ungeachtet dem Zeitverhalten andere Operationen - garantiert nach endlich vielen Schritten. WS 2009/10

Nichtblockierende Synchronisation Aufbauend auf primitiven Operationen wie z.B. CAS, können auch Algorithmen für komplexere Datenstrukturen entwickelt werden. Diese Algorithmen nutzen die selben Strategien, um nichtblockierende Synchronisation zu gewährleisten. Beispiel: Soll ein Prozess eine globale Datenstruktur verändern, so erstellt er zunächst eine Kopie dieser. Anschließend verändert er die Kopie. Haben sich die Originaldaten in dieser Zeit nicht verändert, so wird diese Kopie zur neuen globalen Datenstruktur. Haben sich die Daten verändert, verwirft der Prozess seine geänderte Kopie und versucht es erneut. WS 2009/10

Nichtblockierende Synchronisation Ausgangspunkt Zwei Prozesse Eine globale Liste mit den Elementen A,B,C Prozess 1 möchte Element D einfügen Prozess 2 möchte Element B löschen A B C Pointer WS 2009/10

Nichtblockierende Synchronisation Prozess 1 und Prozess 2 erzeugen jeweils eine private Kopie der Liste A B C Pointer A B C D Process 1 A C Process 2 WS 2009/10

Nichtblockierende Synchronisation Prozess 1 ist schneller fertig und seine Änderung wird wirksam. A B C Pointer A B C D Process 1 A C Process 2 WS 2009/10

Nichtblockierende Synchronisation Prozess 2 muss seine Änderung verwerfen und erneut beginnen. A B C D Pointer A C D Process 2 A B C D Pointer A C D Process 2 WS 2009/10

Nichtblockierende Synchronisation Fokus auf Lock-Contention Schwerpunkt um 1990 (u.A. Herlihy). Speicherlatenz spielte noch keine so große Rolle. Zwar können solche nichtblockierenden Techniken ohne explizite Locks auskommen, jedoch bleibt erhöhter Kommunikationsaufwand zwischen den CPUs erhöhte Speicherlatenz. Einführung einer neuen Art von Overhead durch wiederholte Versuche. WS 2009/10

Speicherlatenz: Beispiel Ein Programm mit zwei Variablen. Beide sind zunächst im Hauptspeicher. CPU 0 Cache CPU 1 Memory A B WS 2009/10

Speicherlatenz: Beispiel CPU 1 lädt Variable A und modifiziert diese. CPU 2 lädt Variable B und modifiziert diese. Beide CPUs besitzen nun jeweils eine Kopie des Wertes in ihrem lokalen Cache. CPU 0 Cache CPU 1 Cache A B Memory A B WS 2009/10

Speicherlatenz: Beispiel CPU 0 greift jetzt lesend auf Variable B zu. Beide CPUs haben jetzt jeweils eine Kopie von B in ihrem Cache. In dieser Situation muss jedes Mal, wenn CPU 1 den Wert von B ändert, CPU 0 gezwungen werden, den Wert von B zu validieren. CPU 0 Cache CPU 1 Cache CPU 0 Cache CPU 1 Cache A B B A B B Memory Memory A B A B WS 2009/10

Speicherbarrieren Die Reihenfolge von Lese- und Schreibzugriffen kann von der Hardware / CPU bei Bedarf geändert werden. „Weak Memory-Consistency Semantics“ Erhöht im Normalfall die Systemleistung Erschwert die Synchronisation von SMMP CPUs besitzen Spezielle Befehle zum Unterbinden dieses Verhaltens. Memory Barriers Kosten Performance, insbesondere bei langen CPU-Pipelines. WS 2009/10

Asymmetrische Synchronisation Für bestimmte Fälle kann man die Speichersynchronisation vereinfachen Beispiel: „split-counter“ Nutze Kommutativgesetz der Addition: Ein Zähler kann über mehrere CPUs unabhängig (ohne Synchronisation) erhöht werden. Synchronisationsoverhead wird auf Lesezugriff verschoben: Dann müssen von allen CPUs die Werte zu einem Wert zusammengezählt werden: Jedoch nur sehr begrenzte Einsatzmöglichkeiten: Zum Beispiel: Statistiken (TCP/IP Paketzähler etc…) WS 2009/10

Beispiel: Hash-Tabelle Ausgangspunkt: Bereits gefüllte Hash-Tabelle. Potentiell (seltene) Updates. Elemente Eintrag 0 Vorgehen: 1.) Sichere exklusiven Zugriff 2.) Berechne Hash Wert 3.) Suche Element 4.) Freigabe Eintrag 1 Elemente … Elemente Eintrag 30 Eintrag 31 Elemente WS 2009/10

Beispiel: Hash-Tabelle 1 2 3 4 5 10 15 20 25 30 35 Hash Table Searches per Microsecond # CPUs „ideal“ „global“ Bei diesem einfachen Beispiel hat das Hinzufügen von weiteren CPUs sogar negative Effekte. In diesem Beispiel wird hauptsächlich lesend auf die Tabelle zugegriffen, dennoch muss dieser Zugriff vor potentiell (seltenen) schreibenden Zugriffen geschützt werden. Frage: Wie kann man solche Zugriffsmuster ausnutzen ? Quelle: Paul E. McKenney „Exploiting Deferred Destruction: An Analysis of Read-Copy-Updates Techniques in Operating System Kernels“, Dissertation Oregon State University, July 2004. WS 2009/10