Thema: Ebenen der Speicherverwaltung

[TheThing]

So, ich arbeite ja mometan wieder an meinem Microkernel, der ja diesmal etwas mehr können soll als nur einen test-task auszuführen
Momentan hängt es noch ein wenig bei der Speicherverwaltung. So wie ich das sehe kann man die ja eigentlich in drei Ebenen unterteilen:
1. PMM: Er kümmert sich einfach nur um das zuteilen und freigeben von 4KB-Blöcken. Das setze ich momentan mit einer Bitmap um.
2. Paging: Kümmert sich im Prinzip nur um das Mapping. Bei mir bekommen sämtliche paging-Funktionen die Adresse des page-directories übergeben. Falls da irgendwo Platz gebraucht wird, wird mit Hilfe des PMM Speicher geholt. Außerdem besitzt mein Code eine Funktion um virtuelle in physikalische Adressen umzurechnen und mappt den Kernel in jeden Adressraum.
3. VMM: Ja, gute Frage. Keine Ahnung. Rein theoretisch könnte man ja einfach auf PMM und paging zurückgreifen: Man holt per PMM einen 4KB-Block, mappt ihn an eine freie Stelle in den Adressraum und gibt dann die Stelle im Adressraum zurück. Wäre vermutlich am einfachsten umzusetzen, aber ehrlich gesagt halte ich es für schlecht, wenn ich für jede Task-Struktur einfach mal 4KB verschwende.

Wie siehts also aus? Sollte ich mir einen vernünftigen VMM basteln? Welche Methode würdet ihr da empfehlen bzw. verwendet ihr?

[Svenska]

Hallo,

ich stelle mir da ungefähr Folgendes vor:

(a) PMM: Verantwortlich für den physischen Adressraum (d.h. physisch verfügbarer RAM, MMIO und so weiter); hat eine Auflösung von 4 KB (*).
(b) VMM: Verantwortlich für den virtuellen Adressraum von Tasks, also das Mapping von RAM und MMIO-Adressen in die entsprechenden Tasks, das Ein- und Auslagern von Pages auf Sekundärspeicher (unter Zuhilfenahme der Treiber) und so Zeugs; hat eine Auflösung von 4 KB (*).
(c) Malloc: Verantwortlich für den Heap und die Aufteilung von Pages in mehrere kleinere Einheiten; liegt in der libc (bzw. System-Runtime) und hat eine beliebig kleine Auflösung, nutzt den VMM.

(*) Optimal wäre statt 4 KB die Pagegröße, die je nach Nutzung und Größe des Blocks auch größer sein kann (Hugepages, z.B. 2 MB oder so).

Wenn ich auf dem Holzweg bin, bitte melden.

Im Kernel brauchst du nicht unbedingt ein malloc/kalloc (je nach Design). Ansonsten kannst du dort eine eigene Implementation bereitstellen; die Treiber nutzen trotzdem die Userspace-Implementation in der libc.

Gruß,
Svenska

[erik.vikinger]

Hallo,


ich gehe mal davon aus das hier die Speicherverwaltung für den Kernel selber gemeint ist, falls das nicht stimmt ist alles nachfolgende purer Unsinn.


Der PMM ist soweit schon ganz gut beschrieben, nur eines fehlt da aus meiner Sicht noch. Woher bekommt der PMM die Verwaltungsstrukturen die er selber benötigt um zu arbeiten? Mit einer Bit-Map die den gesamten physischen RAM umfasst könnte man natürlich sagen das der PMM ansonsten nichts weiter benötigt aber dann kann er auch nichts weiter tun außer physische Pages zu Allozieren und wieder frei zu geben (was grundsätzlich ja auch ausreicht und selbst wenn man mehrere zusammenhängende/ausgerichtete Pages haben will ist das damit kein Problem solange auch beim freigeben immer mitgeteilt wird was da freigegeben wird).

Der VMM ist wohl auch recht klar aber dieser wird definitiv dynamisch Speicher zur Verwaltung benötigen. Dafür wäre es natürlich toll wenn der dazu den Kernel-Heap benutzen könnte was aber bedeutet das da eine Kreisabhängigkeit entsteht denn der Heap benötigt seinerseits ja wieder den VMM. Beim VMM ist aber zu bedenken das dieser 2 verschiedene Arten von Speicher verwalten können muss: zum einen den Kernel-Space selber (also das was in allen virtuellen Adressräumen identisch ist) und den virtuellen Prozess-Space (also alles was für jeden virtuellen Adressraum aka Prozess individuell ist). Zu letzterem können z.B. auch die jeweiligen Paging-Direktorys gehören. Es wäre daher eventuell geschickt wenn der VMM seine Verwaltungsstrukturen immer in den jeweiligen Bereich mit rein legt um jeweils Platz zu sparen (natürlich dürfen die Verwaltungsstrukturen nicht mit User-Mode-Rechten erreichbar sein also die Page-Flags immer passend setzen). Ich denke das man so den eigentlichen Kernel-Space für einen Micro-Kernel bequem auf 64 MB o.ä. beschränken könnte. Für ein richtiges 64 Bit-System spielt das aber keine Rolle und dort sollte man solche Tricks auch besser nicht benutzen, man handelt sich damit nämlich auch ein paar Nachteile ein (es könnte passieren das der Kernel nicht mehr so einfach Shared-Memory einrichten kann weil er dazu eventuell mehrere Paging-Directorys gleichzeitig benutzen muss).

Wie man den Heap in einem Micro-Kernel am besten realisiert ist auch eine Frage des persönlichen Geschmacks. Klar ist das dieser die Pages vom VMM nehmen muss um daraus flexibel passende Häppchen zu machen. Hierzu wurde hier schon einige male über den SLAB-Allocator diskutiert (einfach mal suchen) was aus meiner persönlichen Sicht eine recht gute Idee ist da die mögliche Anzahl an unterschiedlichen Objekt-Größen in einem Micro-Kernel doch ziemlich überschaubar ist. Auch würde es meiner Meinung nach der SLAB-Allocator ermöglichen sich über das Henne-Ei-Problem mit dem VMM hinwegzusetzen. Ob man auf einen dynamischen/flexiblen Heap in einem Micro-Kernel komplett verzichten kann möchte ich eher bezweifeln, ich denke damit würde man sich wohl zu viele andere Probleme holen.


Grüße
Erik