Kapitel 8 Speicherverwaltung

Präsentation zum Thema: "Kapitel 8 Speicherverwaltung"—  Präsentation transkript:

1 Kapitel 8 Speicherverwaltung
Systeme 1 Kapitel 8 Speicherverwaltung WS 2009/10

2 Speicherverwaltung Speicherverwaltung:
Aufteilung des verfügbaren Hauptspeichers zwischen Betriebssystem verschiedenen Prozessen. Speicherverwaltung erfordert enges Zusammenspiel von Hardware und Betriebssystem. Zur Erinnerung: Zu jedem Prozess gehört ein Adressraum: zugeordneter Arbeitsspeicher mit minimalen und maximalen Adressen Enthält Ausführbares Programm, Programmdaten und Kellerspeicher (“Stack”)‏. WS 2009/10

3 Prozesse Hauptspeicher Code Prozess 1 Code Prozess 2 Daten Prozess 1
Activ. rec. Prozess 1 Activ. rec. Prozess 2 Prozesstabelle CPU PC Register Stack pointer WS 2009/10

4 Speicher Die ersten Computer wurden als Einheit entwickelt.
Speicher, CPU, etc. wurden aufeinander abgestimmt entwickelt. Keine großen Geschwindigkeitsunterschiede zwischen den Komponenten. Später standardisiertes Design Erlaubte getrennte und spezialisierte Entwicklung einzelner Subsysteme. Manche Subsysteme konnten schneller und besser optimiert werden als andere. Engpässe („Flaschenhals“) entstanden. insbesondere zwischen CPU und Speicher WS 2009/10

5 Speicherhierarchie Registers Upper Level faster Instr./Operands Cache
Blocks Memory Pages Disk Files Tape larger Lower Level WS 2009/10

6 Anforderungen an das Betriebssystem
Grundlegende Anforderungen an Speicherverwaltung: Bereitstellung von Speicher für Betriebssystem und Prozesse Ziel aus Betriebssystemsicht: Möglichst viele Prozesse im Speicher vorhanden. Multiprogramming! 5 Anforderungen nach Lister / Eager: Relokation Schutz Gemeinsame Nutzung Logische Organisation Physikalische Organisation WS 2009/10

7 Relokation Relokation = „Verlagerbarkeit“ Motivation: Problem:
Mehrere Prozesse gleichzeitig im System Auslagern und Wiedereinlagern ganzer Prozesse aus dem Hauptspeicher soll ermöglicht werden. Ort der Einlagerung zum Zeitpunkt der Programmentwicklung / Programmübersetzung unbekannt! Bindung an alten Ort beim Wiedereinlagern sehr ungünstig! Problem: Speicherreferenzen innerhalb des Programms: Absolute Sprungbefehle Datenzugriffsbefehle WS 2009/10

8 Prozesskontrollblock
Relokation Beginn Prozesskontrollinformationen Prozesskontrollblock Programm Daten Einsprungstelle ins Programm Sprung- befehl Zunehmende Adresswerte Referenz auf Daten Programmende Übersetzung der Speicherreferenzen im Programmcode in tatsächliche physikalische Speicheradressen durch Prozessorhardware Betriebssystemsoftware WS 2009/10

9 Schutz Schutz von Prozessen gegen beabsichtigte oder unbeabsichtigte Störungen durch andere Prozesse Folge: Überprüfung aller Speicherzugriffe notwendig Schwierigkeit: Nicht zur Übersetzungszeit eines Programms überprüfbar, da: Dynamisch berechnete Adressen Relokation Dynamische Überprüfung nötig Hardwareunterstützung nötig In Zusammenhang mit Relokation gelöst. Nicht in ausschließlich Software lösbar Betriebssystem benötigt für effektiven Schutz Hardwareunterstützung. WS 2009/10

10 Exkurs: User-/ Kernel-Modell
Ein sogenannter Prozessor-Ring schränkt nutzbare Prozessor-Befehle und Speicherbereiche ein. z.B. x86 Prozessoren haben 4 Ringe Meist werden nur 2 genutzt: Ring 0 (Kernel-Mode)‏ Ring 3 (User-Mode)‏ Kontrollierter Wechsel durch Betriebssystem (später mehr!)‏ WS 2009/10

