Memory Management, Virtual Memory -...

1

Januar 19ZHAW, BSy, M. Thaler1

Memory Mangement

Memory Management,Virtual MemoryTanenbaum Kap. 3

Stallings Kap. 7, 8

Glatz Kap. 7

2


Inhalt

� Lehrziele

� Memory Management

• Prozesse im Speicher

• logische / physikalische Adressen

• Swapping

� Einfaches MM

• fixed Partitioning

• dynamic Partitioning

• Placement

• Buddy System

• Paging

• (Segmentation)

� Diskussion

3


Lehrziele: Memory Management

� Sie können

• die Begriffe logische und physikalische Adresse erklären und diskutieren

• erklären, um was es beim Swapping geht

• die grundlegenden Verfahren des Memory Managements aufzählen und diskutieren

• Paging erklären und diskutieren

4


Memory Managment: um was geht es ?

� Uniprocessing

• ein Prozess und das Betriebssystemstehen im Speicher

� Multiprogramming

• mehrere Prozesse und das BSstehen im Speicher

• div. Verwaltungsprozesse

• bessere CPU-Nutzung

� Programmierer / Anwender

• will sich nicht um Speicher kümmern

� transparente Speicherverwaltung notwendig

zum Beispiel

• Multiprogramming

- mehrere Prozesse werden gleichzeitig verarbeitet

- aktive Prozesse müssen im Speicher stehen

- wenn zu wenige Prozesse im Speicher

� die meisten Prozesse warten auf I/O

� der Prozessor hat nichts zu tun: ist "idle"

- keine Voraussage möglich

� wann ein Prozess verarbeitet wird

� wo ein Prozess im Speicher steht

- Implikationen

� Prozess muss an beliebigen Ort im Speicher stehen können

� Anzahl Prozesse durch Speichergrösse beschränkt

� Prozessgrösse muss bekannt sein

• Weitere Anforderungen

- Programmierer/Anwender will sich im Allgemeinen nicht um Speicher-verwaltung kümmern

- Speicherhierarchie notwendig, weil schneller Speicher teuer

5


Zwei Ansätze

� Einfaches Memory Management

• ganzer Prozess im Speicher

• einfaches Paging

• einfache Segmentation

• typische Anwendung: "kleine Systemen"

- Eingebettete Systeme, Echtzeitsysteme, Palmtops, etc.

� Virtual Memory

• aktiver Teil des Prozesses im Speicher

- Rest ist auf den Sekundärspeicher ausgelagert

• Paging

• Hard- und Softwareunterstützung notwendig

• typische Anwendung in "grossen Systemen"

- Workstation, Server, PCs, etc

• Zwei grundlegende Lösungsansätze

- einfaches Memory Management (basic memory management)

� ganzer Prozesse steht im Speicher

� traditioneller Ansatz

� Anwender oft selbst für Memory Management verantwortlich, z.B. mit overlays, etc.

- virtual memory (VM)

� die aktiven Teile des Prozesses stehen im Speicher

� virtualisiert den Speicher

• Anwender sieht gesamten Adressraum des Prozessors unabhängig von der Grösse des physikalischen Speichers

� Betriebssystem verwaltet physikalischen Speicher transparent

• Wieso kann Virtual Memory bei Embedded Systems oft nicht eingesetzt werden ?

6


Was gehört zu Memory Management ?

� Logical Organisation

• logischer Adressraum, lineare Folge von Bytes (Words)

• "was sieht der Anwender"

� Physical Organisation

• physikalische Realisierung: Cache-, Haupt- und Sekundärspeicher

• "was sieht das Betriebssystem"

� Protection

• verhindern, dass sich Prozesse gegenseitig beeinflussen

� Sharing

• gemeinsame Speicherbereiche zur Verfügung stellen

� Relocation

• verschieben eines Prozesses an beliebigen Ort im Speicher

• Logical Organisation

- logischer Adressraum, lineare Folge von Bytes

- logische Segmente: Programm, Daten, Stack

- Vorteile

� verschiedene Zugriffsrechte möglich

� gemeinsame Nutzung von Modulen (Adressierung zur Laufzeit gelöst)

• Physikalische Organisation

- Verwaltung der Speicherhierarchie

- Hauptspeicher: Programme in Ausführung

- Sekundärspeicher: Zwischen- und Langzeitspeicherung

- Datenfluss zwischen Haupt- und Sekundärspeicher: Teil des MemoryManagements

• Protection

- Prozesse müssen getrennte Adressräume haben

� keine gegenseitige Beeinflussung möglich (z.B. Pointer-Fehler)

� Adressen müssen zur Laufzeit überprüft werden

- Betriebssystem braucht eigenen Speicherbereich

• Sharing

- z.B. shared memory für kooperierende Prozesse

• Relocation:

- Prozesse müssen auf Disk aus- und eingelagert werden � Swapping

- Prozesse stehen nicht immer am gleichen Ort im physikalischen Speicher

� ev. müssen Prozess im Speicher verschoben werden

7


Memory Management: Prozesse

� Prozesse und Adressraum

"Ladevorgang"

Adressraumbelegung(logisch)

0x0000000

Adre

ssen

Programm Code

Daten

Heap

Stack

Betriebssystem

Programm Code

Daten

Stack

Process ControlBlock

Process Control

Information

Entry Point to

Program

Current top

of stack

increasing

address

values

Adressraum Prozess(logsich)

• Prozesse bestehen aus

- einem Prozesskontrollblock

- dem Programm

- dem Datenbereich

- dem Stack

• Speicherreferenzen in Prozessen

- Referenzen auf Instruktionen bei Sprungbefehlen

- Referenzen auf Datenwerte

- unabhängig von Platzierung im physikalischen Speicher

- Folgerung

� Abbildung zwischen logischen und physikalischen Adressen notwendig

8


Logische/physikalische Adressen

� Logische Adresse

• Referenz auf Speicherplatz, unabhängig von Speicherorganisation

� Physikalische Adresse

• Referenz auf physikalischen Speicherplatz

� Compiler

• erzeugen Code mit relativen (logischen) Adressen

CPUlogische

Adresse

logischer Adressraum

Memorypysikalische

Adresse

physikalischer Adressraum

?MMU

MemoryManagement

Unit

• Adressübersetzung

