Technische Informatik II (TI II) (8) Speicherverwaltung. Sebastian Zug Arbeitsgruppe: Embedded Smart Systems

Transkript

1 1 Technische Informatik II (TI II) (8) Speicherverwaltung Sebastian Zug Arbeitsgruppe: Embedded Smart Systems

2 2 Fragen an die Veranstaltung Nach welchen Merkmalen lässt sich der Speicher in einem Rechner unterscheiden? Welche Entwicklungskonflikte ergeben sich daraus? Erläutern Sie die Begriffe externe und interne Fragmentierung. Woraus resultieren die Vorteile des Buddy Verfahrens? Vergleichen Sie die Anwendung einer Bitmap und einer Listenstruktur zur Verwaltung des Partitionszugriffes. Erklären Sie die Idee des virtuellen Speichers. Wie erfolgt die Abbildung der logischen Speicheradresse auf die physikalische bei der Anwendung von segmentorientiertem/seitenorientiertem Zugriff? Erläutern Sie die Konzepte Inverse Seitentabelle und mehrstufige Seitentabelle? Warum finden diese überhaupt Anwendung?

3 3 Literatur Bücher Operating System Concepts, Abraham Silberschatz Webseiten

4 4 Speicherverwaltung Wozu braucht man eine Speicherverwaltung? Welche Eigenschaften sollte ein Speicher haben? unendlich groß, unendlich schnell, unendlich billig, nichtflüchtig (?), kein Effekt durch konkurrierende Zugriffe (?), Schutz vor fehlerhaften Zugriffen (?). Die Speicherverwaltung hat das Approximieren dieser Eigenschaften zum Ziel!

5 5 Speicherverwaltung sehr teuer sehr billig sehr schnell schnell langsam sehr langsam registers scratchpad caches RAM ROM Disk DVD-ROM CD-ROM Tape on-chip on-board Hintergrund einzelner CPU Zyklus einzelner in-/ externer Buszyklus ms-minutes 0, sec 0, sec 0,001 sec

6 6 Ist das nur bei großen Rechnern ein Problem?

7 7 Speicherwaltungsebenen Register Scratchpad wird explizit vom Programmierer/Compiler kontrolliert Cache RAM ROM Disk DVD-ROM CD-ROM Tape Hardware-Kontrolle RAM Abstraktion flüchtig Dateiabstraktion persistent unter Kontrolle des Betriebssystems

8 8 Monoprogramming mit Speicherpartitionen Das alleinig laufende Programm hat Zugriff auf den gesamten Speicher. user program BS in ROM user program Geräte Treiber im ROM user program 0xFFF... BS im RAM BS im RAM 0x00...

9 9 Multiprogramm-Speicherpartitionierung Partition 7 Partition 6 Partition 5 Partition 4 Partition 3 Partition 2 Partition 1 BS Partition 4 Partition 3 Partition 2 Partition 1 BS Probleme bei gleichgroßen Partitionen: Ineffiziente Nutzung des Speichers -> INTERNE FRAGMENTIERUNG Overlay-Lösungen für Programme, die nicht in eine Partition passen Eigenschaften: Größe der Speicherblocks konstante Größe variable Größe Zeitpunkt der Allokation off-line (statisch) zur Laufzeit (dynamisch)

10 10 Verwaltung fester Partitionen mehrere Warteschlangen eine Warteschlange Partition 4 Partition 4 Partition 3 Partition 3 Jedes Element einer WS hat spez. Speicherbedarf, der in etwa (d.h. Bedarf Partition) mit der zugehörigen Partition übereinstimmt. Partition 2 Partition 2 Partition 1 BS Partition 1 BS

11 11 Multiprogramming mit dynamischen Speicherpartitionen Feste Partitionen Variable Partitionen Laufzeit allokiert Problem: interne Fragmentierung Anfangs- Situation nach einiger Zeit Problem: externe Fragmentierung benötigt aufwändigere Verwaltung Eigenschaften: Größe der Speicherblocks konstante Größe variable Größe Zeitpunkt der Allokation off-line (statisch) zur Laufzeit (dynamisch)

