Speicherverwaltung III

Transkript

1 Speicherverwaltung III Andreas Görzen Marius Schultchen Benjamin Kotke Sascha Sternheim 26. Februar 2013 Inhaltsverzeichnis 1 Datenstruktur zur physikalischen Speicherverwaltung Übersicht möglicher Datenstrukturen Bitmap Verkettete Liste Stack Tabelle physical memory management table(pmmtable) Aufteilung des Adressraums Lower Half Kernel Higher Half Kernel Umsetzung Paging Rekursives Paging Directory Aufbau Abläufe Initialisierung des Pagings Ablauf des Mappings neuer Pages Erzeugung und Zerstörung eines Pagingkontextes

2 1 Datenstruktur zur physikalischen Speicherverwaltung Durch die physikalische Speicherverwaltung wird das Allozieren und Freigeben von physikalischem Speicher ermöglicht. Dabei speichert eine Datenstruktur in der physikalische Speicherverwaltung welche Speicherbereiche im physikalischen Speicher frei sind. Die verwalteten Speicherbereiche haben eine Seitengröße von 4kb. 1.1 Übersicht möglicher Datenstrukturen Um eine Datenstrukturen zur physikalischer Speicherverwaltung zu implementieren, gibt es verschiedene Möglichkeiten. Im Folgendem sollen einige kurz vorgestellt werden Bitmap Eine einfache Verwaltung der physikalischen Adressen lässt sich mit einer Bitmap realisieren. Dazu wird 1-Bit an Information für jede Seite gespeichert. Dieses Bit gibt an, ob die Seite belegt oder frei ist. Der Vorteil an der Bitmap ist, dass der von der Bitmap selbst verwendete Speicher zur Laufzeit konstant ist. Dadurch kann es nicht zu einer Endlosschleife kommen, falls der Speicherstruktur selbst der Platz für weitere Informationen ausgeht und sie weiteren von sich selbst anfordern will. Ferner ist es möglich einen kontinuierlichen Speicherbereich zur Verfügung zu stellen. Ein Nachteil der Bitmap ist, dass sie keine zusätzlichen Informationen aufnimmt. Dadurch ist es schwer möglich gemeinsam genutzten Speicher zu realisieren, da nicht verwaltet werden kann, wie viele lineare Adressen auf diesen Speicher verweisen Verkettete Liste Ferner können die Seiten durch eine verkettete Liste verwaltet werden. Dabei verwaltet ein Listenelement den Anfang von freiem Speicher und die Länge des fortlaufenden freien Speichers. 2

3 Beim Anfordern von Speicher müssen diese Elemente entfernt, bzw. verkleinert werden. Beim Freigeben von Speicher werden sie vergrößert oder gegebenenfalls neu angelegt. Ein Nachteil der Struktur ist, dass man für sie dynamisch Speicherplatz allozieren muss und es so zu Problemen mit Endlosschleifen kommen kann Stack Eine weitere Datenstruktur ist der Stack. In ihm werden alle freien Seiten verwaltet. Wird eine Seite angefordert wird sie vom Stack genommen. Beim Freigeben einer Seite wird sie wieder auf den Stack gelegt. Ein Vorteil des Stacks ist, das die Anforderung einer freien Seite in konstanter Zeit geschehen kann. Ein Nachteil ist, dass sich die Struktur dynamisch verändert und nicht immer konstant ist. Dadurch muss sich damit beschäftigt werden, dass die Struktur entsprechend wachsen kann und der Speicher nicht ausgeht. Ebenso wie bei den bisherigen Datenstrukturen können in einem Stack keine Zusatzinformationen verwaltet werden Tabelle Eine weitere Möglichkeit ist die Verwaltung in einer Tabelle. In ihr können alle physikalischen Speicherblöcke mit Zusatzinformationen verwaltet werden. Dies ist z.b. dafür nötig, um zukünftig mehrere Prozesse verwalten zu können. Durch die Zusatzinformationen, können z.b. Speicherblöcke als gemeinsam genutzer Speicher markiert werden. Ferner könnten die Anzahl der Prozesse, die auf den Block zugreifen mitgezählt werden, wodurch gemeinsam genutzer Speicher wieder frei gegeben werden kann. Ansonsten verhält sich eine Tabelle wie eine Bitmap, wobei natürlich, je nach dem Umfang an Zusatzinformationen, die Größe der festen Datenstruktur ansteigt. 1.2 physical memory management table(pmmtable) Um die Implementierung zu erleichtern und nicht mit den Problemen einer dynamisch wachsenden Struktur umgehen zu müssen, wird die Tabelle in Form eines Arrays mit einer festgelegten Größe erzeugt. 3