- CPU erzeugt logische bzw. virtuelle Adresse

- logische Adressen sind relativ, meist bezogen auf Adresse 0

- muss schnell und transparent sein -> Hardwareunterstützung notwendig

• Beispiel: Hardwareunterstützung für Relocation

- wird heute nur noch von sehr wenigen Rechnern gebraucht

� Addition eher langsam

- Base Register entspricht den Segmentregistern beim x86

9


Begriffe: Swapping

Betriebs-system

User Space

Main Memory

Disk

Prozess P1

swap out

Prozess P2

swap in

Prozess P1

Prozess P2

• Oft haben nicht alle Prozesse im Speicher Platz

- Swapping

� auslagern eines Prozesses vom Speicher auf Disk resp. umgekehrt

� gilt auch für Teiles eines Prozesses (virtual memory)

- ausgelagerter Prozess: Prozess ist suspendiert

• Anmerkung: heute steht viel Speicher zur Verfügung

- es können sehr viele Prozesse im Speicher gehalten werden

- der gesamte Prozess kann im Spiecher stehen

10


Einfaches Memory Management

� Voraussetzungen

• gesamter Prozess steht im Hauptspeicher

• unterstützt Multiprogramming

• für kleine / einfache Systeme

� Mögliche Memory Management Verfahren

• Addressraum zuteilen

- fixed partitioning

- dynamic partitioning

- placement

• Addressraum aufteilen

- paging

- (segmentation)

11


Fixed Partitioning

Partitionen gleich gross

internes Fragment

Operating System8M

8M

8M

8M

8M

8M

8M

8M

OperatingSystem

OperatingSystem

Partitionen verschieden gross

• Aufteilung des Hauptspeichers in mehrere nicht überlappende Partitionen

- das Betriebssystem belegt i.A. eine feste Partition

- vorgegebene Anzahl Prozesse im Speicher

- wenn alle Partitionen besetzt sind, kann das BS Prozesse auslagern

- falls Programm zu gross für eine Partition ist

� Anwender � Programm mit Overlays realisieren (das Programm lädt benötigte Module selbst und überschreibt nicht benötigte Module)

• Gleich grosse Partitionen

- jedes Programm, egal wie gross, belegt eine Partition- Partiotion nicht vollständig gefüllt: wird internal fragmentation genannt- Nutzung des Hauptspeichers ineffizient

• Verschieden grosse Partitionen

- reduzieren das Problem � lösen es nicht

- für jede Partition eine Prozess Queue

� Prozesse der kleinstmöglichen Partition zuweisen

� versucht interne Fragmentierung zur minimieren

� Problem: Queues bleiben leer, wenn keine entsprechenden Prozesssvorhanden sind � mehr Swapping

- für alle Partitionen eine Prozess Queue

� Prozesse der kleinsten verfügbaren Partition zuweisen

� Verbesserung bezüglich Multiprogramming

� Problem: erhöhte interne Fragmentierung

12


Dynamic Partitioning

externeFragmente

OperatingSystem

OperatingSystem

Process 2

Process 1

OperatingSystem

Process 2

Process 1

OperatingSystem

Process 1

OperatingSystem

Process 1

Process 3

OperatingSystem

Process 4

Process 1

Process 3

OperatingSystem

Process 4

Process 3

OperatingSystem

Process 4

Process 3

Process 2

Process 3

• Grösse und Anzahl der Partitionen variabel

- jedem Prozess soviel Speicher zuweisen, wie er benötigt

• Problem: externe Fragmentatierung

- im Hauptspeicher bilden sich mit der Zeit Löcher

- Grund: Prozesse werden ausgelagert und können nicht immer durch gleich grosse Prozesse ersetzt werden

- Compaction notwendig

� Prozesse verschieben, bis Löcher geschlossen

13


Next Fit

Best Fit

First Fit

Placement Algorithmen (dynamic partitioning)

� Gesucht: Block mit 16MByte

• welchen freien Speicher-Bereich allozieren ?

8M

12M

22M

18M

8M

6M

14M

36M

Last Allocated

Plazierung

• Diskussion

- First Fit

� einfachster Algorithmus, i.d.R. auch am schnellsten und besten

� alloziert Blöck eher in Nähe des Speicheranfangs

� Tendenz: weniger Fragmentatierung als bei Next-Fit

- Next Fit

� alloziert oft freien Block am Schluss des Speichers

� Blöcke am Ende des Speichers oft am grössten

� Tendenz: Compaction öfter notwendig als bei first-fit

- Best Fit

� sucht kleinsten Block passenden Block

� minimiert externes Fragmente zum nächsten Block

� Tendenz: es entstehen schnell viele kleine Fragmente

� i.A. schlechtester Algorithmus: Compaction muss öfters durchgeführt werden als bei bei First Fit und Next Fit

• Replacement Algorithmen

- wenn nicht alle Prozesse im Speicher Platz finden

� Betriebssystem muss Prozess auslagern und durch anderen Prozess ersetzen

� welcher Prozess soll ausgelagert werden ?

� Diskussion: später zusammen mit Virtual Memory

14


512K 512K

1 M

Buddy System

� Kompromiss

• zwischen fixed und dynamic Partitioning

• schneller Allokations- und Deallokationsalgorithmus

• Unix/Linux Kernel verwenden modifizierte Buddy Systeme

1 M

request 100k

request 240k

release A

release B

512K 512K256 K 256 K

128 K

128 K 128 KA = 128 K

512K256 K128 KA = 128 K B = 256 K

512K256 K128 KA = 128 K B = 256 K256 K

128 K 512K256 K128 KA = 128 K 256 K256 K 512K

1 M

• Buddy Algorithmus

- es werden solange Blöcke halbiert, bis ein Block minimaler Grösse zur Verfügung steht

- Daten zum den Freien Blöcken lassen sich mit einem Binärbaum darstellen

- effiziente Algorithmen verfügbar (siehe Lit., z.B. Stallings)

• Unix verwendet modifiziertes Buddy System für die Allokation von Kernel Memory

- Modifikation basiert auf Beobachtung, dass Kern während gewisser Zeit immer gleich grosse Speicherblöcke anfordert -> lazy recombination

- lazy recombination

� Buddies werden nicht sofort zusammengeführt, sondern erst wenn ein grösserer Block benötigt wird