11 Gemeinsame Nutzung Gemeinsame Nutzung = kontrollierter Zugriff mehrerer Prozesse auf gemeinsam genutzte Bereiche des Speichers Anwendungsbeispiele: Ausführung des gleichen Programms durch eine Reihe von Prozessen Code nur einmal im Speicher Benutzung gemeinsamer Module (z.B. dynamisch gelinkte Bibliotheken)‏ Kooperation von Prozessen über gemeinsam genutzten Datenspeicher („shared memory“)‏ WS 2009/10

12 Logische Organisation
Hauptspeicher ist lineares Feld von Bytes (Wörtern)‏ Dagegen: Logischer Aufbau großer Programme: Sammlung verschiedener Module Unabhängig übersetzt; Referenzen erst zur Laufzeit aufgelöst Verschiedene Module mit verschiedenem Schutz (z.B. nur lesen / ausführen)‏ Gemeinsame Nutzung von Modulen durch verschiedene Prozesse z.B. auch dynamisch gebundene Bibliotheken Betriebssystem muss mit Modulen umgehen können. WS 2009/10

13 Physikalische Organisation
Hier betrachtet: 2 Ebenen: Hauptspeicher (schnell, teuer, flüchtig)‏ Hintergrundspeicher (langsam, billig, nicht flüchtig)‏ Grundproblem: Organisation des Informationsflusses zwischen Haupt- und Sekundärspeicher Prinzipiell möglich: in Verantwortung des Programmierers Aufwändig, erschwert durch Multiprogramming Deshalb: Verwaltung durch das Betriebssystem WS 2009/10

14 Grundlegende Methoden der Speicherverwaltung
Partitionierung Für Speicheraufteilung zwischen verschiedenen Prozessen eher veraltetes Konzept Betriebssysteminterne Nutzung von Partitionierung Paging Einfaches Paging Kombiniert mit Konzept des virtuellen Speichers Segmentierung Einfache Segmentierung WS 2009/10

15 Partitionierung Partitionierung: Verschiedene Varianten:
Aufteilung des Speichers in Bereiche mit festen Grenzen Fester, zusammenhängender Teil des Hauptspeichers für Betriebssystem Pro Prozess ein zusammenhängender Teil des Speichers Verschiedene Varianten: Statische Partitionierung Dynamische Partitionierung Buddy-Verfahren WS 2009/10

16 Statische Partitionierung
Einteilung des Speichers in feste Anzahl von Partitionen 2 Varianten: Alle Partitionen mit gleicher Länge Partitionen mit unterschiedlicher Länge Betriebssystem 8 Mbyte Betriebssystem 8 Mbyte 2 Mbyte 4 Mbyte 12 Mbyte 16 Mbyte WS 2009/10

17 Statische Partitionierung
Probleme: Programm zu groß für Partition Programmerstellung durch Overlays nötig (aufwändig!)‏ Interne Fragmentierung: Platzverschwendung, wenn Programm kleiner als Größe der zugeordneten Partition Fest vorgegebene Anzahl von Prozessen im Speicher Bei Laden von Prozessen in Speicher: evtl. Auslagern von anderen Prozessen Zuweisung von Partitionen an Prozesse: Bei Bereichen mit gleicher Länge: trivial Bei Bereichen mit variabler Länge: Kleinste verfügbare Partition, die gerade noch ausreicht? Wenn Speicherbedarf nicht feststellbar, dann helfen nur Overlays oder virtueller Speicher! WS 2009/10

18 Dynamische Partitionierung
Einteilung des Speichers in Partitionen variabler Länge und variabler Anzahl Prozesse erhalten exakt passende Speicherbereiche Ein- und Auslagern führt zu externer Fragmentierung! (vgl. auch Kapitel Dateisysteme)‏ WS 2009/10

