Anbindung zum Betriebssystem (BS)

Transkript

1 7.1 Einleitung Anbindung zum Betriebssystem (BS) Aufgaben BS Schnittstelle von der Software zur Hardware Sicherstellung des Betriebs mit Peripherie Dienste erfüllen für Benutzung Rechner durch Verwaltung der Ressourcen Dateiverwaltung (Kopieren, Verwalten,.) Speicherverwaltung (HW-Unterstützung hierfür Thema dieses Kapitels) Prozessverwaltung Prozess: laufendes Programm + Zusatzinformation (Bedingungsflags, Programmzähler, Speicher-, Registerinhalte, E/A-Status) WS 2013/14, Folie 1

2 7.1 Einleitung Schutzmechanismen bereitstellen Z.B. für Mehrbenutzerbetrieb, falls Fehler im Programm durch falsche Zeiger entstehen Und noch viel mehr. (s. Vorlesung Systemprogrammierung) Wichtig für Rechnerarchitektur: Schnittstelle zur Hardware WS 2013/14, Folie 2

3 7.1 Einleitung Betriebssystem; führt neue Befehle und Merkmale oberhalb der Ebene der Befehlssatz-Architektur ein. Die Betriebssystemebene enthält die Schnittstelle zum Anwendungsprogrammierer. Betriebssystem ist in Software implementiert Applikation Betriebssystem Befehlssatz-Architektur (Mikroprogramme bzw. RISC- Befehle) Hardware WS 2013/14, Folie 3

4 7.1 Einleitung Neue Befehle des Betriebssystems Systemaufrufe (system calls) Aktiviert vordefinierten Betriebssystemdienst Z.B. Daten aus einer Datei lesen Kann über Mikroprogramm bzw. Assemblerprogramm implementiert werden Vorsicht! (siehe Bild vorher) Mikroprogramm über Assembler nach wie vor direkt aufrufbar Jedoch erzeugen manche Befehle Exceptions, z.b. wenn versucht wird, Bereiche zu adressieren, die privilegiert sind Speicherverwaltung im Fokus dieses Kapitels Konzept virtueller Speicher Speicherverwaltungseinheit Memory Management Unit (MMU) Berechnet aus virtueller Adresse die physikalische Adresse Unterstützt das Betriebssystem bei Sicherheitsmaßnahmen, d.h. Vermeiden von Zugriffen auf bestimmte Speicherbereiche WS 2013/14, Folie 4

5 7.2 Speicherverwaltung Memory Management Idee des Virtuellen Speichers Frühe Tage der EDV Speicher war knapp NB: hier hat sich im Prinzip nichts geändert (Speicher ist immer knapp) Programme waren zu groß, um komplett im Speicher unterzukommen Idee: Zerlegen in sog. Überlagerungsprogramme (Overlays) Overlays auf Sekundärspeicher (Festplatte) auslagern Programmierer war eigenverantwortlich für die Verwaltung der Overlays Overlays waren explizit abzulegen Overlays waren explizit einzulesen schlecht für Programmierer WS 2013/14, Folie 5

6 7.2 Speicherverwaltung Memory Management Idee: Programmierer könnte sich zumindest einen großen Speicher vorstellen einen sog. virtuellen Speicher mit virtuellen Adressen Virtuellen (im Prinzip unendlichen) Speicher abbilden in physikalischen (limitierten) Speicher durch Abbildung der einzelnen Adressen virtuelle Adresse physikalische Adresse WS 2013/14, Folie 6

7 7.2 Speicherverwaltung Memory Management Grundlegendes Konzept Trennung in virtueller Adressraum physikalischer Adressraum (Speicherstellen) Virtuelle Adresse Adressraum Vor Erfindung des virtuellen Speichers nur 1-zu-1 Abbildung K- Hauptspeicher WS 2013/14, Folie 7

8 7.2 Speicherverwaltung Memory Management Virtuellen Speicher partitionieren in Overlays gleicher Größe Nächste Partition ab virtueller Adresse 4096 auf physikalische ab Adresse 0 abbilden Wie realisiert Im Prinzip mit in Hardware realisierten Tabellen. Details, s. später Adressraum Abbildung Virtuelle Adresse K- Hauptspeicher WS 2013/14, Folie 8

