Thema: Denkanstoß-Thread: Memory, Paging...

[PowerProgrammer]

Hallo!
Ich möchte mein System mal langsam um Paging und vorallem einem Memory Manager erweitern. Dazu habe ich dann allerdings ein paar Fragen. Ich stelle hier im Laufe der nächsten Zeit einfach meine Fragen, je nach dem, wo ich einen Denkanstoß benötige.

Wie groß soll ein allokierter Block sein?
So wie ich es verstanden habe, soll man am besten mit einem 1. Memory Manager anfangen, der einfach nur immer feste Blöcke verwaltet und vergibt. Vom technischen her bieten sich da Blöcke à 4 MB an, also ein ganzer Page-Directory-Eintrag. Allerdings habe ich das Gefühl, dass das etwas groß ist. Was soll man da am besten nehmen? 4 KB? Das wären dann ja gigantische Datenmengen zur bloßen Verwaltung der Blöcke. Sollte man da vielleicht 512 KB oder 1 MB nehmen, auch wenn das technisch nicht ganz so rund ist?

[bluecode]

Ich bin für 4kb. Ich mein was will mein kleines ls mit 4Mb Speicher (auf 4Mb sollte mein ges. System eigentlich noch laufen), nur weil es ein paarmal Speicher alloziert?
Mal abgesehen davon, was meinst du mit "gigantischen Datenmengen zur bloßen Verwaltung von Blöcke[n]"?

[PowerProgrammer]

"gigantischen Datenmengen zur bloßen Verwaltung von Blöcke[n]":
Um den Speicher zu verwalten, muss der Kernel doch eine Liste der allokierten Elemente haben, um zu erkennen, was schon weg ist und zu welchem Task der Bereich gehört, oder nicht? Angenommen ein großes Programm benötigt 12 MB Speicher. Das wären in der Liste bei 4MB-Blöcken gerade mal 3 Einträge, bei 4KB-Blöcken müssten 3072 Blöcke mit der Liste verwaltet werden, oder etwa nicht? Und wenn es so ist, dann finde ich schon, dass 3 Listeneinträge leicht weniger sind als 3072. Oder denke ich hier ganz falsch und man kann irgendwie auf eine Liste verzichten?

[Termite]

Ich würde sagen du siehst das richtig so. nur solltest du auch noch was anderes bedenken. benötigt ein Programm nur 2kb werden gleich 4 MB reserviert die dann belegt sind und anderen Programmen nicht mehr zur verfügung stehen.

da sind dann die paar kb Verwaltungsdaten doch wieder sehr schnell wieder drinn.  vorallem wenn man sein os auf systemen mit nur ein paar mb testen will.

[PowerProgrammer]

Genau aus diesem Grund fragte ich ja, ob vielleicht 512 KB doch eine Lösung wären, was haltet ihr davon? Oder vielleicht auch 128 KB oder 64 KB, wenn ichs mir recht überlege. Wäre das vielleicht realistisch? Auch wenn das technisch nicht so schön passt?

[kevin]

Die natürliche Größe sind 4k, weil das die Größe einer Page ist und du die Pagingstrukturen sowieso haben mußt. Eine andere halbwegs sinnvolle Wahl wären nur noch 2 MB oder 4 MB, die auch Pagegrößen sein können.

[bluecode]

Um den Speicher zu verwalten, muss der Kernel doch eine Liste der allokierten Elemente haben

Der Kernel muss primär eine Liste der freien, physikalischen Speicherseiten haben. Diese Liste könnte man zB. als Stack (Das ist nicht die einzige Möglichkeit, aber so [ähnlich] habe ich es in lightOS gemacht) implementieren, wobei man zum Allozieren von Speicherseiten einfach von diesem Stack Einträge (Das sind bei mir physikalische Adressen einer 4kb Speicherseite) runterholt und zum Freigeben diese Adresse wieder drauflegt. Das tolle daran ist, dass man den Speicherbereich, den man zum Speichern dieses Stacks braucht, nach und nach (je kleiner der Stack wird) mit freigeben kann.
D.h. im Endeffekt hat man für das Speichern der freien Seiten überhaupt keinen Speicherplatz verbraucht und für die belegten Seiten nur die normalen Page-Tables/-Directories.

edit: In lightOS speichert der Kernel momentan zusätzlich zu den Page-Tables/-Directories noch eine Liste der allozierten Seiten, aber ich kann jetzt ehrlich gesagt nicht mehr sagen, warum/ob das wirklich nötig ist/war.

[...] um zu erkennen, was schon weg ist und zu welchem Task der Bereich gehört, oder nicht?

Das steht doch in den Page-Tables/-Directories dann, dass heißt man könnte es prinzipiell auch dort auslesen.

Angenommen ein großes Programm benötigt 12 MB Speicher.