19 Dynamische Partitionierung
BS, 8MB BS, 8MB BS, 8MB BS, 8MB 56 MB Prozess 1 20 MB Prozess 1 20 MB Prozess 1 20 MB 36 MB Prozess 2 14MB Prozess 2 14MB 22MB Prozess 3 18 MB 4 MB BS, 8MB BS, 8MB BS, 8MB BS, 8MB Prozess 1 20 MB Prozess 1 20 MB Prozess 1 20 MB Prozess 2 14 MB 6 MB P. 4, 8MB P. 4, 8MB P. 4, 8MB 6 MB 6 MB 6 MB Prozess 3 18 MB Prozess 3 18 MB Prozess 3 18 MB Prozess 3 18 MB 4 MB 4 MB 4 MB 4 MB WS 2009/10

20 Dynamische Partitionierung
Defragmentierung erforderlich! Aufwändig Speicherverdichtung nur erfolgreich, wenn dynamische Relokation möglich (Speicherreferenzen werden nicht ungültig!)‏ Speicherzuteilungsalgorithmen: Best Fit: Suche kleinsten Block, der ausreicht. First Fit: Suche beginnend mit Speicheranfang bis ausreichender Block gefunden. Next Fit: Suche beginnend mit der Stelle der letzten Blockzuweisung. WS 2009/10

21 Dynamische Partitionierung
Analyse von Speicherzuteilungsalgorithmen: Im Schnitt ist First Fit am besten! Next Fit: Etwas schlechter Typischer Effekt: Schnelle Fragmentierung des größten freien Speicherblocks am Ende des Speichers Best Fit: Am schlechtesten Produziert schnell eine Reihe von sehr kleinen Fragmenten, die ohne Defragmentierung nie mehr benutzt werden können. Zudem: langsames Verfahren WS 2009/10

22 Buddy-System Nachteil statische Partitionierung:
Beschränkte Anzahl nicht-ausgelagerter Prozesse Interne Fragmentierung Nachteil dynamische Partitionierung: Defragmentierung nötig, wegen externer Fragmentierung Buddy-System (Halbierungsverfahren): Kompromiss zwischen statischer und dynamischer Partitionierung Eigenschaften: Anzahl nicht-ausgelagerter Prozesse dynamisch Interne Fragmentierung beschränkt Keine explizite Defragmentierung WS 2009/10

23 Buddy-System Prinzip: Verwalte Speicherblöcke der Größe 2K, L ≤ K ≤ U
2L = Größe des kleinsten zuteilbaren Blocks 2U = Größe des größten zuteilbaren Blocks (z.B. Gesamtgröße des Speichers)‏ Zu Beginn: Es existiert genau ein Block der Größe 2U. Anforderung eines Blocks der Größe s: Bei 2U-1 < s ≤ 2U: Weise gesamten Speicher zu. Sonst: Teile auf in 2 Blöcke der Größe 2U-1 . Bei 2U-2 < s ≤ 2U-1: Weise einen der beiden Blöcke zu. Sonst: Wähle einen der beiden Blöcke aus und teile. … Fahre fort bis zu Block der Größe 2K mit 2K-1 < s ≤ 2K . Bei resultierendem Block ist der „Verschnitt“ kleiner als die halbe Blockgröße. WS 2009/10

24 Buddy-System Verwalte f.a. L ≤ K ≤ U Listen mit freien Blöcken der Größe 2K . Allgemeiner Fall: Anforderung eines Blocks der Größe 2i-1 < s ≤ 2i: Vergebe Block aus Liste i, wenn vorhanden. Sonst: Wähle Block aus nächstgrößerer nichtleerer Liste. Teile rekursiv auf, bis ein Block der Größe 2i vorhanden. Wenn nach Freigabe eines Blocks der Größe 2K der entsprechende Partnerblock der Größe 2K ebenfalls frei war: Verschmelze die Blöcke zu einem Block der Größe 2K+1 . Mache rekursiv mit Verschmelzen weiter. WS 2009/10

25 Buddy-System Beispiel: Annahme:
Speicher der Größe 1 GB Folge von Anforderungen und Freigaben: A fordert 100 MB an. B fordert 240 MB an. C fordert 64 MB an. D fordert 256 MB an. Freigabe B Freigabe A E fordert 75 MB an. Freigabe C Freigabe E Freigabe D Annahme: Obergrenze der Blockgröße: 1 GB, Untergrenze: 64 MB WS 2009/10

