Autor Thema: Mapping verschiedener Tabellen  (Gelesen 5166 mal)

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« am: 25. January 2010, 11:02 »
Morgen zusammen,

ich bin gerade dabei mir eine variable virtuelle Speicherverwaltung zu schreiben.
Dabei muss ich mir ein paar Gedanken machen, wie man am besten die Tabellen mappt.
Wie man L1- und L2-Tabellen mappt ist ja kein Thema.
Aber wie macht man das am besten L3- und L4-Tabellen.
Ich erstelle mir erst einmal für 1 GB Kernel-Space die Tabellen, damit ich mich nicht um die Aktualisierung der Prozesse kümmern muss.
Wie kann ich jetzt die Tabellen selber mappen?

An sich könnte ich ja temporär einen Eintrag der L1-Tabelle immer freihalten, damit ich an die Tabellen rankomme.
Wie praktikabel ist das?
Gibt es vielleicht auch bessere Realisierungen?

Danke.

Gruß
rizor
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 25. January 2010, 14:41 »
Hm, ich hab mir Paging auf x86_64 noch nicht näher angeschaut, aber klappt der alte Trick, das PD gleichzeitig als PT zu nehmen, nicht mehr (also jetzt PML4T als PDPT nehmen)? Wird bei einem vierstufen System wahrscheinlich etwas unübersichtlicher, aber damit sollten ja wie gehabt alle Pagingstrukturen gemappt sein.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 25. January 2010, 17:37 »
Das Problem dürfte doch sein, dass ich dann zwar ab die L3-Werte komme.
Allerdings fehlt mir dann immer noch die L4-Tabelle.
Da weiß ich nur nicht, wie ich das lösen soll.
Außerdem verliere ich doch mehr Speicher, wenn ich einen Eintrag belege.
Bei L2-Tabellen sind das ja nur 4 MB, aber bei L3- oder L4-Tabellen dürfte das ganze noch mehr sein.
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 25. January 2010, 18:48 »
Ist doch nur virtueller Speicher, davon gibt es mehr als genug.

Die L4-Tabellen musst du natürlich irgendwo extra mappen. Davon hat ja auch jeder Prozess wieder seine eigene. Aber das dürften jeweils nur 4k sein, die pro Prozess in den Kernelspeicher gemappt sein müssen.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 26. January 2010, 10:26 »
Das Problem ist doch, dass wenn ich selbst eine L3-Tabelle habe, dass ich dann alle L2-Tabellen (Kernel-Tabellen) mappen muss, damit ich auch ordentlich mappen kann.
Denn dann kann ich die L3-Tabellen einzeln mappen.
Und wenn ich jede L2-Tabelle mappen muss, verliert mein Kernel sehr viel virtuellen Speicher.
Und bei L4-Tabellen ist der Verlust noch größer.
Oder habe ich gerade einen Denkfehler?
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 26. January 2010, 12:06 »
Ja, natürlich verlierst du virtuellen Speicher. Du verlierst genau 512 GB virtuellen Speicher, wenn du alle Tabellen auf einmal mappst. Klingt viel, klar. Aber wenn man sich überlegt, dass insgesamt 256 TB zur Verfügung stehen, dürfte das verschmerzbar sein.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 27. January 2010, 23:43 »
An sich müsste es doch auch gehen, wenn ich die ganzen Tabellen selber mappe und nicht als Tabellen interpretieren, oder?
Dann würde ich schon sehr viel mehr Speicher zur Verfügung haben.
Ich möchte nicht, dass mein Kernel mehr als 512 GB verbrät, nicht mal bei mehreren TB, das ist mir ein wenig zu ineffektiv.
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

Programm Noob

  • Gast
Gespeichert
« Antwort #7 am: 28. January 2010, 02:19 »
256 TB sind 256000 GB  da fallen doch wohl 512 GB nicht aus, und eine Frage mit was willst du 256000 GB befüllen?

Programm Noob

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 28. January 2010, 12:10 »
An sich müsste es doch auch gehen, wenn ich die ganzen Tabellen selber mappe und nicht als Tabellen interpretieren, oder?
Klar kannst du auch die Tabellen jedes Mal von Hand temporär mappen. Im Gegensatz zum verschenkten virtuellen Speicher, den wirklich niemand interessiert, könnte das dann allerdins einen tatsächlichen Unterschied für die Performance machen.

Zitat
Dann würde ich schon sehr viel mehr Speicher zur Verfügung haben.
Und was willst du mit dem? Den tatsächlich vorhandenen RAM tausendfach hintereinander mappen? Falls du jemals dazu kommen solltest, diesen virtuellen Adressraum tatsächlich auszunutzen, weil wir in zwanzig Jahre alle terabyteweise RAM haben, dann hast du auch entsprechend viele Daten und brauchst diese 512 GB sowieso, um den Speicher überhaupt irgendwie zu verwalten.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #9 am: 29. January 2010, 09:27 »
An sich müsste es doch auch gehen, wenn ich die ganzen Tabellen selber mappe und nicht als Tabellen interpretieren, oder?
Klar kannst du auch die Tabellen jedes Mal von Hand temporär mappen. Im Gegensatz zum verschenkten virtuellen Speicher, den wirklich niemand interessiert, könnte das dann allerdins einen tatsächlichen Unterschied für die Performance machen.
Zitat
va. wird dabei physischer Speicher verschwendet, dazu müsstest du ja neue Tabellen anlegen und physischer Speicher ist mir persönlich weit wichtiger als virtueller.  :wink:
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

 

Einloggen