Thema: Noch mehr Paging-Fragen

[DarkThing]

Hiho

Ich bin jetzt endlich soweit, dass ich Paging aktiviert krieg und sogar verstehe Aber ich hab immer noch n paar Fragen:
1) Welche Vor- und Nachteile haben 4MB-Pages im Gegensatz zu 4kb-Pages? Also mal abgesehen daon, dass man nur eine PageTable für 4Gb RAM braucht.
2) Wie genau gehts mit Paging jetzt weiter? Soweit ich das sehe, sollte man einen Handler für die Page Fault Exception einrichten und Funktionen zum allocaten und freigeben von Pages schreiben. Seh ich das so richtig oder fehlt da noch was?

[SSJ7Gohan]

1) Es gibt keine, ich benutze auch nur 4 KB Pages, da sie leichter zu verwalten sind, als wenn ich zwei verschiedene Arten von Pages nutzen würde.
2) Ja, Funktionen zum allocaten und freen von pages, den Page Fault handler brauchst du, um Pages, die geswappt wurden, wieder zu laden. Wenn ein Programm auf eine unültige Page zugreift, solltest du das Programm terminieren, oder ihm eine Nachricht schicken, so das es anders fortfahren kann.

[Legend]

Na ja, man kann ein paar Kilobyte RAM einsparen. Des weiteren habe ich mal gelesen das im TLB die 4MB Seiten eigene Plätze haben die ansonsten verloren gehen würden. Im wesentlichen fällt aber die Benutzung von 4MB Seiten unter Optimierung.

[joachim_neu]

Ich benutz auch 4kb Seiten und werde auch an dieser Stelle wieder mein Modell beschreiben, nach dem man keine allocate() und free()-Funktionen braucht, sondern diese Vorgänge automatisch vom Handler ausgeführt werden. Das Programm braucht sich somit um nichts zu kümmern.

[Legend]

Und wenn es was offensichtlich falsches tut fällt es nicht mal auf!  

Dieses System könnte ziemlich auf die Systemstabilität gehen. Auf die Applikationsstabilität geht es sowieso.

[WhiteDragon]

@joachim_neu: Ich verstehe deine letzte Aussage nicht - könntest du ein wenig ausschweifender werden?

[Legend]

Er will wieder so schlecht programmieren können wie zu DOS Zeiten.
Ohne malloc und free.

Im Gegensatz zu DOS können sich immerhin Programme dann nicht überschreiben. Aber wenn ein Programm dann halt mal einen fehlerhaften Pointer berechnet hat (z.B. nach nem Array) allokiert sein System mehr Speicher, andere bemerken dies (solange dies nicht in andere allokierte Bereiche reinragt, so schon ne Katastrophe zu finden) und lassen das Programm beenden. Dies setzt natürlich vorraus das ein Programm vorher seinen Bedarf anmeldet.

@joachim_neu: Also du brauchst trotzdem irgendeine Möglichkeit Speicher wieder freizugeben. Es wäre sehr dämlich wenn ein Programm nach einer speicherintensiven Stelle mit 200MB+ im Speicher rumhängt und nur noch 10 braucht o_O

[joachim_neu]

In meinem System wird der Speicher bereitgestellt, wenn er nicht verfügbar ist. Das geht meines Erachtens nach nicht mehr auf das System, als wenn jemand zichma malloc() aufruft, eher noch weniger. Der Vorteil ist beispielsweise, dass man so große Datenbestände logisch hintereinander hat und dadurch viel schneller drauf zugreifen kann.
Angenommen wir haben einen Datenbankserver mit einer 20 MB großen Tabelle. Dann befindet sich die, wenn der Datenbankserver sie so läd, hintereinander im Speicher. Das erleichtert natürlich die Abfragen, da man nicht alle 4kb die nächste Speicherstelle suchen muss, sondern das ganze einfach hintereinander laufen lassen kann.
Außerdem hindere ich keine Applikation daran, dass sie weiterhin ihr malloc() und free() benutzt, nur ist das dann nur "simuliert", hat also quasi keinen Effekt.

[SSJ7Gohan]

Normalerweise ruft malloc () ja einen Systemcall auf, sobald es keinen Speicher mehr hat, und der Systemcall mappt dann eine neue Page in den Prozess. Bei deiner Methode muss auch eine neue Page allokiert werden, und malloc () muss auch darauf achten, das es nicht auf schon benutzte Speicherbereiche zugreift und dafür muss es wieder einen Systemcall aufrufen, wodurch wieder Zeit verschwendet wird.

Wie Legend schon gesagt hat ist diese Methode extrem instabil, was machst du z.B. wenn es zu einem Buffer Overflow kommt? Es würde evt. solange Speicher allokiert bis keiner mehr da ist und unkontrollierbar irgentwelche Befehle ausgeführt, was je nach Rechten des Prozesses sehr schlecht enden könnte.