26 Buddy-System Zunächst verfügbar:
Freie Blöcke: 1 GB: MB: MB: MB: MB: 0 1 GB Es folgt Anforderung A: 100 MB, d.h. Block der Größe 128 MB. WS 2009/10

27 Buddy-System Nach Anforderung A: 100 MB, d.h. Block der Größe 128 MB:
Freie Blöcke: 1 GB: MB: MB: MB: MB: 0 1 GB A: 128 MB Es folgt Anforderung B: 240 MB, d.h. Block der Größe 256 MB. WS 2009/10

28 Buddy-System Nach Anforderung B: 240 MB, d.h. Block der Größe 256 MB
Freie Blöcke: 1 GB: MB: MB: MB: MB: 0 1 GB A: 128 MB B: 256 MB Es folgt Anforderung C: 64 MB, d.h. Block der Größe 64 MB. WS 2009/10

29 Buddy-System Nach Anforderung C: 64 MB, d.h. Block der Größe 64 MB
Freie Blöcke: 1 GB: MB: MB: MB: MB: 1 1 GB A: 128 MB C:64MB B: 256 MB Es folgt Anforderung D: 256 MB, d.h. Block der Größe 256 MB. WS 2009/10

30 Buddy-System Nach Anforderung D: 256 MB, d.h. Block der Größe 256 MB
Freie Blöcke: 1 GB: MB: MB: MB: MB: 1 1 GB A: 128 MB C:64MB B: 256 MB D: 256 MB Es folgt Freigabe B. WS 2009/10

31 Buddy-System Nach Freigabe B: Es folgt Freigabe A. Freie Blöcke:
1 GB: MB: MB: MB: MB: 1 1 GB A: 128 MB C:64MB D: 256 MB Es folgt Freigabe A. WS 2009/10

32 Buddy-System Nach Freigabe A:
Freie Blöcke: 1 GB: MB: MB: MB: MB: 1 1 GB C:64MB D: 256 MB Es folgt Anforderung E: 75 MB, d.h. Block der Größe 128 MB. WS 2009/10

33 Buddy-System Nach Anforderung E: 75 MB, d.h. Block der Größe 128 MB:
Freie Blöcke: 1 GB: MB: MB: MB: MB: 1 1 GB E: 128 MB C:64MB D: 256 MB Es folgt Freigabe C. WS 2009/10

34 Buddy-System „Buddies“ Bei Freigabe C: Freie Blöcke:
1 GB: MB: MB: MB: MB: 2 1 GB E: 128 MB D: 256 MB „Buddies“ WS 2009/10

35 Buddy-System Nach Freigabe C: Es folgt Freigabe E. Freie Blöcke:
1 GB: MB: MB: MB: MB: 0 1 GB E: 128 MB D: 256 MB Es folgt Freigabe E. WS 2009/10

36 Buddy-System „Buddies“ Bei Freigabe E: Freie Blöcke:
1 GB: MB: MB: MB: MB: 0 1 GB D: 256 MB „Buddies“ WS 2009/10

37 Buddy-System „Buddies“ Bei Freigabe E: Freie Blöcke:
1 GB: MB: MB: MB: MB: 0 1 GB D: 256 MB „Buddies“ WS 2009/10

38 Buddy-System Nach Freigabe E: Es folgt Freigabe D. Freie Blöcke:
1 GB: MB: MB: MB: MB: 0 1 GB D: 256 MB Es folgt Freigabe D. WS 2009/10

39 Buddy-System „Buddies“ Bei Freigabe D: Freie Blöcke:
1 GB: MB: MB: MB: MB: 0 1 GB „Buddies“ WS 2009/10

40 Buddy-System „Buddies“ Bei Freigabe D: Freie Blöcke:
1 GB: MB: MB: MB: MB: 0 1 GB „Buddies“ WS 2009/10

41 Buddy-System Nach Freigabe D:
Freie Blöcke: 1 GB: MB: MB: MB: MB: 0 1 GB Gesamter Speicher wieder als 1 Block verfügbar. WS 2009/10