4 Dabei wird die Größe abhängig von dem zur Verfügung stehenden physikalischen Speicher gewählt. Um die Information über die Speichergröße zu erhalten, werden die Informationen aus einer Boot-Struktur, den E820-Entries, entnommen, die beim Start dem Kernel übergeben werden. Außer den eigentlichen Einträgen der Speicherblöcke, werden Zusatzinformationen wie Speichergröße, Kernelgröße und Blockanzahl erfasst, da sie noch für andere Verwaltungseinheiten benötigt werden. So müssen für die PmmTable an sich lineare Adressen auf den physikalischen Speicher abgebildet werden, da sie selbst ihre Einträge im Speicher ablegen muss. Dazu muss die Größe des Speichers bekannt sein, um die Größe der PmmTable zubestimmen. Die Einträge an sich, die PmmTableEntries, repräsentieren jeweils einen 4kb Speicherblock im physikalischen Speicher und reichern ihn mit Zusatzinformationen an. So kann die Anzahl der linearen Adressen, die auf ihn zeigen, mitgezählt werden. Dadurch lässt sich gemeinsamer Speicher realisieren, der auch wieder freigegeben werden kann. Ferner lassen sich durch weitere Bits Zusatzinformationen anlegen, die sich in der weiteren Entwicklung 1 nützlich erweisen können. In der Tabelle 1 ist die Bitbelegung der Einträge beschrieben. Auf Basis dieser Bitbelegung lassen sich viele verschiede sinnvolle Kombinationationen bilden, um die Blöcke im physikalischen Speicher zu charakterisieren. Einen Überblick dazu gibt Tabelle 2. Bit Beglegung Bedeutung 0 0 Der physikalische Speicherblock ist laut der Boot-Struktur nicht verfügbar. 1 1 Der physikalische Speicherblock ist für den Kernel. 2 1 Der physikalische Speicherblock kann gemeinsam genutzt werden. 3 1 Der physikalische Speicherblock ist frei. Abbildung 1: Bitbelegung der Tabelle zur physikalischen Speicherverwaltung Ferner gibt das Klassendiagramm in Abbildung 3 einen genauen Blick in den Aufbau der Datenstruktur. Die Operationen, die in der Abbildung zu sehen sind, dienen dazu die PmmTable zu initialisieren, Bereiche im physikalischen Speicher als verfügbar oder nicht verfügbar zu deklarieren, sowie Bereiche für den Kernel festzulegen. Ferner werden die wichtigsten Operationen allocblock und freeblock spezifiziert, mit denen Speicher angefordert und freigegeben werden kann. Bei der Implementierung dieser beiden Operationen, veranschaulicht in den Aktivitätsdiagrammen 4 1 Zugriffsmethoden für die Zusatzinformationen wurden noch nicht entwickelt. Es wird sich im weiteren Verlauf des Projektes zeigen, welche Flags für das Multitasking nützlich sind. 4

