Kapitel 6

2020-12-15 11:25:09 +01:00 · 2020-12-15 11:25:09 +01:00 · a43f9546b0
commit a43f9546b0
parent eed34f2170
1 changed files with 557 additions and 5 deletions
--- 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 
+  - Semaphore und Hoare‘sche Monitore: blockierend, pessimistisch 
-  - b) transaktionaler Speicher: neu, optimistisch, transaktional
+  - transaktionaler Speicher: neu, optimistisch, transaktional
-  - c) Botschaften: kein gemeinsamer Speicher, Datentransport
+  - Botschaften: kein gemeinsamer Speicher, Datentransport
-  - d) Fernaufrufe, Systemaufrufe: „Spezialisierungen“
+  - Fernaufrufe, Systemaufrufe: „Spezialisierungen“
-  - e) Ereignismanagement: Interrupts, Unterbrechungen auf Anwendungsebene
+  - 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