12 12 Variable Speicherpartitionierung - Buddy-System initial 1M block 1 M request 100 k 128 k 128 k 256 k 512 k request 240 k request 60 k 128 k 128 k 256 k 128 k 64 k 64 k 256 k 512 k 512 k request 250k 128 k 64 k 64 k 256 k 256 k 256 k release 128 k 64 k 64 k 256 k 256 k 256 k release 128 k 64 k 64 k 256 k 256 k 256 k request 75 k 128 k 64 k 64 k 256 k 256 k 256 k release 128 k 128 k 256 k 256 k 256 k release 512 k 256 k 256 k release 1 M

13 13 Herausforderung: Relokation Ein-/Auslagern: Jedes Prozessabbild wird vollständig vom Speicher auf die Platte geschoben und umgekehrt, mit seinen Code-, Daten- und Stackbereichen. Programm 1? Freispeicherverwaltung Ersetzungsstrategie Realokation des Programmes Schutzmechanismen

14 14 Dynamische Partitionen mit Ein-/Auslagern (Swapping) Problem: Wo sind freie Blöcke und welche Größe haben sie? Bitmapdarstellung: = allozierter Block 0 = Loch Darstellung durch verkettete Liste: P 0 3 H 4 2 P 5 5 H 10 2 nächstes Element

15 15 Berücksichtigung terminierender Prozesse bei der Verwaltung von Listen Auswechseln einseitig verschmelzen beidseitig verschmelzen

16 16 Verwaltung des Speichers first / next fit Start der Suche am Anfang/ fortlaufende in der Liste 0 best fit Kleinste mögliche Lücke nach vollständiger Suche 0 worst fit Größte mögliche Lücke 0? quick fit Zuteilungsalgorithmus mit getrennten Listen für unterschiedliche Löcherkategorien

17 17 Relokation eines Programmes im Speicher 1. Initialisierung eines Programmes im Speicher 2. Ausführung 3. Auslagerung Swapping 4. Erneutes Laden 5. Eintrittspunkt für das Programm Process Kontrollblock Programm Code branch und jump Operationen Daten Daten Referenzen ursprünglicher TOS (top of stack) Stack

18 18 Programmadaption beim Ein-/Auslagern (Swapping) Differenzierung von Adressen: Logische Adresse: Verwendung innerhalb des Programmes, unabhängig von der aktuellen Position im Speicher Relative Adresse: Besondere Form der logischen Adresse, repräsentiert die Distanz zwischen zwei Adressen im Speicher Physikalische Adresse: Absolute Adresse im Hauptspeicher Basis Register Bounds Register Adder Comperator Relative Adresse Absolute Adresse Process Kontrollblock Programm Code Daten Logische Adresse Stack

19 19 ManipulateProgrammCounter.c #include <stdio.h> #include <string.h> void dosomething(int a, int b, int c){ char buffer1[5]; buffer1[0]=0xee; int *ret; ret = buffer1 + 0x15; printf("address of x = %p\n", ret); printf("content of x = %p\n", (*ret)); (*ret) += 0x08; //(*ret) += 0x0123; außerhalb Prozess } Beispiel: Manipulation von Speicherinhalten zug@thinkpad:~$./manipulatepc Address of x = 0xffffcbec Content of x = 0x Value of x is 0 int main(int argc, char *argv[]) { int x; x=0; dosomething(1,2,3); x=1; printf("value of x is %d\n", x); } zug@thinkpad:~$ gcc -o ManipulatePC ManipulatePC.c m32

20 20 Analyse mit GDB (gdb) break dosomething (gdb) run (gdb) info frame Stack level 0, frame at 0xffffcbf0: eip = 0x in dosomething (ManipulateJump.c:4); saved eip = 0x called by frame at 0xffffcc20 source language c. Arglist at 0xffffcbe8, args: a=1, b=2, c=3 Locals at 0xffffcbe8, Previous frame's sp is 0xffffcbf0 Saved registers: ebp at 0xffffcbe8, eip at 0xffffcbec (gdb) x buffer1 0xffffcbd7: 0x printf("address of x = %p\n", ret); (gdb) s Address of x = 0xffffcbec 10 printf("content of x = %p\n", (*ret)); (gdb) s Content of x = 0x

21 21 Zugriffsschutz Problem - Beliebige Referenzen auf Bereiche außerhalb der Partition. Mechanismen: 1. Protektion-Codes (IBM 360) Speicherblöcke fester Länge, die mit einem 4-bit Protection-Code gekennzeichnet sind (tagged memory). Der p-code wird bei jedem Zugriff mit dem entsprechenden Feld des Programm-Status-Worts (PSW) verglichen 2. Base und Bound Register (CDC 6600) Begrenzung des Speichers für einen Prozess durch die Definition einer Basisadresse und einer Größe, in Hardware erfolgt die Prüfung des Zugriffs