9 7.2 Speicherverwaltung Memory Management Virtuelle Speicherverwaltungen (Demand) Paging Speicherseiten gleicher Größe, einfachere Verwaltung Nachteil: internen Verschnitt Segmentierung Nicht nur ein Programm, viele Programme Nachteil: externe Speicherfragmentierung Segmentierung + Paging Vorteile beider Verfahren vereinen WS 2013/14, Folie 9

10 7.2.1 Paging Annahme: Im physikalischen Arbeitsspeicher steht Programmkode mit virtuellen Adressen zwischen 0 und 4095 Es erfolgt eine Sprung auf die virtuelle Adresse zwischen 8192 und NB: identische Problematik für Referenzen auf Datenbereiche außerhalb des im physikalischen Speicher gehaltenen Overlays Was tun? Inhalt des im Arbeitsspeicher vorhandenen Overlays (Seite) auf Platte speichern Warum? Programmkode-Abschnitt könnte globale Variablen erhalten, die verändert wurden Overlay (Seite) mit Worten von 8192 bis suchen Overlay (Seite) von der Platte in den Hauptspeicher laden Adresszuordnungen auf ändern Programmausführung fortsetzen WS 2013/14, Folie 10

11 7.2.1 Paging Das Ein-/Auslagern von diesen Seiten soll automatisch geschehen (nicht durch Programmierer) Diesen Vorgang bezeichnen wir nun als Paging Folgende Notation im Folgenden (s. nächste Folie) WS 2013/14, Folie 11

12 7.2.1 Paging Automatisches Ein-/Auslagern von Overlays Seitenauslagerung (Paging) Von Festplatte gelesene Programm-(Daten)blöcke, bisher Overlays genannt Seiten (Pages) Adressraum, auf den ein Programm verweisen kann Virtueller Adressraum (Virtual Address Space) Die real fest verdrahteten Speicheradressen Physikalischer Adressraum (Physical Address Space) Abbildung virtuelle in physikalische Adresse Speicherabbildung (Memory Mapping) realisiert über in Hardware umgesetzte Seitentabelle (Page Table) WS 2013/14, Folie 12

13 7.2.1 Paging Dieses Konzept 1961 für den ATLAS-Computer erstmalig von Fotheringham, Universität Manchester, eingesetzt: Anfang der 70er Jahre war Konzept des virtuellen Speichers etabliert Wird heute direkt von Mikroprozessoren unterstützt. Die Verwaltung des virtuellen Speichers ist heutzutage gleich im Mikroprozessorsystem integriert Nehalem-Architektur (z.b. Core i7 Prozessor) hat den Memory-Controller gleich auf Prozessor-Chip integriert WS 2013/14, Folie 13

14 7.2 Speicherverwaltung Memory Management Ziel: Abbildung muss für Programmierer völlig transparent geschehen (soll heißen ohne sein aktives Zutun) Illusion eines im Prinzip beliebig großen, linear adressierbaren Hauptspeichers (z.b. von 0 ab aufwärts) Seitenein-/auslagerung geschieht im Hintergrund Hardware-Unterstützung dafür notwendig WS 2013/14, Folie 14

15 7.2.1 Paging Praktische Implementierung Paging Auch Virtueller Adressraum bekommt in der Regel Obergrenze Virtueller Adressraum wird eingeteilt in Seiten gleicher Größe Größen von 512 Byte 4 MB pro Seite Immer 2er Potenz Hauptspeicher kann mehr als nur eine Seite aufnehmen Im Gegensatz zur Situation auf Folie 7 (dort nur eine 4K große Seite) Vorgesehener Platz im Arbeitsspeicher für Aufnahme der Seiten heißt Seitenrahmen (Page frame) WS 2013/14, Folie 15

16 7.2.1 Paging Beispiel: 64 K virtueller Adressraum (16 Seiten à 4K Seitengröße) 32 K physikalischer Speicherraum (8 Seiten à 4K Seitengröße) Seitennummer Virtuelle Adressen über Tabelle Seitennummern abbilden WS 2013/14, Folie 16 Seitennummer Physikalische Adressen

17 7.2.1 Paging Allgemeines Prinzip der Abbildung über Seitentabellen über virtuelle Seitennummer in Seitentabelle Eintrag holen Spalte Valid zeigt an, ob virtuelle Seite im Speicher ist oder nicht sofern Seite im Speicher ist Eintrag enthält zugehörige Nummer der physikalischen Seite sofern Seite nicht im Speicher Eintrag enthält Verweis, aus dem hervorgeht, wo Seite auf Platte zu finden ist WS 2013/14, Folie 17

