Betriebssysteme Sommersemester 28 Betriebssysteme 7. Kapitel Effiziente Speicherverwaltung 7. Virtualisierung und Caching 7. Virtualisierung und Caching schneller, teurer, kleiner Register Cache Hauptspeicher Prof. Matthias Werner Professur Betriebssysteme langsamer, billiger, größer Massenspeicher (Magnetplatte, Solid State Disk,...) Archiv (Band, CD-ROM,...) In diesem Kapitel diskutieren wir das Zusammenspiel der einzelnen Hierachiestufen SoSe 28 M. Werner 2 / 36 osg.informatik.tu-chemnitz.de 7. Virtualisierung und Caching Lokalitätsprinzip 7. Virtualisierung und Caching Lokalitätsprinzip (Forts.) Speicherhierarchie beruht auf dem Lokalitätsprinzip (Principle of locality) Programm greift in kleinem Zeitraum t nur auf kleinen Teil seines Adressraums A zu Prinzip der räumlichen Lokalität Wird auf eine Adresse a zugegriffen, so ist Zugriff auf eine Adresse in der Nähe von a wahrscheinlich. Beispiel: Nach den von-neumann-prinzipien werden Programme sequentiell ausgeführt (solange kein Sprung erfolgt) nächster Befehl liegt in der Nähe des aktuellen Prinzip der zeitlichen Lokalität Wird auf eine Adresse a zugegriffen, so ist erneuter Zugriff auf a in Kürze wahrscheinlich. Beispiel: Wird eine Variable geschrieben, wird sie vermutlich bald gelesen oder wiederum geschrieben Häufig gelten beide Prinzipien gleichzeitig, z.b. beim Zugriff auf Arrays SoSe 28 M. Werner 3 / 36 osg.informatik.tu-chemnitz.de SoSe 28 M. Werner 4 / 36 osg.informatik.tu-chemnitz.de
7. Virtualisierung und Caching Caching vs. Virtualisierung Schicht k- Schicht k Schicht k+ Caching Virtualisierung transparent sichtbar transparent Programmierer/Nutzer einer Speicherhierarchie sieht i.d.r. nicht alle Schichten einige sind transparent Zugriffe beziehen sich auf Schicht k De-facto-Zugriff auf Schicht k Caching De-facto-Zugriff auf Schicht k + Virtualisierung Durch Caching werden die Zugriffe schneller, durch Virtualisierung wird Kapazität größer 7. Virtualisierung und Caching Flüchtiger vs. Permanenter Speicher Bedingt durch die eingesetzten Medien sind die oberen Ebenen der Speicherhierachie flüchtig, die unteren permanent Entsprechend werden sie eingesetzt z.b. Programmvariablen vs. persistente Daten Problem: Caching und Virtualisierung führen zur Aufweichung dieser Einteilung Unerwünschte Speicherung Unerwarteter Ausfall flüchtiger Speicher temporäre Daten (Programmvariablen) nichtflüchtiger Speicher permanente Daten (Dateien) Datei -Cache Caching Dateien Programm AR Virtualisierung Paging area Hauptspeicher Magnetplatte SoSe 28 M. Werner 5 / 36 osg.informatik.tu-chemnitz.de 7. Virtualisierung und Caching Caching und Betriebssystem Das Caching des Hauptspeichers erfolgt unmittelbar durch die Hardware Kurs Rechnerarchitektur Gegebenenfalls muss das Betriebssystem den Cache konfigurieren, z.b. welche Speicherbereiche werden durch einen Cache abgedeckt welches ist die Rückschreib-Strategie (write trough vs. write back) wie verhält sich der Cache bei konkurrierendem Zugriff Greift das Betriebssystem in die Speicherabbildung ein (häufig bei streuender Adressabbildung), müssen ggf. Caches invalidiert (ungültig gemacht) werden Dies gilt ggf. auch für den TLB Das Caching tieferer Schichten der Speicherhierachie ist ummittelbare Sache des Betriebssystems SoSe 28 M. Werner 6 / 36 osg.informatik.tu-chemnitz.de 7. Virtualisierung und Caching Zuständigkeit während der Ausführung Zuständigkeit Hardware Hardware Betriebssystem Betriebssystem, Benutzer Prozessorregister Cache Hauptspeicher Magnetplatte Magnetband Transfereinheit Wort (z.b. 8 Byte) Cache-Line (z.b. 64 Byte) Plattenblock (z.b. 4KByte) Datei (variabel) Transport der Daten und Befehle zwischen Hauptspeicher, Cache und Prozessor wird von der Hardware direkt erledigt Zugriffe auf die Platte sind Aufgabe des Betriebssystems Aus- und Einlagern von Dateien auf/vom Archivspeicher wird entweder explizit vom Benutzer angestoßen oder automatisch vom Betriebssystem (Dateisystem) durchgeführt SoSe 28 M. Werner 7 / 36 osg.informatik.tu-chemnitz.de SoSe 28 M. Werner 8 / 36 osg.informatik.tu-chemnitz.de
Methoden Häufig ist der Hauptspeicher nicht hinreichend für alle Prozesse Daher gibt es mehrere Ansätze, größeren Speicher aus der Speicherhierachie (Festplatte) zu nutzen: Swapping : ein Prozess läuft nur, wenn er vollständig im Hauptspeicher ist; Prozesse werden wiederholt vollständig ein- und ausgelagert z.b. frühes UNIX Memory Overlay: Prozesse betreiben eigenes Speichermanagement und lagern Teile ihres Speichers in Dateien ein und aus z.b. häufig in MS-DOS Demand Paging: Prozesse laufen auch wenn nur ein Teil von ihnen im Hauptspeicher liegt fast alle modernen Betriebssysteme Demand Paging Idee: Automatisierte Verknüpfung von streuender Adressierung und Speicherhierachie Nicht benötigte Speicherbereiche werden auf Platte ausgelagert und auf Anforderung eingelagert Demand Paging Für Benutzer/Programmierer transparent Mengenbeschränkung des Hauptspeichers wird ersetzt durch Mengenbeschränkung des Auslagerungsmediums (praktisch unbegrenzt) Dieser unbegrenzte Speicher ist jedoch nur virtuell vorhanden Demand Paging ist State of the Art und wird im Folgenden betrachtet Achtung: Aus historischen Gründen wird der Begriff Swapping auch dort gebraucht, wo er technisch nicht korrekt ist. SoSe 28 M. Werner 9 / 36 osg.informatik.tu-chemnitz.de Datenstrukturen Abwesenheit einer Speicherseite muss automatisch von der Hardware erkannt werden Zugriff auf nicht vorhandene Seite löst Unterbrechung (Trap) aus Seitenfehler Zusätzliche Verwaltungsinformationen notwendig: Seite im Hauptspeicher vorhanden? Präsenzbit (presence bit, valid bit), nicht bei invertierter Seitentabelle Frame belegt/frei? Belegungsbit (occupation bit), nur bei invertierter Seitentabelle Dokumentation des Seitenzugriffs? Referenzinformation, evtl. nur ein Bit (reference bit) Seite verändert? Modifikationsbit (dirty bit) Ggf. Rechte Ggf. TLB-Konfigurationsinformationen SoSe 28 M. Werner / 36 osg.informatik.tu-chemnitz.de SoSe 28 M. Werner / 36 osg.informatik.tu-chemnitz.de Seitentabelle bei virtuellem Speicher Seiten Seitentabelle Modifikation Zugriff (Referenzierung) Präsenz Speicher (Kacheln) Typisch: Jeder Prozess hat eigene Seitentabelle gleiches Speicherlayout aus Prozesssicht (vgl. Kapitel??) Mitunter zusätzliche inverse Seitentabelle SoSe 28 M. Werner 2 / 36 osg.informatik.tu-chemnitz.de
Beispiel: Seitentabelleneintrag bei X86 Res (writable on MP Systems) Res Res Global Reserved bits Res (large page if PDE) are used only Dirty when PTE is not valid Accessed Cache disabled Write through Owner Write (writable on MP Systems) 3 2 frame number U P Cw Gi L D A Cd Wt O W V valid 29 Ablauf beim Seitenfehler Seitenfehler leerer Frame verfügbar? nein Frame zum Leeren auswählen ja Seite modifiziert? ja nein Seite auslagern auf Ersatzspeicher Neue Seite einlagern von Ersatzspeicher zeitintensiv! Strategieproblem Update Tabelle(n) SoSe 28 M. Werner 3 / 36 osg.informatik.tu-chemnitz.de Nebenläufigkeit Seitentausch verlangt I/O zeitaufwendig möglichst vermeiden (nur modifizierte Seiten schreiben) Vermeidung von unnötiger Blockierung durch Erhöhung der Nebenläufigkeit ISR des Seitenfehlers erledigt nicht den (synchronen) Plattenzugriff! ISR blockiert auslösenden Prozess und weckt Seitentauscher Seitentauscher (eigener Prozess) organisiert den Seitentausch asynchrone Interaktion mit der Hardware Je nach Strategie wird nicht nur auslösende Seite ersetzt, sondern ggf. mehr (Lokalitätsprinzip) Da Seitenfehler oft stoßweise auftreten z.t. weitere Erhöhung der Nebenläufigkeit durch Frameleerer, der präventiv einen Vorrat freier Seitenrahmen organisiert SoSe 28 M. Werner 4 / 36 osg.informatik.tu-chemnitz.de 7.2. Auswahlstrategien Seitenfehlerrate hängt davon ab, welche Seiten im Hauptspeicher gehalten und welche ausgelagert werden Globale vs. lokale Sicht: Werden nur Seiten des den Seitenfehler auslösenden Prozesses betrachtet oder alle? Lokale Sicht: Konzept der Working Sets: (Maximale) Anzahl von Seiten, auf die bei einem Prozess ohne Seitenfehler zugegriffen werden kann Das Bestimmen der Größe von Working-Sets kann eigene Strategie benötigen Ersetzungsstrategie (policy): Welche Auswahl minimiert die Anzahl der Seitenfehler? Globale/lokale Sicht und Ersetzungsstrategie sind orthogonal SoSe 28 M. Werner 5 / 36 osg.informatik.tu-chemnitz.de SoSe 28 M. Werner 6 / 36 osg.informatik.tu-chemnitz.de
Zufällige Auswahl Betrachten zur Bewertung verschiedene Strategien im Folgenden stets dieses Beispiel: Speichergröße: 3 Seitenrahmen Referenzsequenz: 2 4 3 2 3 3 2 Beispiel bei zufälliger Strategie Zeit: 2 3 4 5 6 7 8 9 2 Referenz: 2 4 3 2 3 3 2 Rahmen 2 2 2 2 2 2 Rahmen 2 2 2 3 3 3 3 3 3 Rahmen 3 4 4 4 4 4 2 7 Seitenersetzungen, Seitenfehler Ergebnis könnte natürlich schlechter oder besser sein (aber wie gut maximal?) FIFO SoSe 28 M. Werner 7 / 36 osg.informatik.tu-chemnitz.de FIFO: Seiten werden in der gleichen Reihenfolge aus- wie eingelagert Zeit: 2 3 4 5 6 7 8 9 2 Referenz: 2 4 3 2 3 3 2 Rahmen 3 3 3 3 3 3 3 3 2 Rahmen 2 2 2 2 2 2 Rahmen 3 4 4 4 4 4 4 Seitenersetzungen 7 Seitenfehler Problem: Anomalie Die Anzahl der Seitenersetzungen sollte bei steigender Anzahl von Seitenrahmen monoton fallen Diese Eigenschaft trifft auf die FIFO-Strategie nicht zu Optimale Auswahlstrategie Ziel einer optimalen Strategie: bei gegebener Referenzfolge sollen Anzahl Seitenfehler minimiert werden Perfektes Orakel: Entferne die Seite, die am längsten nicht mehr benötigt werden wird Zeit: 2 3 4 5 6 7 8 9 2 Referenz: 2 4 3 2 3 3 2 Rahmen 2 Rahmen 2 2 2 2 2 2 2 Rahmen 3 4 3 3 3 3 3 3 3 3 3 3 Seitenersetzungen 6 Seitenfehler Nicht realisierbar (benötigt Wissen über Zukunft!) Aber: A-Posteriori-Vergleich für andere Strategien Realisierbare Strategien nutzen Lokalitätsprinzip und nehmen die Vergangenheit als Schätzwert für die Zukunft SoSe 28 M. Werner 8 / 36 osg.informatik.tu-chemnitz.de Anomalie bei FIFO 4 Seitenrahmen Zeit: 2 3 4 5 6 7 8 9 2 3 4 5 Referenz: 2 3 4 5 6 2 3 5 6 Rahmen 4 4 4 4 6 6 6 6 6 6 6 Rahmen 2 2 2 2 2 Rahmen 3 2 2 2 2 3 3 3 Rahmen 4 3 3 3 3 5 5 5 5 5 5 5 5 7 Seitenersetzungen / Seitenfehler 5 Seitenrahmen Zeit: 2 3 4 5 6 7 8 9 2 3 4 5 Referenz: 2 3 4 5 6 2 3 5 6 Rahmen 5 5 5 5 5 3 3 3 Rahmen 2 6 6 6 6 6 5 5 Rahmen 3 2 2 2 2 2 2 2 6 Rahmen 4 3 3 3 3 3 3 3 Rahmen 5 4 4 4 4 4 4 4 2 2 2 2 8 Seitenersetzungen / 3 Seitenfehler SoSe 28 M. Werner 9 / 36 osg.informatik.tu-chemnitz.de SoSe 28 M. Werner 2 / 36 osg.informatik.tu-chemnitz.de
LFU (Least Frequently Used) LFU-Algorithmus hat für alle Seiten einen Zähler, der bei jedem Zugriff inkrementiert wird. Seite mit dem geringsten Zählerstand wird entfernt Zeit: 2 3 4 5 6 7 8 9 2 Referenz: 2 4 3 2 3 3 2 Rahmen 3 3 3 3 3 3 3 3 3 Rahmen 2 2 2 2 2 2 2 2 2 2 2 2 Rahmen 3 4 4 4 4 2 2 3 3 4 4 - - - - - - - Zähler 2-2 2 2 2 2 2 2 3 3 - - - 2 2 2 2 3 3 3 4 - - 4 Seitenersetzungen 7 Seitenfehler LRU (Least Recently Used) Die am längsten nicht mehr referenzierte Seite wird entfernt Mögliche Implementation über Warteschlange Seite am Anfang der Warteschlange wird ersetzt Referenzierte Seiten kommen wieder an das Ende der Warteschlange Zeit: 2 3 4 5 6 7 8 9 2 Referenz: 2 4 3 2 3 3 2 Rahmen 3 3 3 3 3 3 3 3 3 Rahmen 2 2 2 2 2 2 2 2 Rahmen 3 4 4 4 4 (Ende) 2 4 3 2 3 3 2 Warteschlange 2 4 3 2 3 3 (Anfang) 2 4 4 2 3 3 3 4 Seitenersetzungen 7 Seitenfehler SoSe 28 M. Werner 2 / 36 osg.informatik.tu-chemnitz.de RNU (Recently Not Used) SoSe 28 M. Werner 22 / 36 osg.informatik.tu-chemnitz.de 7.2.2 Thrashing Ähnlich LRU, aber mit festem Zeitfenster der Länge k, das über Referenzfolge gelegt wird Entfernt werden kann jede Seite, die innerhalb des Fensters nicht referenziert wurde k ist so zu wählen, dass Anzahl der RNU-Seiten klein ist, aber > Beispiel für k = 2 Zeit: 2 3 4 5 6 7 8 9 2 Referenz: 2 4 3 2 3 3 2 Rahmen 3 3 3 3 3 3 3 3 3 Rahmen 2 2 2 2 2 2 2 2 Rahmen 3 4 4 4 4 2 4 3 2 3 3 2 Fenster - 2 4 3 2 3 3 4 Seitenersetzungen 7 Seitenfehler Ziel: Gute Prozessorauslastung Viele Programme gleichzeitig bearbeiten Hoher Grad n der Nebenläufigkeit Geringe Speichermenge pro Prozess Kurze Zeit zwischen zwei Seitenfehlern Stau am Seitentauschgerät (Platte) Fast alle Prozesse blockiert Ergebnis: Schlechte Prozessorauslastung Das System ist nur noch mit Seitentausch beschäftigt und kommt kaum noch zu produktiver Arbeit Bezeichnung: Thashing to thrash : strampeln, zappeln, wild um sich schlagen Bereit Blockiert (warten auf Seite) Rechnend SoSe 28 M. Werner 23 / 36 osg.informatik.tu-chemnitz.de SoSe 28 M. Werner 24 / 36 osg.informatik.tu-chemnitz.de
Thrashing-Kurve Maßnahmen zur Überwindung des Thrashing-Effekts Bessere Programmprofile Lokalität vergrößern, z.b.: Besser viele kleine als wenige große Schleifen Sehr große Matrizen besser zeilenweise als spaltenweise bearbeiten... Maßnahmen auf Betriebssystem-Ebene: Schnellere Massenspeicher (z.b. SSD) Effizente Organisation von Auslagerungsdateien (Plattenmitte) Reduzierung der Prozessanzahl mit Speicheranforderungen (Swapping statt Paging, atmende Working Sets,...)... Es muss verhindert werden, dass das System in den Überlastbereich gerät Mehr zu Analyse Vorlesung Betriebssysteme 2: Analyse und Modellierung SoSe 28 M. Werner 25 / 36 osg.informatik.tu-chemnitz.de Speicherverwaltung in Unix Frühere Unix-Systeme noch ohne virtuellen Speicher, aber mit Swapping Hauptspeicher als Betriebsmittel mit Verdrängung verwaltet Prozesse wurden komplett auf Platte ausgelagert, wenn kein Platz für Prozesserzeugung zur Verfügung stand oder eine dynamische Speicheranforderung nicht erfüllt werden konnte Kriterien für Auslagerung Zustand bevorzugt blockierte Prozesse auslagern Sonst: Priorität und Aufenthaltszeit im Hauptspeicher Priorität und Zeit seit der letzten Einlagerung werden addiert Prozess mit höchsten Wert wird ausgelagert Verwaltung mit First-Fit SoSe 28 M. Werner 26 / 36 osg.informatik.tu-chemnitz.de Demand-Paging in Unix Heutige Unix-Systeme haben Demand-Paging mit extra Rahmen-Leerer (page daemon) Globale Sicht auf den Speicher Auslagerungsstrategie: Second-Chance-Algorithmus: Wird irgendwann auf eine Seite zugegriffen, wird in der Seitentabelle das Referenzbit gesetzt Uhrenzeiger durchläuft zyklisch alle Rahmen Bei einer Seite mit gesetztem Referenzbit wird dieses zurückgesetzt Einer Seite ohne gesetztes Referenzbit wird ausgelagert Annäherung an LRU/RNU Bei Thrashing erfolgt Rückfall auf Swapping SoSe 28 M. Werner 27 / 36 osg.informatik.tu-chemnitz.de SoSe 28 M. Werner 28 / 36 osg.informatik.tu-chemnitz.de
Modifizierter Second-Chance-Algorithmus Bei 4.3BSD wurde ein modifizierter Second-Chance-Algorithmus mit zwei Zeigern eingesetzt, jeweils für Markieren und Räumen Zeiger 2: Räumen Zeiger : Nullsetzen Vor Aktivieren des daemon Zeiger 2: Räumen Zeiger : Nullsetzen Nach Aktivieren des daemon Zeiger 2: Räumen Zeiger : Nullsetzen Vor Aktivieren des daemon handspread Zusätzlicher Parameter: Abstand der Zeiger (handspread) kann an Lastsituation angepasst werden SoSe 28 M. Werner 29 / 36 osg.informatik.tu-chemnitz.de Speicherverwaltung in Windows Fork mit Copy-On-Write Copy-on-write: bei fork()-systemruf erbt der Kindprozess den Zustand des Elternprozesses Nutzersicht: Kopieren eines Speicherbereiches bzw. Adressraums Implementierung: Nur die Seitentabelle wird kopiert Seitentabelleneinträge von Eltern und Kind werden als nur lesen markiert MMU meldet Zugriffsfehler bei schreibendem Zugriff Betriebssystem behandelt Fehler, legt echte Kopie an, wiederholt Aktion SoSe 28 M. Werner 3 / 36 osg.informatik.tu-chemnitz.de Speicherverwaltung in Windows (Forts.) Lokale Seitentauschstrategie Working Set Je nach Seitenfehlerrate und Gesamtzahl von Speicherrahmen werden Working Sets der Prozesse angepasst Wenig Seitenfehler verkleinern (working set trimming) Viele Seitenfehler erweitern (working set expansion) Systemweites Maximum wird beim Start berechnet (MmMaximumWorkingSetSize) Harte Grenzen: 2GB für X86, 7TB für IA64, 8TB für X86_64 Einlagerung und Auslagerung auf Kosten des den Seitenfehler verursachenden Prozesses Behandlung von Seitenfehler im Kontext des verletzenden Prozesses (Moduswechsel) Ein Prozess startet immer mit einem leeren Working Set Seitenfehler beim Zugriff Füllt sich im Laufe der Prozessausführung Nur wirklich benötigte Daten / Code-Teile liegen im Hauptspeicher read-ahead-mechanismen: Mehr Seiten einlesen als eigentlich benötigt Bei Verkleinerung: LRU-Schema zum Ersetzen Der Kern hat sein eigenes System Working Set Beinhaltet globalen Cache des Dateisystems Kernel-Code und Daten (inkl. Treiber) können auch ausgelagert sein SoSe 28 M. Werner 3 / 36 osg.informatik.tu-chemnitz.de SoSe 28 M. Werner 32 / 36 osg.informatik.tu-chemnitz.de
Frameverwaltung in Windows Frameverwaltung in Windows (Forts.) Ungenutzte Frames werden in verschiedenen globalen FIFO-en verwaltet Free : Verfügbare Frames, nicht mit gefüllt Modified : Veränderte Seiten / Frames, aus dem Working Set entfernt Standby : Unveränderte Seiten / Frames, aus dem Working Set entfernt Zero : Verfügbare Frames, mit gefüllt Bad : Frame hat Hardware-Test nicht bestanden Systemweite Optimierung durch Justierung der Working Sets einzelner Prozesse Neue Kacheln für Prozesse aus Free oder Zero, je nach Art der Nutzung Soft Fault: Frame geht aus standby oder modified-e wieder zurück in das Working Set, keine E/A-Operationen nötig Anmerkung: Mac OS X und ios arbeiten mit ähnlichen en demand zero page faults Process Working Sets Private pages at process exit soft page faults working set replacement page read from disk or kernel allocations Standby modified page writer Modified Free zero page thread Zero Bad SoSe 28 M. Werner 33 / 36 osg.informatik.tu-chemnitz.de 7.4 Zusammenfassung 7.4 Zusammenfassung SoSe 28 M. Werner 34 / 36 osg.informatik.tu-chemnitz.de Literatur Literatur Lokalitätsprinzip erlaubt effiziente Nutzung der Speicherhierachie Demand Paging erweitert das Konzept der streuenden Adressierung/Paging zur Virtualisierung des Speichers Zusätzliche Verwaltungsinformationen nötig Problem des langsamen Massenspeicher soll durch Parallelisierung und geeignete Ersetzungsstrategien gebändigt werden [Sta4] [Tan8] W. Stallings. Operating Systems: Internals and Design Principles. Prentice Hall, 24, Chapter 7 und 8 A. Tanenbaum. Modern Operating Systems. Prentice Hall, 28, Chapter 3 und 9/ [SR96] David A. Solomon und Mark E. Russinovich. Inside Window 2. Microsoft Press, 996, Chapter 7 Thrashing kann effektive Nutzung der Speicherhierachie stören und sollte verhindert werden SoSe 28 M. Werner 35 / 36 osg.informatik.tu-chemnitz.de SoSe 28 M. Werner 36 / 36 osg.informatik.tu-chemnitz.de