• Linux verwendet Buddy System für Speicherallokation

- Slab Allocator

15


Paging

� Problemstellungen bis jetzt

• Fixed Partitioning

- interne Fragmentierung

• Dynamic Partitioning

- externe Fragmentierung

- erfordert Compaction

• Prozesse belegen zusammenhängenden Speicherbereich

� Paging

• Prozesse in Blöcke gleicher Länge aufgeteilt: Pages

• Speicher in Blöcke gleicher Länge aufgeteilt: Frames

• Zuweisung Pages � Frames beliebig

- Konsequenz: Prozess müssen nicht zusammenhängendim physikalischen Speicher stehen

Programm Code

Daten

Heap

Stack

Page

• Paging

- der logische Adressraum der Prozesse wird in Pages aufgeteilt

- der physikalische Adressraum wird in Frames (Page Frames) aufgeteilt

- Pagegrösse = Framegrösse

- heute übliche Pagegrössen: 1KB, 4KB, 8KB

• Die Speicherwaltung bildet Pages auf Frames ab

- Zuweisung beliebig

- Frames müssen nicht einen zusammenhängen Block bilden � Prozesse auf beliebige Frames verteil

- Effizienz: Abbildung in Hardware (siehe Virtulal Memory)

16


Paging: Beispiel

� 4 Prozesse

• PA: 4 Pages

• PB: 3 Pages

• PC: 4 Pages

• PD: 5 Pages

� Speicher

• 16 Frames

� Ablauf

PA wird geladen

PB wird geladenPC wird geladen

Prozess PB blockiertwird ausgelagert

Prozess PD geladen

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

0

1

2

3

0

1

2

3

4

5

6

7

-

-

-

0

1

2

3

4

5

6

7

7

8

9

10

0

1

2

3

4

5

6

7

4

5

6

11

12

0

1

2

3

4

5

6

7

PageTabellen

PBPA PC PD

13

14

15

free

• Wie weiss das Betriebssysten welche Frames zu welchen Prozessen gehören ?

• Pro Prozess unterhält das Betriebssystem eine Page Tabelle

- Pagenummer referenziert Tabelleneintr äge

- Einträge enthalten die Framenummer der physikalischen Adresse

- Liste mit freien Blöcken notwendig

0

2

3

4

0

1

2

3

4

5

6

7

-

-

-

0

1

2

3

4

5

6

7

7

8

9

10

0

1

2

3

4

5

6

7

4

5

6

11

12

0

1

2

3

4

5

6

7

PageTabellen

PBPA PC PD

13

14

15

free

17


... Paging

� Wie logisch Adresse in pysikalische Adresse übersetzen ?

6 Bit Page Nr. 10 Bit Offset

0 0 0 0 0 1 0 1 1 1 0 1 1 1 1 0

16 Bit logische Adresse

0 0 0 1 0 1

0 0 0 1 1 0

0 1 1 0 0 1

0

1

2

Page Tabelle0 0 0 1 1 0 0 1 1 1 0 1 1 1 1 0

16 Bit physikalische Adresse

Offset478

6 Bit Frame Nr. 10 Bit Offset

Page 0

Page 1

Page 2

logischer Adressraum

physikalischer Adressraum kann kleinerals logischer Adressraum sein

• Jede logische Adresse (N Bit) besteht aus zwei Feldern

- einer Pagenummer

� k höherwertige Bits der Adresse

- einem Offset

� m tieferwertige Bits der Adresse

� Pagegrösse = 2m � immer Zweierpotenz

� Offset vom Beginn der page

- es gilt: N = k + m

• Pagetabelle

- jeder Prozess hat eine eigene Pagetabelle

- enthält für jede Pagenummer die entsprechende Framenummer

- die Pagenummer ist dient als Referenz (Adresse) zum Lesen der Framenummer

• Anmerkungen

- die letzte Page (Frame) ist nicht unbedingt "voll" � interne Fragmentierung, Fragmentierung aber klein

- Paging ist für Anwender transparent

- Anzahl Bits der Frame Nummer ≤ Anzahl Bits der Page Nummer

• Daten zum Beispiel

- logische Adresse 16 Bit

- Pagenummer 6 Bit � maximal 64 Pages

- Offset 10 Bit � page size = 1KB

- Einträge in der Tabelle ≤ 64

18


Segmentation

� Anwenderprogramme � mehrere Segmente

• Programm

• Daten

• Stack

� Segmente

• verschiedene Grösse

• zusammenhängender Adressraum

• können im Speicher an beliebigem Orte plaziert werden

• keine interne, aber externe Fragmentierung

• für Programmierer sichtbar

• Segmentation

- für Programmierer resp. Compiler sichtbar, im Gegensatz zu Paging

- hilft Programme logisch zu organisieren

- Programmierer muss Grenzen der Segmente kennen

- vereinfacht die Handhabung von wachsenden Datenstrukturen

- erlaubt Programme unabhängig zu verändern

- unterstützt die Nutzung gemeinsamer Daten

- unterstützt Schutz des Speichers

- externe Fragmentierung

� geringer, weil Prozess aus mehreren kleinen Partitionen

• Das BS muss pro Prozess eine Segmenttabelle unterhalten

- physikalische Startadresse des Segments

- Länge des Segments (Schutz)

19


Paging vs. Segmentation

� Paging

• für Programmierer transparent

• kleine, interne Fragmentierung

• Adressübersetzung: Tabellen-Lookup

• Schutz auf Ebene von logischen Segmenten

� Segmentation

• für den Programmierer sichtbar

• externe Fragmentierung

• Adressübersetzung: Tabellen-Lookup und Addition

• Schutz von physikalischen Segmenten

� Kombination: Paging und Segmentation möglich

• Vorteile beider Verfahren nutzbar, z.B. ab Intel 80486

• nur OS/2 hat dieses Verfahren je genutzt

20


Virtual Memory

Virtual MemoryTanenbaum Kap. 4

Stallings Kap. 7, 8

Glatz Kap. 7

21


Inhalt

� Virtual Memory

• Problemstellung

• Kontrollstrukturen & Hardware

- Funktionsweise

- Adressübersetzung

- (Segmentation)

- Page Size

• MM Software

- Page Replacement