[Legend]

In meinem System wird der Speicher bereitgestellt, wenn er nicht verfügbar ist. Das geht meines Erachtens nach nicht mehr auf das System, als wenn jemand zichma malloc() aufruft, eher noch weniger. Der Vorteil ist beispielsweise, dass man so große Datenbestände logisch hintereinander hat und dadurch viel schneller drauf zugreifen kann.
Angenommen wir haben einen Datenbankserver mit einer 20 MB großen Tabelle. Dann befindet sich die, wenn der Datenbankserver sie so läd, hintereinander im Speicher. Das erleichtert natürlich die Abfragen, da man nicht alle 4kb die nächste Speicherstelle suchen muss, sondern das ganze einfach hintereinander laufen lassen kann.
Außerdem hindere ich keine Applikation daran, dass sie weiterhin ihr malloc() und free() benutzt, nur ist das dann nur "simuliert", hat also quasi keinen Effekt.

Pfft, bei deinem System benötige ich 20*1024*1024/4096=5120 Page faults um die 20MB zu haben, genau wie mit Lazy Allocation, welche dann noch den Speicher exakt so vergeben kann wie deine Methode. Einziger Unterschied ist ein Mallocaufruf (und nicht zig), also 0,2 Promille mehr wegen einem Systemaufruf, die ich für die wesentlich höhere Sicherheit gerne ausgebe.

20MB von virtuellem Speicher am Stück mit einem Aufruf kriege ich mit malloc sowieso hin.

[DarkThing]

Thx für die ganzen Antworten. Aber mich würden nochmal andere Methoden zum verwalten der Pages interessieren, also zum Unterscheiden zwischen freien und belegten. Momentan hab ich mir drei Methoden überlegt, aber welche ist die effektivste?
- Eine Bitmap anlegen, um zwischen freien und belegten Pages zu unterscheiden
- Freie Pages auf einen Stack pushen. Beim allocaten einfach einen pop ausführen und beim freen einen push
- Die drei verfügbaren Bits von einem PageTableEntry verwenden

[WhiteDragon]

Also selbst verwende ich gerade eine Bitmap zum Unterscheiden von freien und belegten Pages. Allerdings überlege ich dies zu ändern: Eine Verwaltung von freien hintereinanderliegenden Blöcken ist in der Regel weniger speicherintensiv (Ausnahme: extrem viele kleine laufende Programme, was eher unwahrscheinlich ist). Zur Zeit verwende ich also bis zu 128kB für insgesamt bis zu 4GB Speicher mit 4kb-Pages. Das ist mit einer Liste freier, zusammenhängender Blöcke natürlich eleganter.

Außerdem: Die Suche nach einem freien Bereich beliebiger Größe würde so auch schneller werden!

[Homix]

hi,
also in einer Bitmap nach freien Bits zu scannen kann ziemlich langsam sein, vor allem dann wenn der freie Speicher hinten in der Bitmap liegt und mehr als eine Page allokiert werden soll.
Für freie Pages auf einen Stack pushen ist zwar schnell, aber es ist schlicht unmöglich, damit mehr als eine Page allokieren zu lassen, außerdem ist der Speicherverbrauch durch den Stack ziemlich hoch.
Ich habe es selbst auch mal mit den 3 freien Bits in den PageTableEntries probiert, das ist aber noch langsamer als eine Bitmap weil man PageDirectory und PageTable beachten muss.

Jetzt verwende ich ein Array mit Einträgen, die den freien Speicher und die Adresse angeben. Das Array kann auch dynamisch erweitert werden, indem ein einziger Array-Eintrag als zusätzliches Array benutzt wird.
Außerdem ist diese Methode sehr schnell und es lassen sich auch problemlos Blöcke von mehreren MB's schnell allokieren.

cu,
stefan2005

[joachim_neu]

Ich nehme die Stackversion ist angenehmer.

[Homix]

hi,
klar, die Stackversion ist einfach zu realisieren aber wenn man nicht nur 4 KB Pages verteilen will ist diese Variante die schlechteste  

Ich benutze die Stackvariante in der physikalischen Speicherverwaltung, die oben angesprochenen Arrays in der virtuellen Speicherverwaltung.

cu,
stefan2005

[DarkThing]

Ein Nachteil von Stacks wäre auch, dass man nur schwer überprüfen kann, ob eine bestimmte Page belegt/frei ist. Bei nem Bitmap oder einem Array könnte man einfach an der entsprechenden Stelle nachsehen.

Ich denke ich werde mal versuchen die Methode mit den Arrays einzubauen.

[Legend]

Also einen Stack würde ich nur physikalischen Speicher benutzen und selbst dort könnte man Probleme mit z.B. Page Coloring Algorithmen bekommen.

Als Methode für virtuellen  Speicher würde sich auch noch ein binärer Baum anbieten.