5 Bit 3 Bit 2 Bit 1 Bit 0 Bedeutung nicht verfügbarer Speicher laut E820-Entries belegter Benutzerspeicher belegter Kernelspeicher belegter teilbarer Benutzerspeicher belegter teilbarer Kernelspeicher freier Benutzerspeicher freier Kernelspeicher freier teilbarer Benutzerspeicher freier teilbarer Kernelspeicher Abbildung 2: sinnvolle Kombinationen der Bitbelegung Abbildung 3: PmmTable und 5, wird die Variable _free_start_search verwendet, um das Suchen nach freien Speicherblöcken zu beschleunigen. Dazu wird ein Pointer auf den untersten freien Speicherblock gesetzt. Wird dieser besetzt, zeigt der Pointer auf den nächsten Eintrag. Dadurch wird das fortlaufende Suchen beschleunigt. Wenn untere physikalische Speicherblöcke wieder frei werden, wird der Zeiger auf diese gesetzt. Dadurch sinkt die Performanze, da nachfolgende Anfragen die Tabelle von dem Pointer aus weiter durchsuchen müssen. Allerdings wird durch das Umsetzen des Pointers vermieden, dass Lücken im physikalischen Speicher entstehen, wodurch dann wieder in konstanter Zeit auf freien Speicher zugegriffen werden kann, wenn die Lücken gefüllt sind. Ist kein freier Speicher verfügbar, wird die als Error definierte Adresse 0x zurückgegeben. 5

6 Abbildung 5: Speicher freigeben Abbildung 4: Speicher allokieren 2 Aufteilung des Adressraums Neben der Verwaltung des freien und belegten physikalischen Speichers wurde überlegt, wie die Kommunikation zwischen Prozessen und Kernel stattfinden kann. Dabei wurde auch berücksichtigt, dass ein Kontextwechsel 2 sehr viel CPU Zeit benötigt und wie ein unnötiger Wechsel nur für den Scheduler vermieden werden kann. Ein Kontextwechsel findet statt, wenn das CR3 Register (das Register das die Adresse des Page Directorys enthält) mit einer neuen Adresse belegt wird. Üblicherweise wird der 4GB große lineare Adressraum, der mit 32-Bit adressiert werden kann, in zwei Teile aufgeteilt: Kernel- und User-Space. Am häufigsten ist die Aufteilung mit 1GB für den Kernel-Space und 3GB für den User-Space. Dabei ergibt sich, dass Prozesse nur maximal 3G Speicher exklusiv 2 Unterbrechung des aktuellen Prozesses inklusive Speicherung des Kontext und Wechsel zu einer anderen Routine 6

7 für sich adressieren können. 3 Für die Aufteilung diese Bereiche haben sich folgenden zwei Vorgehensweisen etabliert: 2.1 Lower Half Kernel Abbildung 6: Lower Half Kernel 0 1 GB sind für den Kernel vorgesehen und 1 4 GB folglich für den Userspace. Durch die Zuweisung des Adressraums 0x x3F F F F F F F für den Kernel kann dieser 1 zu 1 gemappt werden. Dies ermöglicht eine einfachere Implementierung, kann allerdings auch zu Problemen führen. So müssen Anwendungsprogramme so kompiliert werden, dass sie erst bei einer 1 GB Startadresse beginnen. 2.2 Higher Half Kernel Abbildung 7: Higher Half Kernel Der Higher Half Kernel zeichnet sich beim 32-Bit System dadurch aus, dass der Kernel Space nun im Bereich 0xC xF F F F F F F F liegt. Bis zu Initialisierung des Pagings muss der Kernel in diesem Fall zunächst mit physikalischen und später mit virtuellen Adressen arbeiten. Diese zunächst als unnötig aufwendig erscheinende Vorgehensweise bringt allerdings diverse Vorteile mit sich. 3 In der Regel weniger, denn auch bei 4GB physikalischen Speicher müssen diverse Geräte auf diesen gemappt werden. Dieser Speicher kann also nicht angesprochen werden, obwohl er physikalisch vorhanden ist. 7

