From a43f9546b04a024889620d1f6afe018f379882ec Mon Sep 17 00:00:00 2001 From: Robert Jeutter Date: Tue, 15 Dec 2020 11:25:09 +0100 Subject: [PATCH] Kapitel 6 --- Betriebssysteme.md | 562 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 557 insertions(+), 5 deletions(-) diff --git a/Betriebssysteme.md b/Betriebssysteme.md index 2f74dfe..8032bc2 100644 --- a/Betriebssysteme.md +++ b/Betriebssysteme.md @@ -1125,8 +1125,560 @@ Zusammenfassung Ereignismanagement/Botschaften ## Zusammenfassung IPC: Kommunikation und Synchronisation - - a) Semaphore und Hoare‘sche Monitore: blockierend, pessimistisch - - b) transaktionaler Speicher: neu, optimistisch, transaktional - - c) Botschaften: kein gemeinsamer Speicher, Datentransport - - d) Fernaufrufe, Systemaufrufe: „Spezialisierungen“ - - e) Ereignismanagement: Interrupts, Unterbrechungen auf Anwendungsebene + - Semaphore und Hoare‘sche Monitore: blockierend, pessimistisch + - transaktionaler Speicher: neu, optimistisch, transaktional + - Botschaften: kein gemeinsamer Speicher, Datentransport + - Fernaufrufe, Systemaufrufe: „Spezialisierungen“ + - Ereignismanagement: Interrupts, Unterbrechungen auf Anwendungsebene + + +# Speichermanagement +Ideale Speichermedien sind +- beliebig schnell und +- beliebig groß und +- beliebig billig und +- persistent (speichern Daten ohne andauernde Energiezufuhr) + +Reale Speichermedien sind +- schnell, teuer, flüchtig oder +- langsam, preiswert, persistent oder +- eine Vielzahl von Schattierungen dazwischen + +Fazit: Speicherhierarchie +- Speichermanagement: Management dieser Speicherhierarchie + +## Speichertechnologien und -klassen +- Prozessorregister, Cache-Speicher + - sehr schnell (Pikosek., 10 11 -10 12 Zugriffe/s) + - sehr teuer → klein (≈ KByte-MByte) + - flüchtig +- Arbeitsspeicher + - schnell (Nanosekunden, ≈ 10 10 Zugriffe/s) + - weniger teuer → mittelgroß (≈ GByte) + - flüchtig +- Flash-EEPROM (SSDs, USB-Sticks) + - langsam (Mikrosekunden, 10 8 Zugriffe/s) + - preiswert → groß (≈ GByte-TByte) + - persistent +- Magnetplatten, optische Medien, Archivierungsbänder + - langsam (Mikro-/Millisekunden, 10 6 -10 8 Zgr./s) + - mittel bis sehr groß (≈ GByte-PByte) + - persistent + +### Was muss Arbeitsspeicher können? +- Prozesse: Programmcode, statische Daten, dynamische Daten, Stack + - Struktur + - Typisierung +- große Prozesse -> Größe +- parallele, potentiell fehlerhafte/unfreundliche Prozesse -> Isolation + +### Layout des (physischen) Arbeitsspeichers: 50er Jahre +Merkmale: +- extrem einfaches Speichermanagement (fester Adressbereich für Anwendungsprogramm) +- keine Hardware-Unterstützung +- Betriebssystem: Bibliothek +- Problem: zu jedem Zeitpunkt nur ein Programm + +### Layout des physischen Arbeitsspeichers: 60er Jahre +Merkmale: +- einfaches Speichermanagement (Freiliste, first-fit oder best-fit-Vergabe) +- parallele Prozesse + +Bezahlt mit +- Verletzbarkeit: Zugriff auf Speicherbereiche fremder Prozesse +- Enge: weniger Raum für einzelne Prozesse +- Komplexität: + - Wachsen von Prozessen problematisch + - keine feste Startadresse; Erzeugung von + - Codeadressen (Sprünge, Prozeduraufrufe) + - Datenadressen (Variablen + +-> Relokation + +## Relokation +Ziele +1. Platzieren eines Prozesses an beliebigen Speicheradressen +2. Verschieben zwecks Vergrößerung/Speicherbereinigung + +Idee +1. sämtliche Speicheradressen in einem Programm werden + - vom Compiler/Linker relativ zur Speicheradresse „0“ berechnet + - als „Relativadressen“ markiert +2. beim Anlegen/Verschieben eines Prozesses werden markierte Adressen aktualisiert (= Relokation): + `tatsächliche Adresse = Relativadresse + Prozessanfangsadresse` + +Realisierung +- per Software → durch Betriebssystem beim Erzeugen/Verschieben +- per Hardware → durch Offset-Register zur Laufzeit: „my first MMU“ + +Erreicht +1. Anlegen eines Prozesses an beliebiger Adresse +2. Verschiebbarkeit +( gegen Enge und Verletzbarkeit hilft Relokation nicht) + +Bezahlt mit +- entweder: verteuertem Programmstart (wenn Startadresse bekannt): + - Aktualisierung der Relativadressen per Software (Betriebssystem-Prozessmanagement) +- oder: höheren Hardware- und Laufzeitkosten: + - mini-MMU mit Offset-Register + - Adressumrechnung bei jedem Speicherzugriff + +## Swapping +Ziel: Beseitigung der Enge +- Schaffen von freiem Arbeitsspeicher durch Auslagerung von Prozessen +- Erstes Auftauchen einer Speicherhierarchie + +Erreicht: mehr Platz (gegen Verletzbarkeit hilft Relokation nicht) + +Bezahlt mit: +1. Prozesswechsel werden teurer + - Aus/Einlagerungszeiten + - Relokation bei Wiedereinlagerung an neue Adresse +2. fortschreitende Zerstückelung des Arbeitsspeichers + - Verluste durch Verschnitt +3. der pro Prozess adressierbare Speicherbereich wird durch Swapping nicht größer (limitiert durch physische Arbeitsspeichergröße) + - virtueller Speicher + +## Virtueller Speicher +Idee: Jeder Prozess erhält einen privaten, sehr großen Arbeitsspeicher + +Damit +- besitzt jeder Prozess einen riesigen Vorrat an Speicheradressen +- bei $2^{Adressenlänge}$ = Anzahl Speicheradressen gilt: sämtliche von einem Prozess erzeugbaren Speicheradressen (sein Adressraum) + - gehören per Definition: zu seinem eigenen Arbeitsspeicher + - dadurch: keine Möglichkeit des Zugriffs auf Arbeitsspeicher anderer Prozesse +- ist keine Relokation mehr notwendig + +Problem: so viel Speicher können wir physisch gar nicht bauen (es gibt nicht einmal $2^64$ Atome im Sonnensystem!!) +Lösung: +- Betriebssysteme lügen (vermitteln Prozessen eine Illusion) +- virtuelle Adressräume + +### Virtuelles Speichermanagement (VMM) +ist die Realisierung dieser Idee durch +1. Abstraktionen physischen Arbeitsspeichers: + - private virtuelle Adressräume +2. Abbildungen $vm_p$: + - virtueller Adressraum → physischer Adressraum +3. MMUs: + - Hardware, die diese Abbildungen effizient implementiert + +Ausgangsidee: Jeder Prozess p besitzt einen privaten, großen virtuellen Adressraum $VA_p$ (z.B. 2 64 adressierbare Speicherzellen). +Damit +1. ist es nicht mehr eng +2. können Prozesse sich gegenseitig nicht mehr verletzen + +### Begriffe +> Adressraum: Ein Adressraum ist eine (endliche) Menge von Adressen +> - Menge aller Postadressen einer Stadt +> - Menge aller IP-Adressen +> - die natürlichen Zahlen 0 ... 2 64 -1 + +> Adressraum eines Prozesses: Der Adressraum eines Prozesses (im Kontext des VMMs) ist die Menge aller ihm zur Verfügung stehender Arbeitsspeicheradressen + +> physischer Adressraum: Ein physischer Adressraum (PA) ist die Menge aller Adressen eines physischen (realen) Speichers + +> virtueller Adressraum: Ein virtueller Adressraum (VA) ist die Menge aller Adressen eines virtuellen Speichers; im Allgemeinen gilt: |VA|>>|PA| + +> virtueller Speicher: ist eine Abstraktion physischen Speichers zwecks Vortäuschung großer physischer Adressräume + +> virtuelles Speichermanagement (besser: Management virtueller Speicher): befasst sich mit der Abbildung virtueller auf physische Adressräume + +### Abbildung $vm_p$ +Realisierung: Jeder virtuelle Adressraum $VA_p$ wird mittels einer individuellen Abbildung $vm_p: VA_p \rightarrow PA$ auf den physischen Adressraum PA abgebildet (siehe: „Speicherlayout“). + +Eigenschaften der Abbildung $vm_p$ +1. Definitionsbereich + - $VA_p$ sehr groß + - $\exists$ unbenutzte/undefinierte Adressbereiche + - $vm_p$ partiell +2. Realisierung + - $|VA_p | >> |PA|$ + - Abwesenheit (Seitenfehler, s.u.) + - $vm_p$ nicht zu jedem Zeitpunkt vollständig gültig +3. Isolation + - Adressen verschiedener virtueller Adressräume werden nie zum selben Zeitpunkt auf dieselbe Adresse des physischen Adressraums abgebildet + +Aufgaben des virtuellen Memory Management (VMM): Realisierung der Abbildung $vm_{pi}: VA_{pi} \rightarrow PA$ einschließlich +- Definitionsbereich: $vm_{pi} partiell +- Anwesenheitskontrolle: $vm_{pi} nicht immer gültig +- Isolation und Kommunikation: Injektivität +- Zugriffsschutz: lesen/schreiben/ausführen + +... bei jedem einzelnen Speicherzugriff! + +Effizienz +- massive Unterstützung durch Hardware (MMU) +- Mengenreduktion: sowohl $VA_{pi}\rightarrow PA$ als auch die Definition von Zugriffsrechten + - erfolgen nicht für jede virtuelle Adresse individuell + - sondern in größeren Einheiten („Seiten“); typische Größe 4 oder 8 KByte + +### Memory Management Units (MMUs) +Integration in die Hardware-Architektur im Zugriffspfad: Prozessor (virtuelle Adressen) → Speicher (physische Adressen) + +Abbildung $vm_p: VA_p\rightarrow PA$ in der MMU +1. Aufteilung jedes virtuellen Prozessadressraums in Seiten gleicher Größe (typisch 4 oder 8 KByte) +2. Aufteilung des physischen Adressraums in Seitenrahmen gleicher Größe +3. Seite eines virtuellen Prozessadressraums mit Seitenrahmen des physischen Adressraums assoziieren („Fliesen legen“): die Seiten(abbildungs)tabelle + +$\rightarrow$ Realisierung der Abbildung $vm_p: VA_p\rightarrow PA$ seitenweise + +### Seitenabbildungstabellen +Beispiel (mit kleinen Zahlen) +- Seitengröße: 2 KByte +- Größe des VA: 2^14 =16 KByte (→ 8 Seiten, virtuelle Adressen haben 14 Bit) +- Größe des PA: 2^13 =8 KByte (→ 4 Seitenrahmen, phys. Adressen haben 13 Bit ) + +Prinzipieller Aufbau eines Seitentabelleneintrags (davon gibt es genau einen je Seite eines virtuellen Adressraums): +`| Rahmennummer im Arbeitsspeicher (PA) | anwesend | benutzt | verändert | Schutz | Caching |` + +Seitenattribute +1. anwesend: Indikator, ob Seite im Arbeitsspeicher liegt („present“-Bit) +2. benutzt: Indikator, ob auf die Seite zugegriffen wurde („used/referenced“- Bit ) +3. verändert: Indikator, ob Seite „schmutzig“ ist („dirty/ modified “-Bit) +4. Schutz: erlaubte Zugriffsart je Privilegierungsebene („access control list“) +5. Caching: Indikator, ob Inhalt der Seite ge“cached“ werden darf + +Von MMU und BS gemeinsam genutzte Datenstruktur: HW/SW Schnittstelle +- von MMU bei jedem Speicherzugriff genutzt zur + - Prüfung auf Präsenz der die Zugriffsadresse enthaltenden Seite + - Prüfung der Rechte des Zugreifers (Privilegierungsebene und Zugriffsart vs. Schutz) + - Umrechnung der virtuellen in die physische Adresse +- vom BS verändert + - bei jedem Adressraumwechsel (Prozesswechsel; Grundlage: Adressraum-Beschreibung im Prozessdeskriptor) + - beim Einlagern/Auslagern einer Seite (present-Bit, phys. (Seitenrahmen-)Adresse) + - bei Rechteänderungen +- von der MMU verändert: zur Lieferung statistischer Informationen + - bei einem Zugriff auf eine Seite (used-Bit) + - bei einem Schreibzugriff auf eine Seite (dirty-Bit) +- vom BS genutzt: zum effizienten Speichermanagement + - z.B. zum Finden selten genutzter Seiten bei Arbeitsspeicher-Engpässen (used-Bit) + - z.B. müssen nur veränderte Seiten bei Freigabe zurückgeschrieben werden (dirty-Bit) + +Problem: VMM „is not for free“ +1. Speicher: Seitentabellen können sehr sehr groß werden +2. Performanz: je Speicherzugriff (mehrere) Zugriff(e) auf Seitentabelle +3. algorithmische Komplexität: Auftreten von Seitenfehlern (Zugriff auf abwesende Seiten) bei vollständig belegtem physischen Arbeitsspeicher: + 1. Untersuchung: Welche Seite soll verdrängt werden? + 2. Ausführen: Seitenaustauschalgorithmen + 3. viele Prozesse können gleichzeitig aktiv sein: jederzeit kann ein Seitenfehler („Page Fault“) auftreten + +Lösungen +1. mehrstufige Seitentabellen: basieren auf Beobachtung, dass Adressräume häufig nur dünn besetzt sind +2. alternative Datenstrukturen + 1. gesehen: mehrstufige, baumstrukturierte Seitentabellen + - grundsätzlich beliebige Baumtiefe + - können selbst dem Paging unterliegen (belegen dann zwar Adressraum, jedoch physischen Speicher nur dann, wenn sie tatsächlich gebraucht werden) + - Nachteil: Performanz; mehrere Tabellenzugriffe zur Umrechnung einer virtuellen Adresse erforderlich, evtl. dabei erneut Seitenfehler + 2. invertierte Seitentabellen (1 Eintrag je physischer Seite) + - Nachteil: virtuelle Adresse kann nicht mehr als Index zum Finden des Tabelleneintrags verwendet werden → aufwendige Suchoperationen + 3. gehashte Seitentabellen + 4. guarded page tables +3. Seitentabelle in schnellem Register-Array (innerhalb der MMU) + - schnell (keine Speicherzugriffe für Adressumrechnung) + - teuer in der Realisierung (Hardware-Kosten) + - teuer bei Prozess-(Adressraum-)Wechsel (Umladen) + - sinnvoll daher nur für relativ kleine Tabellen +4. Seitentabellen im Arbeitsspeicher, Ort in Adressregister + - schnelle Prozesswechsel (keine Rekonfigurierung der MMU, lediglich Aktualisieren des Adressregisters) + - skaliert für große Seitentabellen + - hohe Adressumrechnungskosten (Zugriff(e) auf Arbeitsspeicher) +5. Seitentabellen im Arbeitsspeicher, Ort in Adressregister, plus Caching von Seitentabelleneinträgen + - „TLBs“ (Translation Look-aside Buffer) + - Aufbewahren benutzter Tabelleneinträge + - basiert auf Lokalität von Speicherzugriffen + - reduziert Adressumrechnungskosten speichergehaltener Seitentabellen + + + +Translation Look-aside Buffer (TLB) +- schneller Cache-Speicher für Seitentabelleneinträge +- lokalisiert in der MMU +- Aufbau eines Cacheeintrags identisch dem eines Seitentabelleneintrags +- Cache-Management: + 1. Invalidierung bei Adressraumwechsel erforderlich! + - Sekundärkosten eines Adressraumwechsels durch „kalten“ TLB + 2. cache-refill bei TLB-miss aus Seitentabelle + 1. durch MMU-Hardware („Page Table Walker“, automatisch) + 2. durch Betriebssystem (nach Aufforderung durch MMU (Interrupt)) + +Ablauf einer Seitenfehlerbehandlung +1. Erkennung durch MMU (present-Bit in Seitentabelleneintrag) +2. Anfertigungung einer Seitenfehlerbeschreibung +3. Auslösung eines Seitenfehler-Interrupts; hierdurch: + - a) Unterbrechung der auslösenden Instruktion (mittendrin!) + - b) Aufruf der Seitenfehlerbehandlung (ISR des VMM); dort: + - Suche eines freien Seitenrahmens + - evtl. explizit freimachen (auslagern); + - Auswahl: strategische Entscheidung durch Seitenaustauschalgorithmus + - Einlagern der fehlenden Seite vom Hintergrundspeicher + - z.B. von lokaler Festplatte + - z.B. über LAN von Server + - Aktualisierung des Seitentabelleneintrags (physische Adresse, present-Bit) +4. Fortsetzung des unterbrochenen Prozesses + +### Seitenaustausch-Algorithmen +Problem: Seitenfehler bei vollständig belegtem physischen Arbeitsspeicher + +Strategie: Welche Seite wird verdrängt? + +Optimale Strategie: Auslagerung derjenigen Arbeitsspeicherseite, deren ... +1. nächster Gebrauch am weitesten in der Zukunft liegt (dazu müsste man Hellseher sein) +2. Auslagerung nichts kostet, dazu müsste man wissen, ob eine Seite seit ihrer Einlagerung verändert wurde + +im Folgenden: einige Algorithmen, die sich diesem Optimum annähern +1. First-In, First-Out (FIFO) +2. Second-Chance +3. Least Recently Used (LRU) +4. Working Set / WSClock + +#### First-In , First-Out (FIFO) +- Annahme: Je länger eine Seite eingelagert ist, desto weniger wahrscheinlich ist ihre zukünftige Nutzung +- Strategie: Auslagerung der ältesten Seite +- Realisierung + - Einlagerungsreihenfolge merken, z.B. durch FIFO-organisierte Seitenliste + - Auslagerung derjenigen Seite, die am „out“-Ende der Liste steht +- Wertung + - einfacher Algorithmus + - effizient implementierbar (Komplexität: Listenoperationen in O(1)) +- Beobachtung: soeben ausgelagerte Seiten werden oft wieder benötigt + - Annahme stimmt oft nicht (entfernt z.B. alte, aber oft benutzte Seiten) + +#### Second Chance (Variante des FIFO-Algorithmus) +- Annahme + -statt: Je länger eine Seite eingelagert ist, desto weniger wahrscheinlich ist ihre zukünftige Nutzung + - nun: Je länger eine Seite nicht mehr benutzt wurde, desto weniger wahrscheinlich ist ihre zukünftige Nutzung +- Strategie + - Eine FIFO-gealterte Seite bekommt eine 2. Chance, falls die Seite während des Alterns benutzt wurde (used-Bit der MMU) + - Verjüngungskur: + 1. Umsortieren der Seite ans junge Ende der FIFO-Liste, + 2. Löschen des used-Bits +- Wertung + - einfacher Algorithmus + - effizient implementierbar + - used-Bit der MMU + - Listenoperationen in O(1) + - bessere Ergebnisse im Vergleich zu FIFO → die „Kur“ wirkt + - zutreffendere Seitenmerkmale berücksichtigt: Zeitpunkt der letzten Nutzung + - aber immer noch sehr grobgranular: 16 GByte physischer Adressraum u. 4 KByte Seitengröße: ~4.000.000 Seiten im physischen Adressraum -> Prüfintervall ~ 4.000.000 Seitenfehler + +#### Least Recently Used (LRU) +- Annahme: Je länger eine Seite nicht mehr benutzt wurde, desto weniger wahrscheinlich ist ihre zukünftige Nutzung (also dieselbe wie 2 nd Chance) +- Strategie: Feinere Granularität: genauere Nutzungszeitpunkte je Seite +- Notwendiges Wissen: ist teuer + 1. Speicher: Nutzungszeitpunkte für jede Seite des Prozess-Adressraums (einige Millionen) + 2. Laufzeit: Aktualisierung bei jedem Speicherzugriff (einige Milliarden/Sekunde) +- Griff in die Trickkiste + - Hardware-Unterstützung speziell für diesen Algorithmus (MMU) + - eine logische Uhr + - tickt bei jeder ausgeführten Prozessorinstruktion + - wird bei jedem Arbeitsspeicherzugriff in den Seitentabelleneintrag der betroffenen Seite eingetragen + - die am längsten nicht mehr benutzte Seite hat dann den ältesten Uhrenstand + - Software-Realisierungen: Annäherung des Hardware-Tickers + +Variante 1 +- jeder Seitentabelleneintrag erhält Zählerfeld +- periodisch (nicht bei jedem Zugriff, wäre zu teuer) wird für residente Seiten + 1. used-Bit zu diesem Zähler addiert + 2. used-Bit anschließend gelöscht +- Ergebnis + - recht effizient implementierbar + - Zählerwert: nur Annäherung der Nutzungshäufigkeit + - daher: suboptimale Ergebnisse + +Variante 2 +- jeder Seitentabelleneintrag erhält Zählerfeld (wie eben) +- periodisch wird + 1. der Zähler aber gealtert: nach rechts verschoben (= Division durch 2) + 2. das used-Bit jetzt in das höchstwertige Bit des Zählers geschrieben + 3. das used-Bit anschließend gelöscht +- Ergebnis + - recht effizient implementierbar + - Zähler: enthält jetzt einen Alterungsfaktor + - Annäherung an Zeitpunkt der letzten Nutzung + - bessere Annäherung an LRU-Grundannahme + - bessere Ergebnisse + +#### Working Set +- Annahmen + 1. Arbeitsspeicher-Zugriffsmuster von Prozessen besitzen „hot spots“: Bereiche, innerhalb derer fast sämtliche Zugriffe stattfinden + 2. hot spots: bewegen sich während des Prozessablaufs relativ langsam durch den virtuellen Adressraum + 3. die zu den hot spots eines Prozesses gehörenden Seiten nennt man seine Arbeitsmenge (Working Set) +- Idee + 1. Zugriffe auf Seiten der Arbeitsmenge: sind erheblich wahrscheinlicher als auf nicht zur Arbeitsmenge gehörende Seiten + 2. Auslagerungskandidaten: sind Seiten, die zu keiner der Arbeitsmengen irgendeines Prozesses gehören + +Bestimmung der Arbeitsmenge eines Prozesses +1. Wann gehört eine Seite dazu? Beobachtung der Speicherzugriffe +2. Wann tut sie es nicht mehr? Beobachtungs-Zeitfenster der Größe + +> Definition: Die Arbeitsmenge $W_p (t, \tau)$ eines Prozesses p zum Zeitpunkt t ist die Menge der virtuellen Seiten, die p innerhalb des Intervalls $[t-\tau , t]$ benutzt hat. + +Quantifizierung von $\tau$: +- asymptotisches Verhalten +- für $\tau$ existieren sinnvolle Schranken + +Beobachtung von Arbeitsspeicherzugriffen: ist teuer +- Speicher: Zeitpunkt der letzten Nutzung für jede Seite eines VA (Linux: Billionen/VA) +- Zeit: Aktualisierung bei jedem Speicherzugriff (Milliarden/Sekunde) +- also auch hier gesucht: gute Annäherung (vgl. LRU) + +Schema der Implementierung +- wir brauchen + 1. used-Bit der MMU + 2. virtuelle Laufzeit der Prozesse +- das VMM + 1. stempelt benutzte Seiten (used-Bit) periodisch mit virtueller Laufzeit des Eigentümers (prozessindividuell) + 2. löscht deren used-Bits + +- Wir kennen damit (ungefähr) die Zeitpunkte der letzten Nutzung aller Seiten aller Prozesse (ausgedrückt in virtueller Prozesslaufzeit). +- Wir können damit ausrechnen: Die Arbeitsmengen aller Prozesse +- Wir nutzen diese nun zur Bestimmung von Auslagerungskandidaten +- Wann? → Genau dann wenn + 1. ein Seitenfehler auftritt und + 2. kein Seitenrahmen (im Arbeitsspeicher) frei ist +- Wie? + 1. Bestimmung der Arbeitsmenge $W_p$ eines Prozesses p zum Zeitpunkt t mit + - $z_s$ als Zeitstempel einer Seite $s\in VA_p$ + - $v_p(t)$ als virtueller Prozesszeit von p zum Zeitpunkt t + - $\tau$ als Beobachtungsintervall gilt: + - $s\in W_p(t,\tau)\leftrightarrow z_s\geq v_p(t)-\tau$ + 2. Bestimmung der Auslagerungskandidaten + - Seite s ist Auslagerungskandidat zum Zeitpunkt t $\leftrightarrow$ s gehört zu keiner Arbeitsmenge, d.h. + - $s\not\in\bigcup_{p\in P} W_p(t,\tau)$ + - $\exists$ kein Kandidat: Auswahl gemäß LRU-Regel + - $\exists$ mehrere Kandidaten: Auslagerungskosten berücksichtigen (dirty-Bit) + +Algorithmus zur Kandidatenbestimmung: +```cpp +for p in P + W_p ← null; + for s in PA + if s in VA_p OR z_s >= v_p(t)-tau then W_p ← W_p + {s}; +kandSet ← PA-U + W_p ; +``` + +Bewertung: +- bei zutreffender Grundannahme (hot spots): sehr gute Ergebnisse +- Effizienz: Arbeitsmenge kann schon vor einer Prozessreaktivierung eingelagert werden („prepaging“) + - schneller Prozessanlauf +- Kosten + - periodisch: + 1. Löschen der used-Bits sämtlicher PA-Seiten + 2. Stempeln (z.B. 16GB → 2 21 Seiten, verteilt auf die Seitentabellen der Prozesse) + - je Suche eines Auslagerungskandidaten + - Bestimmung sämtlicher Working Sets: $O(|P|*|PA|)$ + - Bestimmung der Auslagerungskandidaten: $PA- U_{p\in P} W_p$ + +2 Methoden zur Kostenreduzierung +1. Trennung + - Seitentabellen der Prozesse und + - Seitentabelle zur Buchführung der Zeitstempel (nur auf Seiten im PA kann überhaupt zugegriffen werden) + - Reduzierung der Tabellenzugriffe bei Stempeln und W p –Bildung +2. Nutzung von Informationen der letzten Suche (soo viel hat sich seitdem nicht geändert) + - Reduzierung der Suchoperationsanzahl +- WSClock , der heute wohl meistgebrauchte Paging-Algorithmus + +#### WSClock +Umsetzung: +- Zeitstempel-Datenstruktur: ringartige Liste der Seiten im physischen Adressraum („Uhren-Zifferblatt“) +- Kandidatensuche: je Seite Zugehörigkeit zum Working Set prüfen +- Zustandsinformationen: Ende der letzten Suche (Uhrzeiger) +- Stopp der Suche: sobald eine Seite $s\not\in U_{p\in P} W_p$ gefunden wird + +- Beobachtung: hot spots → individuelle Arbeitsmenge je Prozess +- Idee: Verdrängung von nicht zu einer Arbeitsmenge gehörenden Seiten +- Realisierung: Arbeitsmengenbildung über Zeitstempel der letzten Nutzung + +effizient implementiert durch +1. Zeitstempel virtueller Prozesslaufzeit in den Seitentabellen (Hardware) +2. periodische Inspektion des used-Bits (vgl. LRU) +3. Nutzung vorausgegangener Scan-Ergebnisse durch zifferblattartige Datenstruktur der Seiten im physischen Adressraum + +### Zusammenfassung +- Ziele: + 1. großer Arbeitsspeicher  virtuelle Adressräume + 2. Isolation von Prozessen  private Adressräume +- Methoden und Techniken + - Abbildung vm p : VA p → PA + - effizient implementiert durch MMU: Seitentabellen + 1. Abbildung: $vm_p: VA_p\rightarrow PA$ + 2. Zugriffsüberwachung: Rechte, Anwesenheit + 3. Statistik: used, dirty +- Problembereiche + 1. sehr große Seitentabellen/Adressräume: mehrstufige (/invertierte/gehashte) Seitentabellen + 2. Zugriffszeit auf Seitentabelle: TLBs + 3. $|VA_p| >> |PA|$: Paging, Seitenaustauschalgorithmen + +## Segmentierung +Das Problem: Arbeitsspeicher aus Sicht eines Prozesses -> strukturiert, typisiert + +Probleme des Speichermanagements der Compiler und Linker +- Bibliotheken + - a) dynamisch gebunden: Adressen (Code, Daten) zur Übersetzungszeit unbekannt + - b) gemeinsame Nutzung: Relokation der Adressen zur Nutzungszeit nicht möglich +- Speichertypen + - vom Compiler organisierte statische Datensegmente (Programmvariablen) + - vom Compiler organisierte dynamische Datensegmente (Stacks) + - vom Prozess zur Laufzeit organisierte dynamische Datensegmente (Heaps) („new“: malloc, shared segments) + +Dies alles in einem eindimensionalen, linearen Adressraum + +Strukturierung des Arbeitsspeichers → Zweidimensionales Adressraum-Layout +- n Segmente (z.B.16384 bei Intel Pentium Architektur) +- je Segment eigener linearer Adressraum, z.B. Adressen 0..2 32 -1 +- je Segment individuelle Schutzmöglichkeiten, z.B. rw oder x + +Aufbau einer Arbeitsspeicheradresse eines Programms (erzeugt vom Compiler/Linker): 2-dimensional + +Gewinn +1. typisierte Segmente (Code, Daten, Stack) mit dediziertem Zugriffsschutz + - Robustheit, Sicherheit +2. je Segment beginnen Adressen bei 0 + - komfortabel für Compiler/Linker, gemeinsame Nutzung (Bibliotheken, IPC) +3. viele Segmente + - Organisierbarkeit; Shared Libraries, DLLs + +## VMM- Abstraktionen in der Praxis +Wir kennen nun die Abstraktionen des VMMs zum Umgang mit physischem Speicher: +1. private Adressräume + - schaffen Illusion individuellen Arbeitsspeichers je Prozess +2. virtuelle Adressräume + - schaffen Illusion beliebig großen Arbeitsspeichers +3. Segmente + - schaffen Abstraktion typisierten 2-dimensionalen Arbeitsspeichers +4. Schutzmechanismen auf Seiten- und Segmentebene + +Nutzung von Sicherheits- und Robustheitseigenschaften +- Standard: Isolation + 1. Anwendungsprozesse untereinander + 2. Anwendungs- und Systemprozesse + +## Zusammenfassung +1. viele Prozesse + - Relokation, Swapping +2. Prozess-Adressraum >> physischer Adressraum + - virtueller Speicher +3. Isolation von Anwendungsprozessen + - private Adressräume +4. strukturierter und typisierter 2D-Arbeitsspeicher + - Segmentierung +5. differenzierter Zugriffsschutz auf Segmente und Seiten + - schützt Prozesse vor eigenen Fehlern + - schützt Betriebsystem vor Anwendungsprozessen +6. effiziente Realisierungen: + - Hardware: MMUs + +Adressraum-Layout beeinflusst massiv +1. Sicherheitseigenschaften +2. Robustheitseigenschaften +3. Korrektheitseigenschaften +4. Performanzeigenschaften + +Architekturprinzipien +1. monolithische Betriebssystem-Architekturen + - großer, monolithischer Betriebssystem-Adressraum + - aus Performanzgründen oft in private Adressräume der Anwendungsprozesse eingeblendet (s. Linux-Beispiel) +2. mikrokernbasierte Architekturen + - feingranulare Adressraum-Isolation, auch zwischen Betriebssystem-Komponenten +