Der Overhead sind da 3Page-Tables (also 12kb), wenn man davon ausgeht, dass man das allozierte wirklich nur in den Page-Tables/-Directories speichert, richtig? Das erscheint mir wirklich nicht so viel, wenn man es mit der Programmgröße von 12Mb vergleicht.

Mal abgesehen davon ist der Aufwand 4/2Mb und 4kb Speicherseiten gleichzeitig zu verwalten sehr wahrscheinlich um einiges größer.Wenn du das machen wolltest, bräuchtest du wahrscheinlich ausgefeiltere Algorithmen (wegen Fragmentation).
Und wenn du nur 2/4Mb Speicherseiten erlauben willst, dann ist der Overhead für kleinere Programm extrem groß.

[PowerProgrammer]

Hey, vielen, vielen Dank! Ihr habt mir wirklich geholfen!

Vorallem das mit dem Speichern des FREIEN Speichers ist cool, das hat den Vorteil, dass das allokieren etwas schneller geht und außerdem - wie gesagt - der Stack bei steigendem Speicherbedarf kleiner wird und das Teil dann wirklich nie Speicher klaut Darauf muss man erstmal kommen, ich habe etwas schief gedacht

PowerProgrammer

[bluecode]

Ich sollte vielleicht folgendes hinzufügen: Für das Allozieren von physikalisch zusammenhängendem Speicher ist ein Stack natürlich nicht gedacht, dass heißt für Allokationen von z.B.Speicher für DMA sind andere Datenstrukturen besser geeignet (viele nehmen hier eine Bitmap, wobei ich persönlich die auch nicht für sonderlich geeignet halte).

[PowerProgrammer]

So, nun habe ich meine nächsten Fragen mal so. Die sind ziemlich noobisch, aber fragen kostet (mich) ja nichts:

Welchen Bereich des RAM soll ich mit meinem OS belegen?
Wäre es ratsam den ganzen Arbeitsspeicher durchgängig von 1 MB aufwärts zu nutzen? Oder soll ich mein verschiedenes Zeugs noch irgendwo zwischen GRUB und dem ganzen VGA-Zeugs ansiedeln? Lohnt sich das?

Wo beginnt der mem_upper?
In der Multibootspekifikation wird die Größe des verwendbaren Arbeitsspeichers ja in mem_lower und mem_upper unterteilt. Beginnt der obere Arbeitsspeicher dann bei 1 MB genau und der untere Teil bei 0? Ja, oder?

[bluecode]

Wäre es ratsam den ganzen Arbeitsspeicher durchgängig von 1 MB aufwärts zu nutzen? Oder soll ich mein verschiedenes Zeugs noch irgendwo zwischen GRUB und dem ganzen VGA-Zeugs ansiedeln? Lohnt sich das?

Die grub memory-map bzw. die BIOS memory map (das ist exakt das selbe) sagt dir genau welche Bereiche frei/belegt sind.

In der Multibootspekifikation wird die Größe des verwendbaren Arbeitsspeichers ja in mem_lower und mem_upper unterteilt. Beginnt der obere Arbeitsspeicher dann bei 1 MB genau und der untere Teil bei 0? Ja, oder?

Jop, genau. Aber die Zahlen sind nicht so richtig aussagekräftig. Es gibt Systeme, die haben ein Speicherloch zwischen dem 15ten und dem 16ten MB. Teilweise sind auch ACPI Tabellen im RAM. Am besten deine Speicherverwaltung mit oben erwähnter memory-map initialisieren.

[PowerProgrammer]

Das mit der memory map war mir bis jetzt noch nicht klar
Jetzt weiß ich, das es sowas gibt, aber verstehen tue ichs immer noch nicht:

             +-------------------+
     -4      | size              |
             +-------------------+
     0       | base_addr_low     |
     4       | base_addr_high    |
     8       | length_low        |
     12      | length_high       |
     16      | type              |
             +-------------------+

Das ist wohl eine sehr wichtige Information aus den GRUB-Informationen. Allerdings verstehe ich nicht, weshalb die Adressierung mit 64 Bit geschieht?! Überall gibt es 32-Bit-Adressen, nur hier nicht, was läuft da schief?
Desweiteren verstehe ich irgendwie nicht, weshalb die Adressierung bei -4 beginnt. Was soll das? Was bedeutet das size da oben?

Tut mir Leid, dass ich sowas frage, für euch ist das wohl alles super logisch, aber ich muss mich erst in die Materie hereindenken.

[bluecode]

Das ist wohl eine sehr wichtige Information aus den GRUB-Informationen. Allerdings verstehe ich nicht, weshalb die Adressierung mit 64 Bit geschieht?! Überall gibt es 32-Bit-Adressen, nur hier nicht, was läuft da schief?

Man wollte halt dann doch mal mit der Zeit gehen und eben ein bisschen mit PAE und 64bit kompatibel sein.

Desweiteren verstehe ich irgendwie nicht, weshalb die Adressierung bei -4 beginnt. Was soll das? Was bedeutet das size da oben?