18 7.2.1 Paging Bildung der physikalischen Adresse Adresse besteht aus der Seitennummer und dem Offset, der auf die Adresse innerhalb der Seite verweist Der Offset ist bei der physikalischen und der virtuellen Adresse identisch Die Abbildung der virtuellen auf die zugehörige physikalische Seitennummer (Seitenrahmen) erfolgt über die Seitentabelle Beispiel rechts: Virtuelle 32-Bit Adresse 4 G(iga) = 2 32 Physikalische 30-Bit Adresse 1 G(iga) = 2 30 Größe der Seite (12-Bit Offset-Adresse) 4 K(ilo) = 2 12 WS 2013/14, Folie 18

19 7.2.1 Paging Bildung der physikalischen Adresse Nummer der physikalischen Seite (Seitenrahmen) über Seitentabelle ermitteln Diese Nummer konkatenieren mit Offset physikalische Adresse WS 2013/14, Folie 19

20 7.2.1 Paging Quantitative Größen für vorheriges Beispiel Virtuelle 32 Bit-Adresse in physikalische 30 Bit- Adresse abbilden Einzelne Seiten 4K groß (= 2 12 ) Wie viele Einträge in Seitentabelle? So viele, wie es virtuelle Seiten gibt = Größe virtueller Speicher / Seitengröße => 2 32 / 2 12 = 2 20 Wie viele Seitenrahmen? Größe Physikalischer Speicher / Seitengröße => 2 30 / 2 12 = 2 18 benötige somit 18 Bit jeder Eintrag in Seitentabelle 18 Bit + 1 Valid Bit breit Folglich Größe Seitentabelle 2 20 x 19 Bit = 19 MBit = 2,375 MByte WS 2013/14, Folie 20

21 7.2.1 Paging Zusammenfassung der Abbildung virtuelle in physikalische Adresse beim (eindimensionalen) Paging Virtuelle Adresse wird zerlegt in Seitennummer und Offset Seitennummer abbilden auf Nummer Seitenrahmen Realisiert über Seitentabelle Offset zeigt in den Seitenrahmen Physikalische Adresse ist Konkatenation aus Seitenrahmen- Nummer und Offset Valid-Bit Ist Seite im physikalischen Speicher? WS 2013/14, Folie 21

22 7.2.1 Paging Seitenanforderung (Demand paging) # (Anzahl) Seitenrahmen < # virtuelle Seiten Analoge Situation wie bei Cache (Cacheblock Hauptspeicherblock) Folglich wird es Situationen geben, in denen eine virtuelle Seite nicht in einem Seitenrahmen vorliegt Seitenfehler (Page fault) Tritt Seitenfehler auf BS muss angeforderte Seite auf Platte suchen und lesen Mit anderer im Speicher vorhandener virtuellen Seite austauschen Seitentabelle entsprechend ändern Es existieren verschiedene Strategien für Seitenaustausch (Swapping). Dies ist nicht Thema in CE1 bzw. GRa, sondern in SP WS 2013/14, Folie 22

23 7.2.1 Paging Nachteil Paging: Interne Fragmentierung Wenn Programme und Daten gerade Vielfaches der Seitengröße sind keine Platzverschwendung Wird i.d.r. nicht der Fall sein Folglich: Verschnitt Verschwendete Bytes: Interne Fragmentierung Beispielrechnung: Bytes benötigt: 4 K Byte Größe Seitenrahmen Rechnung Tafel Besser kleine oder große Seitenrahmen bzgl. interner Fragmentierung? WS 2013/14, Folie 23

24 7.2.2 Segmentierung bisher Paging: eindimensionaler virtueller Adressraum Flexibler: mehrere virtuelle Adressräume (genannt Segmente) Motivation warum mehrere Adressräume flexibler Erleichtert Modulbildung Z.B. bei Dynamischen Zuwachs von Daten Beispiel Compilerlauf Speicherbedarf nimmt ständig zu für Symboltabelle (Verwalten von Variablen) Speicher für Aufnahme Quelltext Für Konstantentabelle Für Syntaxbaum Speicherbedarf schrumpft und wächst abwechselnd für benutzten Stack aufgrund von Prozeduraufrufen des Compilers WS 2013/14, Folie 24

25 7.2.2 Segmentierung Situation bei eindimensionalen virtuellen Adressraum Einzelnen Segmente wachsen von fester unterer Bodenadresse Evtl. wachsen sie in den Bereich anderer Segmente, hinein s. Segment für Symboltabelle wächst in Segment, das Quelltext aufnimmt Mögliche Lösung: Programmierer gezwungen 1-dimensionalen Adressraum zu verwalten WS 2013/14, Folie 25