- Resident Set Management

- Load Control

- Implementationsaspekte

- Zusammenfassung

22


Virtual Memory

� Bis jetzt

• gesamter Prozess muss im Speicher stehen

• Prozessgrösse wird durch pysikalischen Speicher bestimmt

• Speicher i.A. << als Adressbereich (Zukunft 64 Bit Adressraum)

- ca. 16 GB in 16 EB1) Adressraum (aktuell 48 Bit: 256 TB)2)

• Programmierer muss sich um Programmgrösse kümmern

- früher sehr aufwendig

� Programme in so genannte Overlays aufteilen

� Betriebssystem lädt benötigte Overlays vom Disk

� Ist das sinnvoll bzw.notwendig ?

1) Exa Byte: 260 B 2) Tera Byte: 240 B

• Realität

- beschränkter Hauptspeicher, kann oft nicht alle Prozesse gleichzeitig aufnehmen

- Speicherbereiche für Interrupttabellen und Betriebssystem

- Speicherbereiche sind nicht kontinuierlich, noch andere Prozesse im Speicher

- Speicher wird billiger und grösser

� mehrere GB Hauptspeicher ist heute realistisch

� 64-Bit System sind im Kommen (z.Z. 48 Bit phys. Speicheradressen möglich � 64 GByte)

• Anmerkung

- 264 = 1.845 1019 = 18.45 1018 = 18.45 Exa Bytes

23


Virtual Memory

Wunsch des Programmierers

memory

0 h

∞ h

Sicht desProgrammierers

00000000 h

FFFFFFFF h

virtual

virtu

elle

Adre

ssen

physicalmemory

Betriebssystem

Prozess X

...

• Lösung Speichergrösse: Virtual Memory

- logischer resp. virtueller Adressraum in Pages aufgeteilt

- physikalischer Adressraum entsprechend in Frames aufgeteilt

- nur aktuell benötigte Pages im Hauptspeicher

- Rest der Pages als "image" auf dem Disk

• Konsequenzen

- Programmierer sieht logischen (virtuellen) Adressraum

� beschränkt durch Adressbreite und Diskkapazität

- auf dem Disk muss ein Image des Prozesses verwaltet werden

- mehr Prozesse können im Speicher abgelegt werden

- Prozesse können grösser als physikalischer Speicher sein

- alle Speicherreferenzen müssen logische Adressen sein

- effizient wenn

� Hardwareunterstützung für Adresseübersetzung

� Softwareunterstüzung für Ein- und Auslagern der Pages auf Sekundärspeicher

24


Virtual Memory

� Wie funktioniert VM ?

• Prozessor referenziert virtuelle Adresse

- referenzierte Page steht nicht im Speicher � Page Fault

- BS lädt Page, mit referenziertem Datum

� Wieso funktioniert VM ?

• Virtual Memory basiert auf Lokalitätstprinzip

� Welche Pages stehen im Speicher ?

• BS muss bei Page Fault intelligente Entscheidung treffen

• dauerndes Aus- und Einlagern von Pages führt zu Thrashing

• Wie funktioniert VM ?

- Prozessor referenziert virtuelle Adresse

� entsprechende Page steht im Speicher

• keine weiteren Aktivitäten notwendig

� entsprechende Page steht nicht im Speicher � Page Fault

• BS blockiert Prozess und lädt Block vom Disk

• dazwischen anderen Prozess ausführen

• Wieso funktioniert VM ?

- Virtual Memory basiert auf Lokalitätstprinzip

- räumliche und zeitliche Lokalität

� Speicherzugriffe liegen nahe beieinander

� gleiche Instruktionen werden mehrmals ausgeführt

• Nur wenige Pages stehen im Speicher: welche ?

- BS muss bei Page Fault intelligente Entscheidung treffen

� entsprechende Page laden

� bei zuwenig phys. Speicher zuerst eine Page auslagern

- falls ausgelagert Page gerade wieder gebraucht wird

� Page erneut laden

� führt zu Thrashing: Prozzessor ist hauptsächlich mit Swapping beschäftigt

- Lösung

� BS versucht zu raten, welche Pages als Nächste gebraucht werden

� mehr dazu später

25


Virtual Memory: Adressübersetzung

� Page Table aufwendiger

• benötigt zusätzliche Einträge

Page Number Offset

Frame Numberpmother control bits

p: presentm: modified

Virtuelle Adresse

Page Tabelleneintrag

usedprotection (Zugriff)

cachinglocking

• Virtual Memory: Page Tabellen

- Einträge in Page Tabelle aufwendiger: zusätzliche Bits notwendig

� m: modifiied Bit page wurde modifiziert

� p: present Bit page steht im Hauptspeicher

� zusätzliche Bits

• Zugriffsschutz - "read - write -execute"- z.B. Code = readonly, Stack: read/write, etc

• referenziert - auf page wurde zugegriffen

• caching - z.B. Page darf nicht "gecached" werden- lock in cache

• Adressübersetzung ähnlich wie bei einfachem Paging

26


Page Table Organisation

� Problem mit Page Tabellen

• Page Tabellen werden gross

• Beispiel adresses 32 Bit 64 Bitpage size 4 KByte 4 KBytepage table 220 Einträge 252 Einträge

� Mögliche Abhilfen

• Page Table im virtuellen Speicher

• Multilevel Organisation

- page directory: hierarchische Organisation

• Hashed Page Table

- Zugriff auf Tabelleneintrag über Hashwert

• Inverted Page Table

- pro Page Frame ein Eintrag

• Grundsätzliche Probleme

- Page Tabellen werden sehr gross

- ev. mehrere Speicherzugriffe notwendig � langsam

- Lösungen erfordern i.d.R. Hardwareunterstüzung

27


Multilevel Organisation

page directory

• • •

Pdirectory index Ptable index

virtual address

offset

• • •

physical memory

• Beispiel: 2 stufige Organisation

- mehrere Page Directories (Verzeichnisse) und mehrere Page Tabellen

- 1. Stufe wählt Verzeichnis

- 2. Stufe wählt Page Tabelle

- minimale Anzahl von Tabellen

� ein Page Directory und eine Page Tabelle

• Zahlenbeispiel für 32-Bit virtuelle Adresse

- Page directory index: 8 Bit 28 = 256