22 22 Was haben wir bisher erreicht? Bisher wurde betrachtet: 1. Verwaltung des realen, physischen Speichers. 2. Der Adressraum ist dem Realspeicher angepasst. 3. Ein- und Auslagern von Speicherblocks wird explizit durch das BS vorgenommen. 4. Die Größe der Einheiten wird durch den Programmierer festgelegt. Wünschenswert: Transparenter Mechanismus für das Ein-Auslagern von Speicherblocks. Logischer Adressraum ist sehr viel größer als der Adressraum des Realspeichers. Transparenter Mechanismus zur Relokation. Besserer Zugriffsschutz durch Trennung logischer Adressräume. Idee: Betrachten des Realspeichers als ein Fenster in einen viel größeren Speicher. Trennung von logischem und physikalischem Adressraum.

23 23 Diskussion Fritz-Rudolf Güntsch, Dissertation 1957 Der Programmierer braucht auf das Vorhandensein von Schnellspeichern keine Rücksicht zu nehmen (er braucht nicht einmal zu wissen, dass solche vorhanden sind). Denn es gibt nur eine Sorte von Adressen, mit denen programmiert werden kann, als wäre nur ein Speicher vorhanden. Source:

24 24 Segmentierter virtueller Speicher Segmente Virtueller Adressraum Segment Index logische Adressse Versatz (Offset) Realer Adressraum > Offset Länge base address Basisadresse + reale Adresse 0 Basis- Adresse Segmenttabelle

25 25 Segmentierter Speicher - Beispiel logische Addresse (20 Bit) Segment tabellen index Offset realer Speicher 64 K + Länge Basis im Realspeicher base 1111 address < + physical address (16 Bit) Segmenttabelle Segmenttabellenbasisregister Ausnahme (exception) Virtueller Addressraum: 2 20 = 1 M Max. Anzahl der Segmente: 16 Größe eines Segments: 64 k

26 26 Pentium Registersatz AH BH CH DH AX BX CX DX AL BL CL DL EAX EBX ECX EDX ESI EDI EBP ESP CS: enthält Basis des Code Segments SS: enthält Basis des Stack-Segments DS: enthält Basis des Daten-Segments ES: enthält Basis des Extra-Segments FS: zusätzliches Extra-Segment (ab 386) GS: zusätzliches Extra-Segment (ab 386) CS SS DS ES FS GS EIP EEFLAGS

27 27 Segment-Deskriptoren des Pentium Prozessors Die xs-register enthalten Referenzen auf die 1. Globale Descriptor Table (OS und LDT) oder die 2. Lokale Descriptor Table (lokale Segmente). Ablauf des Zugriffs auf ein Speichersegment: 1) Analyse des Selektors im xs Register Descriptor Table Index (13 Bit) Identifier (1Bit) (GDT =0, LDT = 1) Privilegienstufe (2 Bit) (Ring 0-3) 2) Suche des entsprechenden Eintrages in der GDT oder LDT 3) Berechnung der Korrespondierenden virtuellen Adresse 4) Anfrage an die MMU

28 28 Probleme beim segmentierten virtuellen Speicher Segmente virtueller Adressraum?? realer Adressraum für jedes Segment wird ein zusammenhängender Speicherbereich gebraucht, der möglicherweise recht groß ist Verschnittprobleme, da die Segmente unterschiedlich groß sind Vollständiges Segment muss bei einem Zugriff im Hauptspeicher stehen, obwohl vielleicht nur ein kleiner Teil davon benötigt wird Offset

29 29 Alternative: Seitenorientierter virtueller Speicher virtueller Adressraum Idee: Seiten fester Größe werden auf Kacheln (Seitenrahmen: frames) fester Größe im Hauptspeicher abgebildet. 60k - 64k 56k - 60k 52k - 56k 48k - 52k 44k - 48k 40k - 44k 36k - 40k 32k - 36k 28k - 32k 24k - 28k 20k - 24k 16k - 20k 12k - 16k 8k - 12k 4k - 8k 0k - 4k (virtuelle) Seiten Realspeicher- Adresse 28k - 32k 24k - 28k 20k - 24k 16k - 20k 12k - 16k 8k - 12k 4k - 8k 0k - 4k (reale) Seitenrahmen bzw. Kacheln