8 Bei einem 64-Bit System mit einem Higher Half Kernel (Kernel Space also oberhalb von 0xF F F F F F F F ) ermöglicht diese Aufteilung weiterhin, dass 32-Bit Anwendungen den gesamten 32-Bit Adressraum nutzen können, was bei einem Lower Half Kernel nicht möglich wäre. 2.3 Umsetzung Bei der Umsetzung wird nur der Higher Half Kernel betrachtet. Jeder Prozess erhält ein eigenes Page Directory im physikalischen Adressraum. Die letzten PDE Einträge (768 bis 1023) im Page Directory verweisen dabei auf den Kernel-Space und sind bei allen Prozessen gleich. Diese Einträge sollten dann durch die im Prozessor vorhanden Schutzmechanismen geschützt werden. Die restlichen PDEs adressieren den User-Space-Bereich. So können die selben PDE Einträge für jeden Prozess für die Adressierung des Kernel-Spaces verwendet werden. Wenn man so vorgeht, benötigt der Kernel kein eigenes Page Directory, er wird stattdessen als Teil jedes Prozesses angesehen und nicht als ein eigenständiger Prozess. Außerdem kann man die PDEs und die dazugehörigen PTEs mehrfach verwenden, spart also Speicher ein. Ohne die Aufteilung in Kernel- und User-Space würde man pro Prozess die gleichen PDEs erstellen müssen. Bei einem Prozesswechsel muss das CR3 nur auf das Page Directory für den neuen Prozess gesetzt werden. Für den Scheduler muss also kein extra Kontextwechsel stattfinden. Zusätzlich ergibt sich, dass die IDT, bestimmte Funktionen und Einsprungadressen für Kernelfunktionen, wie z.b. das Anfordern von Speicher oder Auswahl des nächsten Prozesses, an der gleichen linearen Adresse für jeden Prozess liegen. Die PDEs für den Kernel-Space müssen erstellt werden, damit diese in jedem Page Directory der Prozesse verwendet werden können. Denn ansonsten müssten die Page Directorys aller Prozesse aktualisiert werden, wenn für den Kernel Speicher adressiert wird. Für die PTEs gibt es zwei Möglichkeiten: 1. Man merkt sich welche PDE zuletzt verwendet worden ist und legt die PTEs dann bei Bedarf an, wenn mehr Speicher nötig ist. 2. Man legt auch alle PTEs für die PDEs von vornherein an. Das kostet allerdings mehr physikalischen Speicher. 1MB für alle PDEs und dazugehörigen PTEs. Die folgende Abbildung verdeutlicht wie der lineare Adressraum (User- und 8

9 Kernel-Space) von zwei Prozessen im physikalischen Speicher vorliegen kann: Abbildung 8: User- und Kernel-Space im physikalischen Speicher Nach der Aufteilung in Kernel- und User-Space können Prozesse nun nur noch den Speicher im linearem Adressraum exklusiv für sich reservieren, der unterhalb 3GB liegt, also bis Adresse 0xC h. Das Anfordern von Speicher oberhalb dieser Adresse muss zu einem Fehler führen. Im Zuge der Gestaltung des linearen Adressraums wurde der Videospeicher auf die Adresse 0xFFBF.F000 bis 0xFFBF.FFFF gelegt. Dies wurde nötig um das volle Higher Half Kernel Konzept umzusetzen. 3 Paging Das Paging setzt die linearen Adressen auf physikalische Adressen um. Somit ist der Zugriff auf den Speicher nur noch indirekt über das Paging beziehungsweise über lineare Adressen möglich. Das bedeutet auch, dass zur Verwaltung der Paging Directory und der Page Tables ein vorhandenes Mapping auf die beiden Pagingstrukturen existieren muss, da keine direkte Verwaltung über physische Adressen mehr möglich ist. Da aber die physikalischen Adressen unterschiedlich zu den linearen Adressen sein können, ist es nötig dieses Problem bei der Implementierung der Pagingverwaltung zu beachten. Zur Lösung dieses Problem wurden zwei Herangehensweisen betrachtet die im folgenden kurz erläutert werden: 1. Bei der ersten Herangehensweise wird ein Teil des physikalischen Adressraums 1:1 auf den linearen Adressraum gemappt oder bzw. mit einem bekannten Offset. 9