- Page Table Index: 12 Bit 212 = 4k

- Offset: 12 Bit 212 = 4k

- Zeiger in Page Table und Page Directory: 4 Bytes

- Gesucht

� wie viele Einträge kann das Page Directory haben ? (256)

� wie viele Page Tables können unterhalten werden ? (256)

� wie viele Einträge hat eine Page Tabelle ? (4K)

� wie viele Bytes enthält ein Page ? (4KB)

� wie gross kann der physikalische Speicher sein ? (4GB)

� wie viele Bytes werden minimal für die Tabellen benötigt ?= 256 * 4 Bytes + 1 * 4K * 4 Bytes = ~ 17 KByte

� wie viele Bytes werden maximal für die Tabellen benötigt ?

= 256 * 4 Bytes + 256 * 4K * 4 Bytes = ~ 4M

28


Hashed Page Table

� Page Nummer wird als Hash Wert verwendet

• geeignet für Invertierte Page Tabelle

• Adressräume > 32 Bit

• verschiedene Page Nummern � gleicher Hash Wert

hashfunction

page offset

frame offsethash table

virtual address

physicaladdress

• Page Nummer wird als Hash Wert verwendet

- verschiedene Page Nummern erzeugen den gleichen Hash Wert

- Hash Tabelle

� jeder Eintrag zeigt auf eine Liste mit den Einträgen

� jeder Listeneintrag enthält Page Nummer und entsprechende Frame Nummer

� bei Zugriff muss jeweils Page Nummer vergleichen werden (gleicher HashWert)

• Zusätzlicher Aufwand: Suchen in Hash Liste

• Geeignet für

- Invertierte Page Tabelle (Konzept siehe unten)

- bei grossen Adresseräumen (> 32 Bit)

29


Konzept: Invertierte Page Tabelle

PID pageNroffset

inverted page table

virtual address

frame Nr

PID pNr

offset

physical address

• • •

• • •

one entryper frame

• • •

physical memory

entry j = frame number

j

0

N

PID pNr

• Invertierte Page Tabelle

- pro Frame ein Eintrag

- Nummer des Eintrags (j) = Frame Nummer

- gleiche Page von verschiedenen Prozessen

� in verschiedenen Frames abgelegt

� Prozess ID muss in Tabelle gespeichert werden

- Problem

� ganze Tabelle muss nach Page Nummer und PID abgesucht werden

� ineffizient, wenn vollständig in Software

• Bei PowerPC, UltraSPARC, ITHANIUM

30


TLB: Translation Lookaside Buffer

� Problem

• jede Speicherreferenz benötigt bis zu zwei Speicherzugriffe

- Frame Nummer aus Page Tabelle

- Zugriff auf Daten

• bei Hash Tabellen zusätzliche Zugriffe

- gleicher Hash Wert für verschiedene Pages

• invertierte Page Tabellen

- zusätzlicher Zugriff auf Prozess ID

� Abhilfe

• spezieller Hardware Cache für Page Tabellen

• enthält kürzlich verwendete Page Tabellen Einträge

• pro Prozess aufgesetzt

• TLB (Translation Lookaside Buffer) genannt

31


TLB: Ablauf Zugriff

Page # Offset

Frame # Offset

PageLoad

Main Memory Secondary Memory

TranslationLookaside Buffer

TLB hit

Page Table

TLB miss

Page Fault

Associative Mapping

�

�

�

Bis zu 3 Schritte notwendig

1. Schritt: TLB absuchen

- Eintrag gefunden

� mit Framenummer physikalische Adresse bestimmen

� fertig

- Eintrag nicht gefunden � Schritt 2

2. Schritt: Page Tabelle adressieren

- Present Bit gesetzt

� Zugriff auf den entsprechenden Frame

� aufdatieren TLB

� fertig

- Present Bit nicht gesetzt � Schritt 3

3. Schritt: Page Fault

- Page mit Tabelleneintrag nicht im Speicher

- Page Fault und Kontrolle an BS (Software) um entsprechende Page zu laden

- aufdatieren TLB

- gehe zu Schritt 1

• TLB ist ein Cache

- Berechnung der Zugriffszeiten ähnlich wie bei Caches

32


TLB: Associatve Mapping

511

19

37

14

1

90

.

375

.

.

.

Page # PT Entry

5 502

37 502

Frame # Offset

Page # Offset

TLB

TLB Realisierung mitAssociative Mapping

• Associative Mapping

- Page Nummer wird am TLB angelegt

- Zelle mit entsprechendem Page Nummer Eintrag meldet sich selbst

- Hardwareunterstützung notwendig

� Hardwarevergleicher für jede Page Nummer

� schnell

• TLB gehört zur MMU

- arbeitet zusammen mit Cache System

33


Paging und Segmentation

� Kombination von Paging und Segmentation

• benötigt Page Table und Segment Table � aufwendig

� Aktuelle Betriebssysteme nur Paging

• Segmentation auf logischer Ebene, z.B. über Zugriffsrechte

- code: readonly

- stack: read/write (wünschenswert: no execute)

- data: read/write (wünschenswert: no execute)

� Paging und Segmentation

• Intel: MMU ab i486 unterstützt

• wurde nur von OS/2 (IBM) genutzt

• Für Details siehe Literatur, z.B. Stallings, Tannenbaum, etc.

34


Page Size

� Genaue Angaben schwierig

• z.T. widersprüchliche Anforderungen

• Trend � grosse Pages

IBM 370/XA, 370/ESA 4 KBytesIBM AS/400 512 BytesVAX 512 BytesDEC Alpha 8 KBytesMIPS 4 KBytes

PowerPC 4 KBytesUltraSPARC 8 KBytes bis 4 MBytesPentium 4 KBytes oder 4 MBytesITHANIUM 4 KBytes bis 256 MBytesAMD64 4 KBytes bis 64 KBytes

P: gesamte Prozessgrösse N: total benötigte FramesW: working set

P W Npage size page size

page

fault r

ate

page

fault r

ate

• Pagegrösse: durch Hardware bestimmt

• Möglichst kleine Pages

- wenig interne Fragmentierung

- viele Pages

• Viele Pages

- grosse Page Tabellen

- Page Tabellen im Virtual Memory � bis zu zwei Page Faults