26 7.2.2 Segmentierung Bessere Lösung: mehrere vollkommen unabhängig voneinander vorhandene Adressräume so genannte Segmente WS 2013/14, Folie 26

27 7.2.2 Segmentierung Vorteil Segmente: Können unabhängig wachsen und schrumpfen Unterstützen Modularisierung bei der Programmierung Jede Prozedur eigenes Segment mit Anfangsadresse 0 Aufruf anderer Prozedur (Segmentnummer, Adresse 0) Nachträgliche Änderungen an Prozedur leichter Immer Einstieg bei Adresse 0 Bei eindimensionalem Adressraum nicht möglich WS 2013/14, Folie 27

28 7.2.2 Segmentierung Einbinden von Bibliotheken Nicht jedes Programm braucht Kopie der Bibliothek NB: Ist auch mit Paging machbar wenn mehrere Seiten zu einem virtuellen Segment zusammengefast werden Unterstützen Schutzmechanismen leichter Angabe Segmentlänge Wird Adresszeiger erzeugt, der über Segmentlänge hinauswächst wird eine sog. Exception generiert -> in der Betriebssystem-Software führt evtl. zum Abbruch des Prozesses WS 2013/14, Folie 28

29 7.2.2 Segmentierung WICHTIG: Segment ist logische Einheit Programmierer kennt diese und muss diese explizit verwenden Auch hier muss Umsetzung in eine physikalische Adresse erfolgen Aus sog. Segmenttabelle über Segmentnummer die zugehörige Anfangsadresse ermitteln NB: Externe Fragmentierung tritt auf! Details: s. Vorl. SP Arbeitsspeicher Segment -nummer Physikalische Segmentanfangs -Adresse Segmentlänge 3 0x5500 0x x4000 0x x3000 0x x0100 0x0200 Segmenttabelle 0x5500 0x4000 0x3000 0x0100 } 0x0400 } 0x0200 } 0x0400 } 0x0200 WS 2013/14, Folie 29

30 7.2.2 Segmentierung Segmenttabelle enthält Segmentdeskriptoren Daher manchmal auch als Deskriptortabelle bezeichnet Über Segmentlänge überprüfbar, ob Zugriffe innerhalb des Segmentes bleiben Adresse bilden aus Addition Segmentanfangsadresse + Offsetadresse Virtuelle Adresse Segment-Nr. Offset-Adresse # Segmenttabelle Anfang Länge < N Fehler an BS melden WS 2013/14, Folie 30 + Physikalische Adresse

31 7.2.2 Segmentierung Auch hier Swapping Referenziertes im Speicher nicht vorhandenes Segment wird nachgeladen Falls kein Platz vorhanden: Ein oder mehrere Segmente müssen auf Platte geschrieben werden Im Prinzip wie bei Demand Paging Entscheidender Unterschied Bei Demand Paging: Seitengrößen identisch Hier: Segmentgrößen unterschiedlich WS 2013/14, Folie 31

32 7.2.3 Segmentierung + Paging Paging hatte durchaus Vorzüge: Berechnung der physikalischen Adresse einfacher, da Seiten immer gleich groß Konkatenation aus Seitenanfangsadresse (ermittelt über Seitentabelle) und Offset i.a. sind jedoch die Seitentabellen größer und benötigen mehr Aufwand als die Segmenttabellen, letztere dadurch leichter in schnellen Registern zu halten Jedoch gilt für Paging: Zugriffe über Cache-Techniken optimierbar (s. später TLB) Adressrechnung bei Segmentierung: erfordert Addition Keine externe Fragmentierung: (Details s. Vorl. SP) Idee: Kombination von Segmentierung und Paging Idee: jedes Segment intern in Seiten aufteilen Alle Verfahren die beim Paging entwickelt wurden nutzbar Neu: für jedes Segment jetzt eigene Seitentabelle Erstmalig angewandt im Betriebssystem MULTICS Adressbildung s. nächste Seite WS 2013/14, Folie 32

33 7.2.3 Segmentierung + Paging Adressbildung bei Segmentierung mit Paging Quelle: Tannenbaum; Computerarchitektur: 7.Auflage, Kap. 6, S WS 2013/14, Folie 33