10 2. Die zweite Herangehensweise ist das Page Directory rekursiv zu Mappen. Das bedeutet, dass ein Eintrag im Page Directory auf die physikalische Adresse des Page Directory verweist. Somit kann dann über einen bestimmten Bereich im linearen Adressraum auf die Pagingstrukturen zugegriffen werden. Von den beiden zur Auswahl stehenden Herangehensweisen wurde die Zweite ausgewählt. Zwar ist die erste Herangehensweise vom Verständnis des Algorithmus einfacher zu verstehen und zu implementieren, die Herangehensweise hat aber den Nachteil, dass schon im Vorfeld sehr viel Speicher für die Pagingstrukturen reserviert werden muss, obwohl der Speicher noch nicht benötigt wird. Ein weiterer Vorteil der ersten Herangehensweise ist es, dass mehrere Pagingstrukturen gleichzeitig verwaltet werden können. Da aber meißtens verwaltende Tätigkeiten nur auf der aktiven Pagingstruktur durchgeführt werden, wie zum Beispiel das Mappen einer Page, ist dieser Punkt eher zu vernachlässigen. Ein weiterer Punkt gegen die erste Herangehensweise, ist die Anforderung, dass es jeweils eine andere Pagingstrukturen für einen Prozesse geben soll. Denn bei falscher Dimensionierung des 1:1 gemappten Bereiches kann es passieren, dass in diesem Bereich schnell kein Speicher mehr zur Verfügung steht oder falls immer nur die aktuelle Pagingstruktur in diesem Bereich vorgehalten werden soll die neue Pagingstruktur in den 1:1 gemappten Bereich kopiert werden muss. 3.1 Rekursives Paging Directory Beim rekursiven Paging Directory wird ein Eintrag auf die physikalische Anfangsadresse des Paging Directories gesetzt. In der Implementierung des FHDW-OS wurde der letzte der Eintrag des Paging Directories dazu verwendet. Dies hat zur Folge, dass wenn auf eine lineare Adresse im Bereich von 0xF F C00000 bis einschließlich 0xF F F F F F F F zugegriffen wird der letzte Eintrag im Paging Directory genutzt wird. Da dieser wieder auf das Page Directory verweist, wird nun das Page Directory nochmals genutzt, aber diesmal in der Rolle einer Page Table. Die Page Table über nimmt dann die Rolle der Page auf die zugegriffen wird. In Abbildung 9 ist Beispielhaft der Ablauf für den Zugriff auf die Adresse 0xF F C dargestellt, mit der man den Zugriff auf den dritten Eintrag in der zweiten Page Table erhält. Somit ist es möglich im linearen Adressraum von 0xF F C00000 bis 0xF F F F F F F F auf die Pagingstrukturen zuzugreifen. In Abbildung 10 ist exemplarisch dargestellt mithilfe welcher linearen Adressen, durch die Benutzung des rekursiven Paging Directory Ansatzes, ein Zugriff auf die Pagingstrukturen möglich ist. 10

11 Abbildung 9: Rekursiver Verweis im Paging Directory Abbildung 10: Lineare Adressen zum Zugriff auf die Pagingstrukturen 3.2 Aufbau Die zur Verwaltung der Pagingstruktur erstellte Klassen-Struktur ist in zwei Bereiche eingeteilt. Der erste Bereich enthält die Schnittstellen um verwaltende Aufgaben im Paging auszuführen. Dazu zählen hauptsächlich die Funktionen zum Mappen oder Freigeben von Seiten, der Wechsel des aktuell genutzten Page Directories 4, sowie Erzeugung und Zerstörung eines Pagingkontextes. Diese Aufgaben werden durch die Klasse PageContext bereitgestellt. Weiterhin repräsentiert ein Objekt dieser Klasse einen spezifischen Pagingkontext und stellt Operationen zur Verfügung, die die einmalige Initialisierung des Pagings durchführt. Aufgrund der Benutzung des rekursiven Paging Directories Ansatzes ist die Benutzung von Operationen die ein spezifischen Pagingkontext ändern, wie zum Beispiel das Mappen nur möglich, wenn 4 Im weiteren Verlauf als Pagingkontext bezeichnet 11