� ein Fault um Teil der Page Tabelle zu laden

� ein Fault um Daten zu laden

- viele kleine Pages ergeben kleine Page Fault Rate

• Auch grosse Pages reduzieren die Page Faul Rate

- wenn Pages ~ so gross wie Prozess

• Anzahl zugewiesener Frames

- beeinflusst Page Fault Rate auch

- Zusammenspiel von Pagegrösse (Hardware) und Anzahl zugewiesener Frames(Software)

• Speichergrösse und Speicherbedarf von Applikationen haben ebenfalss Einfluss

• TLB

- wächst nicht so schnell wie Hauptspeicher

- interagiert zudem mit anderen Komponenten, wie Cache, etc.

- verschiedene Pagegrössen helfen TLB effizient zu nutzen, aber die meisten BS nutzen nur eine Grösse: die Page Grösse beeinflusst viele Komponenten im BS

• Hinweis zu AMD64 � 4KB bis 64KB (alle 2er Potenzen)

35


Memory Managment Software

� Alle wichtigen BS unterstützen heute VM

• Ausnahmen

- einige alte BS (z.B. DOS)

- Echzeitbetriebssysteme

- einige Embedded Systems

• VM benötigt Hard- und Softwareunterstützung

� Memory Managment Software

• mit VM steht nicht gesamter Prozess im Speicher

• 3 Fragestellungen

- wann eine neue Page laden � fetch policy ?

- wo die Page ablegen � placement policy ?

- welche Page ersetzen � replacement policy ?

... wieso nicht ?

• Fetch Policy

- demand paging

� Page wird geladen wenn Datum in Page referenziert wird

� erzeugt beim Starten eines Prozesses eine hohe Page Fault Rate, klingt aber ab, wenn genügende Pages geladen sind

- prepaging

� Page und zusätzliche Pages "in der Nähe" werden geladen

� unterstützt Verhalten von Sekundärspeicher (weniger Zugriffe, seek time)

� hat sich nicht etabliert: eher ineffizient

• Placement Policy

- bei Paging kein Thema

- symmetrisches Multiprozessing

� UMA (uniform memory access)

• Plazierung keine Bedeutung: Zugriffszeit immer gleich

� NUMA (non uniform memory access)

• Plazierung grosse Bedeutung, Zugriffszeit verschieden gross

• z.B. disitributed shared memory Architekturen

• Replacement Policy

- welche Pages im Hauptspeicher sollen ersetzt werden ?

36


Page Replacement

� 3 Fragestellungen

• welche Page ersetzen, wenn Speicher voll ist ?

• welche Pages bzw. Frames kommen für Ersatz in Frage ?

- Pages des verursachenden Prozesses ?

- alle Frames im Hauptspeicher ?

• wie viele Frames sollen einem Prozess zugewiesen werden?

� Wenn Speicher voll: welche Page ersetzen ?

• 4 Algorithmen

- optimal

- least recently used

- fifo

- clock

Bewertungskriterium:minimale Anzahl Page Faults

• Betrachten im Folgenden vier grundsätzliche Replacement Policies

- ähnliche Verfahren werden beim Caching eingesetzt

- basieren auf der Idee des Lokalitätsprinzips

� wenn eine Page häufig referenziert wird, wird sie auch in Zukunft mit hoher Wahrscheinlichkeit referenziert

- verschiedenste Modifikationen der Algorithmen existieren

� siehe Literatur

37


2

2

2 2 2 2 2 4 4 2 2 2

3 2 1 5 2 4 5 3 2 5 2

3 3 3

1

3

5 53

53

5

3

4

5

3

5

3

5

3

5

3

F F F

Replacement Policy: Optimal

� Ersetzt Page, die am spätesten referenziert wird

• nicht implementierbar

� Aber

• beweisbar, dass minimale Anzahl Page Faults

• gut für Vergleiche

� Beispiel mit 3 Frames

• Page Referenzen: 2 3 2 1 5 2 4 5 3 2 5 2

1

3

23 Frames

1

38


Replacement Policy: Least Recently Used

� Ersetzt die am längsten nicht referenziert Page

• Lokalitätstprinzip: wird wahrscheinlich nicht mehr referenziert

• fast so gut wie optimal

� Aber

• Implementation aufwendig

- Time Stamp oder Usage Counter notwendig

� Beispiel

2

2

2 2 2 2 2 2 2 3 3 3

3 2 1 5 2 4 5 3 2 5 2

3 3 3

1

5

1 15

45

4

5

3

4

5

2

5

2

5

2

5

F F FF

39


Replacement Policy: FIFO

� Pages Frames in zirkulärem Buffer angeordnet

• älteste Page wird ersetzt: Policy FIFO

• Problem: auch oft referenzierte Pages werden ausgelagert

� Aber

- Implementation sehr einfach

- schlechte Resultate

� Beispiel

2

2

2 2 2 5 5 5 5 3 3 3

3 2 1 5 2 4 5 3 2 5 2

3 3 3

1

3

1 12

42

4

2

3

4

5

4

2

4

5

2

5

F F FF FF

40


Replacement Policy: clock

page 19u = 1

page 1u = 1

page 45

u = 0

page 191

u = 0

page 727u = 1

page 13u = 0

page 67u = 1

page 33u = 1

page 222u = 0

. . .

. . .

. . .

0

1

2

3

4

56

7

8

n - 1

page 556u = 0

u = 1

u = 1

Für Page 727 einenFrame suchen

• Anordnung der Page Frames in zirkulärem Buffer

- jeder Frame besitzt ein Use Bit u

� wird beim Laden auf 1 gesetzt

• Zeiger wird auf nächsten Frame gesetzt

� wird beim Referenzieren auf 1 gesetzt

• Ersetzen einer Page

- ausgehend von Zeigerposition ersten Frame mit Use Bbit = 0 suchen und ersetzen

- angetroffene Frames mit u = 1 � u auf 0 setzen

- "schützt" häufig referenzierte Seiten vor Auslagerung

• Verhalten

- Kombination LRU/LFU

- ohne Use Bit: gleiches Verhalten wie FIFO

• Verwendung von Clock in modifizierter Form

- z.B. Multics und Unix SVR4 (two handed clock)

• Verbesserte Variante

- berücksichtigt auch modified