Du kriegst einen Pointer auf die memory-map an der Adresse (pointer - 4) steht die größe der mem-map. Die Einträge sind dann von pointer bis (pointer + size).

[PowerProgrammer]

Hi Leute!
Nach einer Pause sitze ich mal wieder am OS-Deven und ich bekomme auch diesesmal nichts auf die Reihe

Es geht sich um folgendes: Ich habe eine kleine Funktion geschrieben um 4k-Blöcke zu allozieren. Das funktionierte theoretisch auch prima.
Nun wollte ich zum Testen mal in Richtung Paging gehen. Und dort beginnen die Probleme:
Durch das aktivierte Paging gibt es nur noch virtuelle Adressen, aber mein toller Blockallokator soll doch den physikalischen Arbeitsspeicher aufteilen. Was ist da zu tun? Wie kann ich das Problem umgehen?

In dem von mir benutzen super Tutorial (http://osdever.net/tutorials/memory1.php) steht zum Beispiel, dass aller physikalischer Speicher als ganzes Beispielsweise an das Ende des virtuellen Adressraums gemappt werden kann. Das ist natürlich ziemlich uneffizient.

Kann mir da jemand helfen?

[bluecode]

Durch das aktivierte Paging gibt es nur noch virtuelle Adressen

Das ist falsch. Du kannst nur noch über die Indirektion des virtuellen Adressraum auf den physischen zugreifen, aber "da" ist letzterer schon noch. Du musst überlegen wie du an den physischen rankommst, aber du kannst ja mappen wie du willst insofern ist das kein Problem. Das einzige was 0xd00f ist, ist dass du an das Page-Directory und an die Page-Tables rankommen musst um zu mappen, deshalben müssen diese von Anfang im virtuellen Adressraum gemappt sein.
Den gesamten anderen physischen Speicher kannst du dann wenn er gebraucht wird dahin mappen wo er gebraucht wird.

aber mein toller Blockallokator soll doch den physikalischen Arbeitsspeicher aufteilen. Was ist da zu tun?

Daran ändert sich mit Paging garnichts (wenn ich jetzt mal Blockallokator als physisches Speichermanagement interpretiere).

dass aller physikalischer Speicher als ganzes Beispielsweise an das Ende des virtuellen Adressraums gemappt werden kann. Das ist natürlich ziemlich uneffizient.

Wie oben gesagt, du brauchst eigentlich nur die Page-Tables und das Page-Directory ständig gemappt, aber es ist halt teilweise auch nicht doof "einfach so" auf den physischen Speicher zuzugreifen und deswegen den ges. physischen Speicher zu mappen. Aber ist wohl im protected-mode mittlerweile vorbei... aber im longmode macht es finde ich wieder Sinn.

[PowerProgrammer]

Hmm okay, eine gute Idee ist es, finde ich, wie in dem Tutorial auch beschrieben, einen Page Directory Entry auf das Page Directory selbst zu linken, so hat man dann immer schön Zugriff auf alle Page Tables.
Ich werde mal schauen, wie fern ich weiterkomme, wenn es doch nicht funzt, frage ich einfach nochmal. Dankeschön!

[ehenkes]

Das wären dann ja gigantische Datenmengen zur bloßen Verwaltung der Blöcke.

Die Lösung ist ein Bitset, siehe James Molloy, Kap. 6.

[kevin]

Nein, das ist die falsche Baustelle. James macht das etwas unglücklich, indem er die gesamte Speicherverwaltung unter den Titel "Paging" abhandelt. Wir unterscheiden hier eigentlich immer recht strikt zwischen der physischen und der virtuellen Speicherverwaltung.

Die physische Speicherverwaltung ist es, mit der man physische Seiten reserviert (bei James Frames) und dafür ist eine Bitmap ein mögliches Mittel. Bei der virtuellen Speicherverwaltung (also Paging) sind die Page Directories und Page Tables die Datenstrukturen, die man braucht.

Damit man keine gigantischen Datenmenge zur Verwaltung braucht, muß man nur die Page Tables tatsächlich anlegen, die auch benutzt werden. Und ein PDE auf das PD selbst zu verlinken kostet genau 4 MB virtuellen Speicher, das ist nicht viel. Physisch wird immer noch nur der Platz belegt, der wirklich benutzt wird.

[ehenkes]

Wir unterscheiden hier eigentlich immer recht strikt zwischen der physischen und der virtuellen Speicherverwaltung.

Interessanter Hinweis. Sollte man dies auch in verschiedenen Modulen halten?

[kevin]

Den Code zu trennen ist auf jeden Fall eine gute Idee. Die physische Speicherverwaltung ist im Gegensatz zur virtuellen Speicherverwaltung auch architekturunabhängig, das sollte schon Grund genug sein. Auch ansonsten haben sie nur insofern miteinander zu tun, daß die virtuelle Speicherverwaltung die physische Speicherverwaltung benutzt.