34 7.2.4 Vergleich Segmentierung / Paging Vor- und Nachteile ein- und mehrdimensionaler logischer Adressen WS 2013/14, Folie 34

35 7.2.4 Vergleich Segmentierung / Paging Heutzutage: zumeist Paging Wegen des Vorteils, dass sich Programmierer nicht explizit um Segmente kümmern muss Jedoch nicht ein Prozess, sondern mehrere Prozesse Jeder Prozess hat seine eigene Seitentabelle Problem jedoch Aufwand für Seitentabellen Für einen Prozess (s. Bsp. Folie 20) nicht so dramatisch Jedoch für eine Vielzahl von Prozessen ist der Aufwand nicht zu unterschätzen WS 2013/14, Folie 35

36 7.3 Optimierungen bei der Speicherverwaltung Zwei Ansatzpunkte zum Optimieren Platz: Aufwand für Speicherung Tabellen reduzieren Z.B. Mehrstufiges Paging Geschwindigkeit: Zugriffszeit auf Tabellen reduzieren Mittels so genannter TLBs (Translation Lookaside Buffer) Platzreduzierung: In der Literatur ist eine Reihe von Maßnahmen aufgeführt In Patterson/Hennessy, Computer Organization & Design, 4.Auflage, S. 500, sind allein 5 Maßnahmen aufgeführt Hier in Vorlesung wird nur die Technik der Einteilung der Seitentabelle in mehrere Ebenen ( mehrstufiges Paging ) behandelt Zugriffsoptimierung per TLB: Im Prinzip Caches für Zugriff auf Seitentabelle WS 2013/14, Folie 36

37 7.3 Optimierungen bei der Speicherverwaltung Platz reduzieren: mehrstufiges Paging Im eindimensionalen Fall (nur eine Seitentabelle) braucht man immer so viele Einträge, wie es virtuelle Seiten geben könnte Dies für mehrere Prozesse bereit zu halten, wäre unakzeptabel viel Aufwand Idee: jeder Prozess erhält ein Verzeichnis, ein sog. Seitenverzeichnis Jeder Eintrag im Seitenverzeichnis verweist auf eine Seitentabelle Der Eintrag kann leer sein, wenn der Prozess den Adressraum nicht braucht Spart Speicher Die Einträge in den Seitentabellen zeigen - wie üblich - in die Seitenrahmen (physikalischen Seiten) Idee führt somit zur mehrstufigen Seitenverwaltung (mehrstufiges Paging) WS 2013/14, Folie 37

38 7.3 Optimierungen bei der Speicherverwaltung Beispiel x86-architekturen Die ersten 10 Bits verweisen auf das Seitenverzeichnis Die zweiten 10 Bits in die jeweilige Seitentabelle CR3 PDBR: Page Directory Base Register WS 2013/14, Folie 38

39 7.3 Optimierungen bei der Speicherverwaltung Rechenbeispiel: Ein Prozess benötigt den virtuellen Adressbereich 0x00bc0000-0x00bc1fff für sein Codesegment (entspricht bzgl. der Größe genau 2 physikalischen Seiten á 4 KiByte Seitengröße) Dies erzeugt folgende Aufteilung DIR PAGE OFS bis x002 0x3c0 0x3c1 1. physikalische Seite 2. physikalische Seite WS 2013/14, Folie 39

40 7.3 Optimierungen bei der Speicherverwaltung graphische Darstellung der Verzeigerung der Tabellen Seitentabelle 0x000. Seitenverzeichnis 0x3c0 0xZ Z 0xZ Z000 0x000 0x3c1 0xY Y 0x x002 0xX X 0x3ff. 0xZ Zfff.. 0x3ff. 0xY Y000 0xY Yfff Physikalische Seite 1. Physikalische Seite 2... Vergleich Aufwand eindimensional mehrdimensional, s. Tafel WS 2013/14, Folie 40

41 7.3 Optimierungen bei der Speicherverwaltung Zugriff optimieren: Translation Lookaside Buffer Voll-assoziativer Cache für virtuelle Adressen aus Seitentabelle (im Prozessor realisiert) WS 2013/14, Folie 41

42 7.3 Optimierungen bei der Speicherverwaltung Adressbildung insgesamt Translation Lookaside Buffer, Seitentabelle und Cachezugriff Beispiel hier: Cachen der physikalischen Adresse Es gibt auch eine Lösung, bei der die logischen Adressen im Cache stehen WS 2013/14, Folie 42