- Algorithmus: siehe Stallings, Abschnitt 8.2

41


Page Buffering

� Bis jetzt

• Frames durch neue Pages ersetzt

� Page Buffering: VAX

• Replacement Policy: FIFO

• nicht alle Frames stehen für den Gebrauch zur Verfügung

• BS unterhält zwei Listen: Free Page List und Modified Page List

modified page

free page list

modified page list

• Page Replacement mit Page Buffering

- ersetzte Page geht nicht sofort verloren

� nicht modifizierte Page wird an die Free Page List gehängt

� modifizierte Page wird an die modified Page List gehängt

- Page am Kopf der Free Page List wird ersetzt

- Modified Page List

� Pages werden in Clustern auf den Disk geschrieben

� kommen dann in die Free Page List

• Mach verwendet ein leicht modifiziertes Page Buffering System

- es wird aber nicht zwischen modifizierten und nicht modifizierten Pagesunterschieden

42


Vergleich der Verfahren

� Vergleich der 4 Verfahren

• fixed page allocation, local page replacement

• J. Baer (1980) und R. Finkel (1988)

- sozusagen identische Resultate für Verfahren mit verschiedenen Anordnungen (Daten)

gewünschter ArbeitsbereichFIFO

CLOCK

LRU

OPT

6 8 10 120

14

5

10

15

20

25

30

35

40

Page F

aults

/ 1000 R

efe

rence

s

Allocated Frames

• Der "Verbesserungsfaktor" nicht umwerfend ist

- erzielte Effekte aber messbar

- speziell bei grösserer Anzahl Frames ist eine Verbesserung bei LRU und OPTIMAL ersichtlich

• Anmerkungen

- die vorgestellten Verfahren basieren auf dem Lokalitätstprinzip

- moderne Technologien wie OO-Design und Multithreading reduzierenu.U. die Lokalität

43


Resident Set Managment

� Fragestellungen

• wie viele Frames einem Prozess zuweisen ?

• aus welcher Menge neue Frames wählen ?

� Resident Set Size / Replacement Scope

• Anzahl zugewiesener Frames / wo neuen Frame holen

local replacement

• fixe Anzahl Frames pro Prozess

• zu ersetzende Pages gehören dem aktuellen Prozess

• Anzahl zugewiesener Framesändert von Zeit zu Zeit

• zu ersetzende Pages gehört dem aktuellen Prozess

global replacement

• nicht möglich (per Definition)

• zu ersetzende Page wird unter allen zur Verfügung stehenden Frames ausgesucht

fixedallocation

variable allocation

• Virtual Memory

- nicht alle Pages eines Prozesses müssen / können im Hauptspeicher stehen

- bis jetzt beantwortet: welche Page aus einer vorgegebenen Menge ersetzen

- neue Fragestellungen

� was ist die vorgegebene Menge (replacement scope) ?

• local replacement nur zum Prozess gehörende Frames

• global replacement gesamthaft verfügbare Frames

� wie viele Frames einem Prozess zuweisen ?

• fixed allocation feste Anzahl Frames zuweisen

• variable allocation Anzhal Frames ändert mit Zeit

• Variable Allocation / Global Scope � Unix / Linux

- einfach zu implementieren

- oft globale Liste mit freien Frames � schnelle Anforderung neuer Frames

- Page Deamon: holt sich Frames von Prozessen, wenn keine freien Frames

- Problemstellung

� welche Frames können welchem Prozess weggenommen werden ?

� ev. ist Wahl des Prozesses nicht optimal

• Variable Allocation / Local Scope � Windows

- beim Start eine Menge von Frames aufgrund des Applikationstyps zugewiesen

- löst Problem mit Global Scope

- aber Grösse des Resident Set muss periodisch angepasst werden

44


Working Set

� Working Set: W(t, ∆T)

• referenzierte Frames während Zeitfensters ∆T

• W(t, ∆T) konstant für gewisser Zeit

� Beispiel: W(t, ∆T) für ∆T = 4

24 15 18 23 24 17 18 24 18 17 17 15 24 17 24 18

Page Referenzen

Working Set konstant

24 24 24 24 24 24 24 24 24 24 24 15 15 15 15 18

15 15 15 15 17 17 17 17 17 17 17 17 17 17 17

18 18 18 18 18 18 18 18 18 18 24 24 24 24

23 23 23 23

• Prozess startet

- Working Set des Prozesses wächst

• Lokalitätsprinzip

- der Working Set stabilisiert sich für eine gewisse

• Prozess tritt in neuen Lokalitätsbereich ein

- Working Set wächst bis Pages von zwei Lokalitätsbereichen

- stabilisiert sich anschliessende im neuen Stabilitätsbereich

• Resident Set

- die Anzahl aktuell zugewiesener Frames

• Working Set

- die in letzter Zeit benutzten Frames

45


Working Set Strategy

� Working Set Strategy

• aus Working Set � Resident Set bestimmen

� Vorgehen

• Bestimmen des Working Set

• periodisch Pages entfernen, die nicht mehr zum Working Set gehören

• Prozess nur ausführen, wenn sein Working Set im Speicher steht

� Problemstellungen

• aus Vergangenheit Zukunft nicht immer voraussagbar

• Bestimmen des Working Set unpraktisch

• optimaler Wert von ∆T ist unbekannt

� Lösung � Page Fault Frequency überwachen

46


Page Fault Frequency

� Resident Set aus Working Set

• bestimmen über Page Fault Rate

� Page Fault Frequency

Number of Frames

Page Fault Rate

W: sinnvolle Page Fault Rate N: Prozess vollständig im Speicher

NW

PFok

• Beobachtung

- die Page Fault Rate nimmt mit zunehmendem Working Set bzw. Resident Set (Anzahl Frames pro Prozess ab)

• Folgerung

- die Grösse des Working Set kann über die Page Fault Rate bestimmt werden

• Realisierung

- Messung der Anzahl Page Faults während Zeitintervall

- Zeitintervall berechnet aus konsumierter CPU-Zeit eines Prozesses

� wird auch virtuelle CPU-Zeit genannt

• Implementation Page Fault Frequency (PFF)

- verwenden des Use Bit

- definieren einer Schranke TF für Zeitintervall

- Page Fault

� wenn Zeitintervall seit letztem Page Fault < TF