30 30 Adressumsetzung mit Seiten logische (virtuelle) Adresse (20 Bit) Seiten tabellen Index Versatz (offset) Real Speicher 64 K = 16 x 4K Kacheln Kachel# (realer Seitenrahmen) reale Adresse (16 Bit) offset Seitentabelle (256 Einträge) Seitentabellenbasisregister virtueller Adressraum: 2 20 = 1 M max. Anzahl der Seiten: 256 max. Größe der Seiten: 4 k

31 31 Kritischer Parameter Seitengröße Zielkonflikte: Seitengröße: large small interne Fragmentierung Management Overhead Ladezeit von der Platte Übliche Seitengrößen liegen zwischen 512 Bytes und 64KB. Heute werden Seitengrößen von 4KB oder 8KB benutzt.

32 32 Größe der Seitentabelle 32-Bit Adressraum: 4G Adressen 64-Bit Adressraum: 4G 4G Adressen 4k: 1M Einträge 4k: 1M 4G Einträge 1. Seitengröße erhöhen: z.b. UltraSPARC II unterstützt 8k, 64k, 512k and 4M Seiten Grund: weniger Seiten Problem: interne Fragmentierung 2. Seitentabellen ein-und auslagern: mehrstufige Seitentabelle Grund: a.)virtueller Teil Speicher ist billig, b.) es wird aktuell immer nur ein kleiner Teil der Seiten benötigt ( working set) Problem: eine zusätzliche Indirektionsstufe 3. Flexible Zuordnung von Tabelleneinträgen: Invertierte Seitentabellen Verfahren: Tabelleneinträge werden Seitenrahmen fest zugeordnet Grund: Der reale Adressraum ist klein im Vergleich zum virtuellen. Problem: viel mehr Seiten als Seitenrahmen keine eindeutige Abbildung

33 33 Mehrstufige hierarchische Seitentabellen 10 bit 10 Bit 12 Bit Wurzel sekundär Kachel offset ST-Basis-Reg Eintr Eintr. Seite Abbildung eines 32Bit Seitentabelleneintrages auf 4kB große Tabellen Protektionsmechanismen auf dem Wurzelknoten Ergebnis: Strukturierung der Seitentabellen zur Reduzierung des Speicheraufwandes Beispiel: Prozess im Speicher Programmsegment/Daten/Lücke/Stack Sollten weitere Stufen eingeführt werden?

34 34 Invertierte Seitentabelle virtuelle Seitennummer offset = hit Hash virtuelle Seitennummer Kachel nummer Hashkette reale Seicheradresse

35 35 Invertiert oder nicht invertiert? Pro invertiert: Seitentabelle ist proportional zur Größe des Realspeichers: z.b. für 1 8k Seiten: 128k Einträge unabhängig von Größe d. virtuellen Adressraumes Con invertiert: Hashing muss bei jedem Speicherzugriff durchgeführt werden. Verkettung kann zu mehrfachen Zugriff führen. benötigt komplexe Ersetzungs-und Verwaltungsstrategien. ABER: Hierarchische Seitentabellen benötigen ebenfalls mehrfachen Zugriff. wenn sekundäre Seitentabellen ausgelagert sind: mehrfacher Plattenzugriff. Hardwareunterstützung wird in allen Fällen benötigt!

36 36 Diskussion: Segmente gegen Seiten Transparenz Anzahl d. virt. Adr. variable Frag- Verw. Hauptgrund für Progr. Adress- raum > realer Objektgr. ment. overhead für Einführung räume Speicher Seitenor. ein intern unendlich viel Speicher Segmentor. viele extern mehrere Adr. räume

37 37 Kombination von Segmenten und Seiten virtuelle Adresse Segm.# Seite# offset Segmentor. Teil Seitenor. Teil Segmenttabelle Seitentab. Kachel offset + Seite + Segm.# Seiten# Segm.-Tab.-Reg

38 38 Zusammenfassung Ziele: unendlich {groß, schnell, billig}, -->Zielkonflikte Verwaltung des physischen Speichers: Interne und externe Fragmentierung Lokale und globale Listenverwaltung Buddy System Virtueller Speicher: Segmentierung: Seitenorientierung: + private Adressräume, Schutz - Segment muss in physischen Speicher passen + riesiger linearer Adressraum - Schutz, Problem der Seitentabellen

39 39 Bis zur nächsten Woche