12 der zu ändernde Pagingkontext aktiv ist 5. In Abbildung 11 ist die Klasse PageContext dargestellt. Abbildung 11: Klasse PageContext Im zweiten Bereich sind mehrere Klassen die zur intern Verwaltung der Pagingstrukturen benutzt werden. Ein Zugriff auf diese Klassen ist von außerhalb nicht vorgesehen. Eine Übersicht über die Klassen dieses Bereiche ist in Abbildung 12 abgebildet. PageEntry ist entweder ein Eintrag in der PageTable oder im Page Directory. Die Klasse bietet Operationen zum Ändern der Flags oder zum Setzen der physikalischen Adresse an. Die Klassen PageDirectoryEntry und PageTableEntry, die von der Klasse PageEntry ableiten, enthalten spezielle Implementierungen für den Ablauf des Mappings. PageTable repräsentiert eine Page Table und bietet Operationen um einen Eintrag für einen bestimmte lineare Adresse auszuwählen. PageDirectory spiegelt ein Page Directory wieder. Die Klasse bietet Operationen wie die Klasse PageTable an, um einen Eintrag auszuwählen. Des weiteren gibt es Operationen um Mappings zu erstellen oder aufzuheben, zum Setzen des rekursiven Eintrages und Operationen die zum Erstellen eines neuen Page Directories benötigt werden. 3.3 Abläufe In diesem Abschnitt sind die wichtigsten Abläufe des Paging sowie deren Besonderheiten beschrieben Initialisierung des Pagings Die Initialisierung des Paging findet vor der Initialisierung der physikalischen Speicherverwaltung statt. Dabei wird zunächst der Eintrag fürs rekursive Paging gesetzt. Darauf werden die Page Tables für den Kernel Space erstellt auf die 5 isenabled() == true 12

13 Abbildung 12: Klassenstruktur des internen Bereiches dann von jedem Page Directory verwiesen wird. Außerdem werden dabei gleichzeitig die minimalen Mappings für den Kernel Space angelegt. Dazu zählen zum Beispiel die Mappings für den Kernel, für die physikalische Speicherverwaltung als auch den Bereich für den Videospeicher. In diesem Zustand ist das Paging funktionsfähig, aber es existieren noch Mappings die durch den Bootloader erzeugt wurden. Diese werden nach der grundlegende Initialisierung des Kernels entfernt Ablauf des Mappings neuer Pages Da das Mappen neuer Pages die Hauptfunktion der Pagingverwaltung ist, ist in Abbildung 13 dargestellt wie das Mappen bzw. Reservieren einer bestimmten linearen Adresse abläuft. Das Freigeben von Pages läuft analog dazu Rückwarts ab, nur mit dem Unterschied, dass eine Page Table die keine aktiven Einträge mehr enthält nicht freigegeben wird. Die Überprüfung ob die angeforderte lineare Adresse nicht in einem gesperrten Bereich liegt ist dafür zuständig, dass nicht zum Beispiel im linearen Bereich des rekursiven Paging Directories eine Page reserviert wird oder das der Kernel Code freigegeben wird. 13

14 Abbildung 13: Ablauf des Mappings Erzeugung und Zerstörung eines Pagingkontextes Um einen neuen Pagingkontext zu erzeugen wird sich zunächst eine physikalische Seite reserviert. Darauf wird die physikalische Seite temporär auf eine beliebige nicht vergebene lineare Adresse gemappt. An dieser temporären Stelle wird nun ein Page Directory mit seinen Grundstrukturen, den Page Tables für den Kernel Space und dem Eintrag für das rekursive Page Directory, erstellt. Nach diesem Vorgang wird Abschließend noch das temporäre Mapping aufgehoben und das CR3 Register auf die physikalische Adresse des neuen Page Direcotries gesetzt. Die Zerstörung eines Pagingkontextes ist nur möglich falls dieser aktiv ist. Dafür ist es nötig den Pagingkontext anzugeben, der nach der Zerstörung des aktuellen Pagingkontext aktiviert werden soll. Bevor zum nachfolgende Pagingkontext gewechselt wird, werden zunächst alle reservierten Seiten für den User Spaces freigegeben und auch die Seiten die von der Pagingstruktur selbst belegt wurden. 14