Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Systeme 1 Kapitel 8.3 Betriebssystemaufgaben Kapitel 9.1 Betriebssysteme auf aktueller Hardware WS 2009/101."—  Präsentation transkript:

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

2 Letzte Vorlesung Vergleich Seitenersetzungsstrategien WS 2009/102 AlgorithmusBewertung OptimalUnrealisierbar, gedacht für Vergleiche NRU (Not Recently Used)Sehr primitiv FIFO (First-In, First-Out)Wichtige Seiten können entfernt werden. Second ChanceEnorme Verbesserung gegenüber FIFO ClockRealistisch LRU (Least Recently Used)Exzellent, schwierig zu implementieren NFU (Not Frequently Used)Unoptimiert mit LRU vergleichbar AgingOptimierter Algorithmus, der fast LRU erreicht. Working setEtwas aufwändig in der Implementierung WSClockGuter und effizienter Algorithmus In der Realität wird insbesondere WSClock eingesetzt.

3 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. WS 2009/ PPPPPPPPPPP

4 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/104

5 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. WS 2009/ PPPPPPPPPPP Distanzkette für M

6 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. WS 2009/ PPPPPPPPPPP AbstandAnzahl

7 Distanzkette Die Formel – beschreibt dann die Anzahl der Seitenfehler F m einer gegebenen Distanzkette, – wobei D i die Häufigkeit des Abstands i bezeichnet, – n die Anzahl der virtuellen Seiten und – m die Anzahl der verfügbaren Seitenrahmen ist. Beispiel: WS 2009/107 F1F2F3F4F5F6F7F

8 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/108

9 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 W high, bekommt der Prozess einen zusätzlichen Seitenrahmen. unter W low, verliert der Prozess einen Seitenrahmen. – Der Prozess nutzt dabei die Eigenschaften der Keller- Algorithmen (monoton fallende Seitenfehlerrate bei zusätzlichen Speicherrahmen). WS 2009/109

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/1010

11 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/1011

12 Systeme 1 Kapitel 9.1 Betriebssysteme auf aktueller Hardware WS 2009/1012

13 Zukünftige Bedeutung von NUMA-Hardware Interview J. Goslin, Java Magazin, Februar 2008 … es ist ziemlich eindeutig, dass Moores 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. WS 2009/1013 Konsequenz: Forschung- und Entwicklungsschwerpunkt von allgemeinen Betriebssystemen verlagert sich. Betriebssysteme werden spezifischer auf Hardware mit einer großen Zahl von Prozessorkernen angepasst. James Goslin, Sun Microsystems Erfinder der Programmiersprache Java

14 Moores 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. WS 2009/1014 Gordon Moore Intel Mitbegründer

15 Moores Gesetz WS 2009/1015

16 Moores 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/1016

17 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 WS 2009/1017 CPU Northbridge Southbridge RAM PCI-E SATA USB CPU Northbridge Southbridge MC 1 PCI-E SATA USB MC 2 MC 3 MC 4 CPU RAM

18 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/1018

19 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/1019

20 Probleme beim konkurrierenden Speicherzugriff Beim Design entsprechender Datenstrukturen müssen folgende Eigenschaften berücksichtigt werden: 1.Nebenläufigkeit (Concurrency) 2.Performanz 3.Korrektheit 4.Skalierbarkeit WS 2009/1020 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. P1 P2 P3 Concurrent data structures Shared Memory Thread1Thread2Thread3

21 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) WS 2009/1021 Sequentielles fetch-and-inc oldval = X; X = oldval+1; return oldval; Lock-basiertes fetch-and-inc aquire(lock(X)); oldval = X; X = oldval+1; release(lock(X)); return oldval; Richtige Ergebnisse, jedoch Sequentieller Flaschenhals Blockierung Contention (Konkurrenzsituation) T1 0+1 Return 0 T2 0+1 Return 0 T1 0+1 Release Lock Return 0 T2 1+1 Release lock Return 1 Require lock Rejected lock Fehler: beide liefern 0! Schlechtes Interleaving

22 Probleme einfacher lock-basierter shared counter 1. Sequentielles Flaschenhalsproblem – zunächst: der Idealfall Die Beschleunigung skalierbarer Datenstrukturen steigt mit P WS 2009/1022 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

23 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/1023

24 Probleme einfacher lock-basierter shared counter Steigerung der Performance durch: I.Reduzierung Länge des sequentiell bottlenecks II.Reduzierung der Lockgranularität III.Reduzierung der Anzahl der Locks Weitere Probleme: 2.(Memory-) Contention: Ein Overhead im Datenaustausch der zugrundeliegenden Hardware, da viele Threads nebenläufig z.B. auf die selbe Speicheradresse zugreifen. (auch Cache-Probleme). 3.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/1024

25 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. WS 2009/1025 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; } CAS-Operation im Pseudocode:

26 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/1026

27 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/1027

28 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 WS 2009/1028 A A B B C C Pointer

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

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

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

32 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/1032

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

34 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. WS 2009/1034 CPU 0 Cache CPU 1 Cache Memory AB AB

35 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. WS 2009/1035 CPU 0 Cache CPU 1 Cache Memory AB AB CPU 0 Cache CPU 1 Cache Memory AB ABBB

36 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/1036

37 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/1037

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

39 Beispiel: Hash-Tabelle 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 ? WS 2009/ Hash Table Searches per Microsecond # CPUs ideal global Quelle: Paul E. McKenney Exploiting Deferred Destruction: An Analysis of Read-Copy-Updates Techniques in Operating System Kernels, Dissertation Oregon State University, July 2004.


Herunterladen ppt "Systeme 1 Kapitel 8.3 Betriebssystemaufgaben Kapitel 9.1 Betriebssysteme auf aktueller Hardware WS 2009/101."

Ähnliche Präsentationen


Google-Anzeigen