• Page zum Working Set hinzufügen

• Anmerkung

• kurze Zeit � hohe Page Fault Rate � mehr Frames notwendig

� wenn Zeitintervall seit letztem Page Faul > TF

• alle Pages mit used bit = 0 aus Working Set entfernen

- Problem

� schlechtes Verhalten während transienter Phase

• sehr viele Pages werden in den Working Set aufgenommen

47


Load Control

� Anzahl Prozesse im Speicher

• zu wenig Prozesse

- schlechte CPU Auslastung wegen I/O

• zu viele Prozesse

- Working Set zu klein � thrashing

Anzahl Prozesseim Speicher

100%

Prozessor Auslastung

thrashigI/O bound

optimal

• Zu wenige Prozesse im Speicher

- Working Set genügend gross

- Prozesse warten auf I/O

• Zu viele Prozess im Speicher

- Working Set wird zu klein � thrashing und CPU Auslastung sinkt drastisch

• Load Control

- eine Working Set Strategie impliziert Load Control

� Prozess läuft nur, wenn minimaler Working Set im Speicher verfügbar

� durch Anpassen des notwendigen Working Sets, wird die Anzahl Prozesse im Speicher automatisch angepasst

- oder z.B. modifizierter Clock Algorithmus

� Beobachtung des Zeigers

• Multiprogramming Level kann erhöht werden, wenn

• wenig Anfragen, den Zeiger vorwärts zu bewegen

• und wenn nur kleine Vorwärtsbewegung notwendig sind

• in beiden Fällen sind viele, nicht referenzierte Pages verfügbar

48


Load Control: process suspension

� Welche Prozesse sollen suspendiert werden, wenn zu viele Prozess im Speicher ?

� Sechs Möglichkeiten

• Prozess mit tiefster Priorität

• Prozess mit (vielen) Page Faults

• der am längsten nicht aktivierte Prozess

• Prozess mit kleinstem Resident Set

• grösster Prozess

• Prozess mit dem längsten Verarbeitungsfenster

• Prozess mit tiefster Priorität

- implementiert eine Scheduling Policy Entscheidung (hat nichts mit Performance zu tun)

• Prozess mit (vielen) Page Faults

- grosse Wahrscheinlichkeit, dass

� Working Set nicht resident ist

� Prozess blockiert wegen Page Fault

• Der am längsten nicht aktivierte Prozess

- hat mit grosser Wahrscheinlichkeit den Working Set nicht vollständig im Speicher

• Prozess mit kleinstem Resident Set

- erfordert am wenigsten Aufwand, den Prozesse aus- und wieder einzulagern

• Grösster Prozess

- gibt am meisten Frames frei

- mit grosser Wahrscheinlichkeit muss kein zusätzlicher Prozess ausgelagert werden

• Prozess mit dem längsten Verarbeitungsfenster

- implementiert etwas, wie ein "SJP" Scheduling Policy

49


Implementationsaspekte

� I/O Page locking

• Prozess wartet auf Eingabedaten (System Call)

- Page mit I/O-Buffer kann aus System ausgelagert werden

� z.B. wegen Replacement Strategie mit global scope

- oder Prozess wird "swapped"

• Lösungen

- Pages mit I/O Buffer in Speicher "locken"

- I/O Buffer im Kernel verwalten und Daten später in den User Space kopieren

� Shared Memory

• ähnliche Probleme wie mit I/O Pages

• aber: mehrere Prozesse sind involviert

50



� Instruktionen

• Instruktion, die Page Fault erzeugt, muss wiederholt werden

- Problem bei variabel langen Instruktionen

� Betriebssystem muss wissen, wo Instruktion beginnt

• ev. müssen zusätzlich Autoinkrement und -Dekrement rückgängig gemacht werden

• falls keine Hardwareunterstützung

- zusätzlicher Overhead bei Page Replacement

� Paging Deamon

• Page Replacement kann effizient durch Hintergrundprozess (Deamon) ausgeführt werden

• z.B. periodisch oder während Lastpausen

51



� Betriebssystemaufgaben mit Paging

• Prozesserzeugung

- aufsetzen und initialisieren der Page Table und Swap Area

• Prozessausführung resp. Prozessaktivierung

- MMU rücksetzen und Inhalt des TLB entfernen

- entsprechende Page Table aktivieren

• Page Fault

- bestimmen welche Page geladen werden muss

- Neustart der Instruktion

• Prozessterminierung

- Page Table und Swap Area entfernen

- Shared Pages beibehalten (Eintrag für Prozess entfernen)

52


Zusammenfassung

� Memory Management Algorithmen

• einfache Single-User Systeme bis Paged Segmentation

• verschiedenste Einflussfaktoren sind zu berücksichtigen

• grosser Einfluss auf Wahl eines Verfahrens durch Hardware

- Pagegrösse

- Organisation der Page Tabellen

- Adressraum (32 vs. 64 Bit)

- Schutzmechanismen

� Virtual Memory

• von den meisten modernen Betriebssystemen unterstützt

• meist nur logische Segmentierung (auch wenn HW vorhanden)

• Real-Time und Embedded Systems

- kein resp. oft kein VM weil nicht deterministisches Verhalten

• Memory Management Verfahren (für Details siehe Literatur Stallings, Tannebaum)

- UNIX

� global scope, modifiziertes Clock Verfahren (2 Zeiger)

- LINUX

� global scope, modifiziertes Clock Verfahren (use bit = used byte)

- Windows

� local scope

� für jeden Prozess ein Minimum und ein Maximum an Frames definiert

• wenn weniger als Minimum: Frame zugewiesen

• wenn mehr als Maximum: Frame weggenommen

• wenn Prozess hohe Page Fault Rate wird Maximum erhöht

- UNIX / LINX / Windows

� unterhalten einen globalen Pool von freien Frames

� Page Deamon sucht bei knappem Speicher nach Pages, die nicht oder nur wenig benutzt werden

• Anmerkung zu Paging

- Wahl eines Verfahrens reicht nicht

- zu berücksichtigen sind weiter

� Bestimmen des Working Set

� Memory Allocation Policy

� Page Size (Einfluss der Hardware)

Memory Management, Virtual Memory -...

Documents

Transcript of Memory Management, Virtual Memory -...