Freispeicherverwaltung Motivation Vorlesung Betriebssysteme II Thema : Hauptspeicherverwaltung Robert Baumgartl 7. April 5 Applikationen und das Betriebssystem selbst fordern zur Laufzeit Speicher an (und geben diesen später wieder zurück). Notwendigkeit der Verwaltung notwendig, zur Laufzeit Speicher an Anfordernde (Applikationen, BS) auszureichen und wieder entgegenzunehmen Schnittstelle: Menge an Funktionen, die Speicher anfordern und diesen wieder zurückgeben / 9 / 9 Freispeicherverwaltung Probleme Fragmentierung: intern Verlust durch feste Segmentgröße ( Verschnitt ) extern Verlust durch inkohärente Speicherung ( Verstreuung ) Kompensation durch Kompaktifizierung Table Verlust durch Speicherbedarf der Verwaltungsstrukturen Laufzeitkomplexität der Suche nach freiem Segment der Rückgabe des Segments (Wiedereinordnung) Zwei grundlegende Management-Techniken:. Bitmaps. Listen Bitmaps Anforderung wird auf einen oder mehrere Blöcke einer fixen Größe abgebildet Karte des Hauptspeichers Blöcke (allocation units) einheitlicher Größe pro Block ein Bit: = Block frei = Block belegt belegt frei belegt belegt frei belegt belegt A B C D E Bitmap n Allokations einheit frei / 9 / 9 Bitmaps Blockungsfaktor Parameter: Blockungsfaktor n, beeinflusst: Speicherbedarf für die Bitmap interne Fragmentierung Gefahr der externen Fragmentierung fixe Größe der Verwaltungsstruktur keine weiteren Verwaltungsinformationen in Bitmap speicherbar Idee: Suche nach einem passenden freien Segment ggf. Abtrennen des nicht benötigten Restes d.h., es werden stets exakt passende Segmente ausgegeben ( keine interne Fragmentierung) pro Segment ein Element einer verkettete Liste (einfach, doppelt, Ring), enthält: Anfangsaddresse belegt/frei-information Zeiger auf Nachfolge-Element weitere Informationen, z. B. Eigentümer Start A 5 5 B 8 6 C 8 D 6 E 6 9 5 / 9 6 / 9
Blöcke mit integrierten Headern Suchstrategien Suchoperation bei Forderung eines Segmentes der Größe m: Variante: Header ist in Blöcke integriert (belegt/frei-bit,, evntl. Zeiger auf NF) Header First Fit Durchsuchen der Liste beginnend von Start erstes freies Segment m wird genutzt ggf. Abtrennen des Überschusses (Teilung des Segments; freies belegtes + freies) Tendenz: anfangs belegte Segmente, später mehr freie Segmente Next Fit Start der Suche an letzer Erfolgsposition sonst wie First Fit Tendenz zu größerer Fragmentierung als First Fit 7 / 9 8 / 9 Suchstrategien II Best Fit Suche in Liste nach bestpassendstem Element (kleinstes Element, dessen Größe l m) Suchaufwand! Gefahr der Generierung unbenutzbar kleiner Restsegmente Worst Fit Suche nach größtmöglichem Element, um Nachteil von Best Fit zu begegnen externe Fragmentierung! Bei Freigabe eines Blockes: Markierung als frei Vereinigung mit freien Nachbarblöcken, wenn möglich Techniken zur Effizienzsteigerung Verzögertes Vereinigen (Deferred Coalescing): freigegebene Segmente nicht sofort mit freien Nachbarsegmenten vereinigen Effizienzsteigerung wenn Objekte einer Größe angefordert und freigegeben werden Vereinigung erst nach Verzögerung oder durch extra Aktivität Objektcache (Slab Allocator) Begrenzungsmarken (Boundary Tags) Endebegrenzung jedes Segmentes durch zum Header identischen Footer vereinfacht Vereinigung mit unmittelbar vorangehendem (freien) Nachbarblock Problem: Table Fragmentation 9 / 9 / 9 Techniken zur Effizienzsteigerung II Zusätzliche Verkettung freier Segmente schnellere Suche kein zusätzlicher Speicherplatz nötig, da nur im ungenutzten Speicher angelegt H F H F H F H F H F Abbildung: Zusätzliche Verkettung freier Segmente Getrennte n (Segregated Fits) Idee: Array von Listen unterschiedlicher Segmentgröße(nklassen), um Suchaufwand zu reduzieren Variante : Einfacher getrennter Speicher (Simple Segregated Storage) eine Liste pro Segmentgröße keine Teilung von Segmenten Liste leer - Seiten mittels sbrk() anfordern, in gleichgroße Blöcke teilen, in Liste einordnen kein Transfer zwischen Listen ( keine Vereinigung mit benachbarten Segmenten) ziemlich effizient im durchschnittlichen Fall Worst Case? / 9 / 9
Getrennte n (Segregated Fits) Variante : Getrennte Fits Liste leer Liste mit nächster Größe durchsucht, Teilung eines gefundenen Segments a) exakte Listen b) Strikte Größenklassen mit Rundung c) Listen mit Größenintervallen ggf. Wiederholung der Suche in Listen mit größeren Segmenten Vereinigung benachbarter freier Segmente (sofort oder verzögert) Buddy-Verfahren Idee: System reicht Blöcke fester Größe k = N Bytes aus N Listen mit (exakter) Segmentgröße ausgereicht wird stets ein Block mit der Größe, die die Anforderung am knappsten befriedigt (z. B. Anforderung 7 KiB Auslieferung 6 KiB) wenn kein Block passender Größe vorhanden:. Teilung eines nächstgrößeren (freien) Blockes. Auslieferung einer Hälfte. andere Hälfte (der Buddy ) wird als frei in die entsprechende Liste einsortiert Initial enthält eine Liste genau einen Block, den gesamten (freien) Hauptspeicher Bei Rückgabe wird geprüft, ob der Block ggf. mit seinem Buddy vereinigt werden kann (und in der Liste der nächstgrößeren Blöcke eingeordnet werden kann) / 9 / 9 Buddy-Verfahren Beurteilung Virtueller Speicher Motivation Aufwand bei Rückgabe des Speichers geringer als mit wirkt externer Fragmentierung entgegen, da stets maximal wieder vereinigt wird Hauptnachteil: Speicherplatzverschwendung (Verschnitt; interne Fragmentierung) Ziel: Schutz der Aktivitäten voreinander die Größe des Hauptspeichers übersteigende Prozesssysteme Konzept: Erweiterung des Hauptspeichers durch Massenspeicher Privatisierung der Adressräume Partitionierung der virtuellen und des physischen Adressraums (einheitliche, feste Größe; z. B. KiB) 5 / 9 6 / 9 Virtueller Speicher Seiten vs. Kacheln Virtueller Speicher Seiten vs. Kacheln virtueller Adressraum logische Seiten (virtuelle Seiten, Pages) physischer Adressraum (gleichgroße) Kacheln (Seitenrahmen, Page Frames) Seiten virtueller Speicher physischer Hauptspeicher Prozeß A B C MMU+OS P A B C D Prozeß P Q R frei Q R frei D Kacheln Abbildung: Abbildung logischer Seiten auf physische Kacheln 7 / 9 8 / 9
Gestreute Speicherung Umsetzung virtueller in physische Adresse Seitentabelleneintrag (Page Table Entry PTE) Aufbau (Beispiel) bei jeder (!) Speicherreferenz ausgeführt durch Hardware (Memory Management Unit MMU im Prozessor) Indexierung einer Tabelle (Seitentabelle, Page Table) Seitentabelle durch BS verwaltet, existiert pro Prozess Seitennummer Seitenadressen x8 x x virtuelle Adresse x Seitentabelle RO Index Prot P RW RWX RO + x x x physische Adresse x Hauptspeicher selektiertes Wort C D R M Prot P Page Frame Number PFN Page Frame Number Adresse der entsprechenden physischen Kachel P Present-Bit Seite ist im Hauptspeicher (oder auf Massenspeicher ausgelagert) Prot Protection Lese-/Schreib-/Ausführungs-Operation sind (nicht) erlaubt M Modified ( dirty ) Kachel wurde beschrieben ( muss vor Auslagerung auf Massenspeicher zurückgeschrieben werden) R Referenced Seite wurde durch den Prozess (irgendwann einmal) gelesen, referenziert CD Cache disable Seiteninhalt darf nicht gecacht werden (wichtig bei memory-mapped devices) 9 / 9 / 9 Größe der einstufigen Seitentabelle Größe der Seitentabelle Problem: Größe der Seitentabelle (muß hintereinander im Speicher stehen) Beispiel Seitengröße KiB, Bit Adressbreite Index Bit ( = 96) Seitennummer Bit groß (-=) Seitentabelle kann Einträge enthalten resultierende Größe der Seitentabelle MByte (pro Prozess!) Lösung: Baum von Seitentabellen ( Hierarchie) langsamerer Zugriff, da mehrere Subtabellen aufgesucht werden müssen Subtabellen dafür kürzer und flexibler (auf Anforderung anlegbar) zwei- (Intel i86), drei- und vierstufige Hierarchien Verbesserung des Timings durch einen Cache, der Adressumsetzungen virtuell physisch aufbewahrt: Translation Lookaside Buffer (TLB) / 9 / 9 Beispiel: Zweistufige Seitentabelle (i86) Demand Paging PD Index Register CR PD Eintrag Page Directory Einträge PT Index Byte Index PTE Page Tables Einträge virtuelle Adresse gewähltes Byte physischer Adreßraum gewählte Seite Idee: Benötigte Seiten werden erst bei Bedarf in den Hauptspeicher geladen. Ist der physische Speicher restlos ausgenutzt, so muss zuvor eine andere Seite ausgelagert werden. Prinzipieller Ablauf. Prozess referenziert eine Adresse (neuer Befehl, Zugriff auf Datum). MMU führt Adressübersetzung aus. BS prüft: referenzierte Seite im physischen Speicher Ausführung der Instruktion, Weiterarbeit referenzierte Seite momentan ausgelagert Seitenfehler (Page Fault, Software-Interrupt) / 9 / 9
Seitenfehler (Pagefault) Einlagerungsstrategien. Prozess wird angehalten (blockiert). BS sucht freie HS-Kachel. falls keine freie HS-Kachel verfügbar Auswahl einer auszulagernden Seite, Auslagerung auf Festplatte. Einlesen der referenzierten Seite in (nun) freie HS-Kachel von Festplatte 5. Weiterarbeit des blockierten Prozesses Pro Seitenfehler bis zu Festplattenzugriffe notwendig! Einfachere Alternative: Swapping: ganze Prozesse werden ausgelagert! Demand Paging: Einblenden einer Seite bei Referenz (spätestmöglicher Zeitpunkt, Lazy Evaluation) Prepaging: Seiten werden im voraus eingeblendet. Sinnvoll bei kontinuierlicher Ablage auf Massenspeicher; angewandt z.b. bei Start eines neuen Prozesses (Windows NT). 5 / 9 6 / 9 Optimales Verfahren; LRU Frage: Welche Seite soll ausgelagert werden? Ähnlichkeit zur Ersetzungsstrategie in Caches Strafe (Penalty) sehr hoch, da Massenspeicherzugriff: Instruktion benötigt ca.. ns bei GHz Takt Festplattenoperation benötigt ca. ms Zeit für 6 Instruktionen Worst Case? Optimales Verfahren lagert diejenige Seite aus, die am längsten nicht benötigt wird (in Zukunft) schwierig ohne eingebauten Hellseher wichtig zum Vergleich realer Verfahren Least Recently Used (LRU) Heuristik: Seiten die lange nicht referenziert wurden, werden auch in Zukunft kaum gebraucht exaktes LRU schwierig ( älteste Seite auslagern ) vgl. Cache Approximation: NRU 7 / 9 8 / 9 Not Recently Used (NRU) Not Recently Used (NRU), contd. Not Recently Used (NRU) Ausnutzung des Referenced- und des Modified-Bits im Seitentabelleneintrag periodisches Rücksetzen des R-Bits durch BS (z.b. durch Timerinterrupt gesteuert) R-Bit wird automatisch (durch MMU) gesetzt, sobald Seite referenziert wurde M-Bit gesetzt, wenn Seiteninhalt modifiziert wurde ( dirty ) vor Auslagerung zurückschreiben Klassen von Seiten unterscheidbar: R M Beschreibung Seite wurde nicht referenziert Seite wurde lange nicht referenziert, aber (irgendwann) verändert Seite wurde referenziert, aber nicht modifiziert Seite wurde referenziert und geändert bei Bedarf zunächst Auslagerung von {}-Seiten wenn keine verfügbar, dann {}-Seiten, dann {}-Seiten, usw. 9 / 9 / 9 5
FIFO; nd Chance NFU; Aging First In, First Out (FIFO) Idee: ältere Seiten zuerst auslagern keine Berücksichtigung der Referenz Second Chance verbessert FIFO Auslagerungskandidat (AK): älteste Seite R == Seite wird ausgelagert R == R :=, Kandidat: nächstälteste Seite Anordnung der Seiten in Ringliste, Zeiger auf AK Uhralgorithmus Not Frequently Used (NFU) Betrachtung der Referenzierungshäufigkeit pro Seite ein Zähler, periodisches Aufaddieren des R-Bits Auslagerung der am seltensten genutzten Seite (kleinster Zählerstand) später eingelagerte Seiten benachteiligt benötigt: Vergessen veralteter Zählerstände Aging Modifikation von NFU: alle Zähler vor Aufaddieren des R-Bits Bit nach rechts geschoben R-Bit wird an höchste Bitposition des Zählers geschrieben / 9 / 9 Aging, contd. Konzept der Arbeitsmenge (Working Set) Tick 5 R Bits 5 Abbildung: Beispiel für den Aging-Algorithmus Empirische Beobachtung: eine bestimmte Anzahl eingeblendeter Seiten ist optimal. Anzahl zu gering hohe Seitenfehlerrate, Anzahl zu groß Speicherverschwendung, möglicherweise kein Prozess mehr bereit. Prinzip: Die Arbeitsmenge W (t, ) sind diejenigen Seiten eines Prozesses, die zwischen dem aktuellen Zeitpunkt t und einem Zeitpunkt t in der Vergangenheit referenziert wurden. Shift-Operation realisiert Vergessen alter Zählerstände Häufigkeit und Zeitpunkt der Referenzierung relevant / 9 / 9 Beispiel für eine Arbeitsmenge Referenz- kette 5 5, 5,5,5,5 8 5, 8,5,8,5,8,5,8 8, 5,8,,5,8,,5,8,, 8,, 7, 7,, 7 8,,, 7 5, 8,,, 7 8 7, 8, 7, 8,, 7, 8 8, 7, 8, 8, 8 7,, 8 7 8, 7, 8, 7 7 7 8, 7 5 7, 5 7, 5 8, 7, 5, 8, 7, 5 5, 7, 5, 7, 5, 7, 7 7, 5, 7, 8, 8 7,, 8 7,, 8 5, 7,, 8 Tabelle: Beispiel der Entwicklung der Arbeitsmenge eines Prozesses für unterschiedliche (Bach: The Design of the UNIX Operating System. 986, S. 87) 5 / 9 Konzept der Arbeitsmenge (Working Set) Es gilt W (t, + ) W (t, ) d.h., die Arbeitsmenge wächst monoton mit. Weiterhin gilt für die Menge der referenzierten Seiten W (t, ) min(, N) wobei N die Gesamtzahl der referenzierten Seiten eines Prozesses bezeichnet. Der Parameter kann als Fenstergröße in die Referenzierungsvergangenheit des Prozesses aufgefasst werden. 6 / 9 6
Abhängigkeit der Größe der Arbeitsmenge von Abhängigkeit der Größe der Arbeitsmenge von W (t, ) gesättigtes Verhalten: ab einem bestimmten Punkt ( ) ändert sich die Größe der Arbeitsmenge nicht mehr gravierend (Ursache: Lokalitätsprinzip) minimale Größe der Arbeitsmenge W (t, ), bestimmt die Grenze zwischen niedriger und hoher Pagefault-Rate Working Set unterliegt zyklischen Veränderungen; man unterscheidet transiente und stabile Zustände 7 / 9 8 / 9 Idee für eine Ersetzungsstrategie... basierend auf dem Working Set W für jeden Prozess beobachten zyklisch alle diejenigen Seiten eines Prozesses entfernen, die nicht zu W gehören Prozess darf nur aktiviert werden, wenn seine Arbeitsmenge im Hauptspeicher eingeblendet Probleme: exakte Messung, Logging des WS aufwendig Approximation Wahl von : zu klein PF-Rate des Prozesses steigt zu groß Speicherverschwendung keine Adaption bei Größenänderung der Arbeitsmenge Beladys Anomalie Vergrößerung von W führt normalerweise zu Verringerung der Page-Fault-Rate des betroffenen Prozesses, jedoch... 5 virtuelle Seiten Ersetzungsstrategie FIFO (willkürliche ) Referenzierungskette: Ref. Kette jüngste Seite älteste Seite PF Abbildung: Beladys Beispiel mit W = Seitenrahmen 9 / 9 / 9 Beladys Anomalie, contd. Weitere Aspekte zur Seitenersetzung Ref. Kette jüngste Seite älteste Seite PF Abbildung: Beladys Beispiel mit W = Seitenrahmen Vergrößerung des WS führt zu Erhöhung der PF-Rate (W = 9PF, W = PF) unerwartetes Verhalten, Anomalie konstruiertes Beispiel abhängig vom Seitenersetzungsverfahren; LRU unempfindlich optimale Seitengröße? lokale vs. globale Ersetzungsstrategien variable vs. konstante Größe des Working Set viele weitere Ersetzungsstrategien alternative Mechanismen der Suche in Seitentabellen / 9 / 9 7
Schnittstelle zum Betriebssystem UNIX malloc() und free() Speicherabbild eines Prozesses Semantik: Anforderung von Heap-Speicher, bzw. dessen Rückgabe Funktionen der C-Bibliothek ( portabel) eine der Hauptquellen für Programmfehler ist fehlerhafter Umgang mit diesen Funktionen weitere Funktionen: realloc(), calloc() unter UNIX gewöhnlich mittels brk() realisiert (jedoch auch mit mmap()) Implementierung stark systemabhängig viele Allokatoren vergrößern Heap zwar, verkleinern jedoch nicht (Optimierung) Seiten werden bei malloc() weder initialisiert noch zwangsweise eingeblendet bekannteste Implementation: Doug Lea s Allocator High Low Umgebung, Argumente Stack Heap uninitialisierte Daten (BSS) initialisierte Daten Text "break" null initialisiert aus Datei eingelesen durch exec() / 9 / 9 Der Systemruf brk() Stackanforderung mittels alloca() int brk(void *end_data_segment); setzt das Ende des Heaps auf end_data_segment, vorausgesetzt Wert ist plausibel, das System hat noch genügend Speicher, maximale Heapgröße des Prozesses wird nicht überschritten genutzt z. B. zur Implementierung von malloc() & Co. weitere Funktion der C-Bibliothek: sbrk() malloc() und brk() nicht gleichzeitig verwendbar im Vergleich zu malloc() viel elementarer void *alloca(size_t size); alloziiert size Bytes auf dem Stack (!) keine Rückgabefunktion benötigt (Warum?) nicht für alle Systeme verfügbar The alloca function is machine and compiler dependent. On many systems its implementation is buggy. Its use is discouraged. (man alloca,.6er Linux-System) Implementierung durch Inline-Code ( nicht als Argument einer Parameterliste nutzbar) 5 / 9 6 / 9 Ausschalten des Pagings (Pinning) Memory-mapped Files aka speichereingeblendete Dateien Verhinderung des Auslagerns a) einzelner Seiten mittels mlock() b) des gesamten Adressraums mittels mlockall() für (weiche) Echtzeit- und sicherheitskritische Applikationen Rückbau mit munlock()/munlockall() vergrößert Pagefault-Rate für nichtpinnende Prozesse mmap(), munmap(), mremap(), msync() blendet Dateien (oder Geräte) in den Hauptspeicher ein Granularität: Seiten gemeinsame oder exklusive Einblendung möglich d. h. eingeblendete Dateien werden wie Hauptspeicher manipuliert (ersetzt klassische open/read/write/close-schnittstelle) modern 7 / 9 8 / 9 8
Was haben wir gelernt? Hauptspeicherverwaltung: Bitmaps, Listen, Buddy-Verfahren Virtueller Speicher: Funktionsweise, Ablauf des Pagefault, relevante Datenstrukturen Ersetzungsstrategien (LFU, NFU, Aging & Co., Working Set ) API zum Hauptspeicher von unix-artigen BS 9 / 9 9