Thema: Shared Memory

[Svenska]

Naja, den Fakt, dass eine Page "shared" ist, kannst du im Swapping komplett ignorieren.

Du speicherst halt pro Page irgendwelche Informationen zur Nutzung, um deinen welche-page-auslagern-Algorithmus betreiben zu können und ignorierst den Zustand des Sharings komplett. Wird eine solche, von mehreren Programmen genutzte, Page ausgelagert, bricht natürlich die Systemperformance ein - unter der Voraussetzung, dass du aber genug RAM hast, spielt das keine Rolle.

Naja, ignorieren würde ich das nicht unbedingt. Ich würde sogar sagen, das wenn eine Page bei mehr als 2 Prozessen gemappt ist, dann lohnt sich das Auslagern schon gar nicht mehr.

Wenn du zwingend Speicher benötigst und nur noch shared Pages da sind, dann musst du die zwingend mit auslagern oder OOM-Exceptions werfen. Sonst kann dir dann jeder das System lahmlegen, indem er einfach den RAM mit shared Pages vollmüllt.

Bei mir ist es halt so das du von einem Prozess nicht in den anderen reingucken kannst (auch nicht vom Kernel aus und erst recht nicht auf die PageTables) und von daher kannst du ja nicht wissen ob die Page die du gerade in dem Prozess ausgewählt hast, in dem anderen Prozess auch nicht benötigt wird. Da müsstest du also erst mal das PD von dem anderen Prozess mappen, dann die PageTable um dann nachzusehen ob die Page eventuell ausgelagert werden kann.

Wie gesagt, das ist nicht nötig. Du solltest als Maßstab für die Auslagerfähigkeit einer Page den Nutzungsgrad annehmen und nicht den Zustand - eine Page, die in hundert Prozessen gemappt, aber trotzdem ungenutzt ist, kannst du problemlos auslagern.

Gruß

[FlashBurn]

Wie gesagt, das ist nicht nötig. Du solltest als Maßstab für die Auslagerfähigkeit einer Page den Nutzungsgrad annehmen und nicht den Zustand - eine Page, die in hundert Prozessen gemappt, aber trotzdem ungenutzt ist, kannst du problemlos auslagern.

Ok, wie definierst du Nutzungsgrad und wie würdest du den rausbekommen?

Problem ist hier redet ein Blinder (ich) vom Sehen. Denn ich weiß theoretisch wie das mit dem Auslagern so ungefähr funktioniert, wie das aber implementiert wird da habe ich nicht wirklich eine Ahnung. Aber dafür wird meiner Meinung nach das Dirty-Flag benutzt und das müsstest du dann in allen Prozessen prüfen wo die Page gemappt ist und das finde ich zu aufwendig.

Sonst kann dir dann jeder das System lahmlegen, indem er einfach den RAM mit shared Pages vollmüllt.

So einfach wird es nicht, dafür würdest du dann schon 2 Programme benötigen, weil so wie ich jetzt mein SharedMemory geplant habe, kann der nur erstellt werden in dem du Speicher verschickst und dann brauchst du noch nen Prozess der den dann auch nicht mehr freigibt.

[Svenska]

Hm, ich komm derzeit nicht an mein Minix2-Buch ran, da ich wegen Praktikum wieder zuhause wohne... da standen ein paar Ideen drin.

Ein Beispiel: Du brauchst über jede irgendwo gemappte Page systemweit eine Statistik, die dir angibt, wie oft in einem bestimmten Zeitraum (z.B. zwischen 2 Scheduleraufrufen) eine Page benutzt wurde. Das kann ein Bit oder ein Zähler pro Page sein. Wichtig ist, dass diese Statistik extern gehalten und regelmäßig genullt wird. Brauchst du Speicher, sortierst du diese Liste aufsteigend und lagerst die vorne stehenden Pages der Reihe nach aus, bis genug Speicher frei ist.

Der Zählerstand ist somit der Nutzungsgrad. Allerdings kannst du für jeden Algorithmus auch Fälle konstruieren, bei denen er versagt. In meinem Fall genau dann, wenn dein Prozess alle 500ms seine Daten braucht, der wird dann bei RAM-Knappheit ständig ausgelagert und wieder eingelesen.

[erik.vikinger]

Hallo,

Du brauchst über jede irgendwo gemappte Page systemweit eine Statistik, die dir angibt, wie oft in einem bestimmten Zeitraum (z.B. zwischen 2 Scheduleraufrufen) eine Page benutzt wurde. Das kann ein Bit oder ein Zähler pro Page sein. Wichtig ist, dass diese Statistik extern gehalten und regelmäßig genullt wird. Brauchst du Speicher, sortierst du diese Liste aufsteigend und lagerst die vorne stehenden Pages der Reihe nach aus, bis genug Speicher frei ist.

Hm, interessante Idee, genau sowas möchte ich für mein Paging in HW implementieren. Da ich nur ein einziges Paging-Directory (natürlich mit vielen wild verstreuten Paging-Tables) habe (ach ich liebe Segmentierung) kann ich dafür einfach in HW einen Mechanismus drüber laufen lassen, mit einem bestimmten Zeitraster, der in jedem gültigen Eintrag 2 Zähler dekrementiert (für Lese- und Schreibzugriffe getrennt) und die CPU tut bei jedem Zugriff den entsprechenden Zähler auf 0xFF setzen. Nur sortiert ist das natürlich nicht so das ich zum auslagern immer erst nach den kleinsten Zählern suchen muss, dafür muss ich mir noch was einfallen lassen.


Grüße
Erik

[Svenska]

Wie wäre es, das Sortieren erst im Schadensfall ("jetzt muss ausgelagert werden") durchzuführen? Du kannst ja einen Sicherheitspuffer für z.B. den QuickSort-Rekursionsstack bereithalten. Unter der Voraussetzung, das Swapping eh nicht oft nötig ist und wenn, dann richtig, lohnt es nicht, bereits vorher zu sortieren.

[erik.vikinger]

Hallo,

Wie wäre es, das Sortieren erst im Schadensfall ("jetzt muss ausgelagert werden") durchzuführen?

Das sowieso, mir ging es aber eigentlich darum dass das Sortieren CPU-Zeit kostet. Das könnte man so lösen das der automatische HW-Page-Table-Walker (der nur aktiviert wird wenn der Speicher langsam knapp wird, schließlich kostet er auf jeden Fall etwas Speicherbandbreite) einfach immer die Page-Einträge deren Zähler unter einer dynamischen Schwelle liegen in eine extra Liste einträgt. Dann hätte man zu jedem Zeitpunkt zumindest einige gute Kandidaten (falls diese Pages in der Zwischenzeit nicht wieder von einer CPU angefasst wurden). Ich muss da auf jeden Fall mal ein paar Notizen meiner Ideen-Liste hinzufügen.


Grüße
Erik

[Svenska]

Das sowieso, mir ging es aber eigentlich darum dass das Sortieren CPU-Zeit kostet.

Wenn du auslagerst, verlierst du Milliarden(!) CPU-Zyklen beim Zugriff auf den Auslagerungsspeicher. Die paar tausend Takte für das Sortieren der Liste fallen da nicht wirklich ins Gewicht.

[erik.vikinger]

Hallo,

verlierst du Milliarden(!) CPU-Zyklen

Da meine CPUs wohl höchstens in den zweistelligen MHZ-Bereich kommen sind es wohl nur Millionen CPU-Zyklen.

Die paar tausend Takte für das Sortieren der Liste fallen da nicht wirklich ins Gewicht.

Aber wenn ich das vermeiden kann in dem die Sortierung in HW abläuft hab ich trotzdem noch was gewonnen, wenn auch nur wenig (zumindest spare ich den Speicher für den Sortier-Code).

Da fällt mir ein das diese Info kaum aktuell ist da ich ja bei den meisten Segmenten ohne Paging auskomme. Wenn der Speicher anfängt knapp zu werden muss ich erst mal bei möglichst vielen Segmenten überhaupt das Paging aktivieren und für diese Bereiche des linearen Adressraums auch (1:1-)Page-Tables erstellen damit es überhaupt sinnvolle Infos über die Speicherbenutzung geben kann.
Das wird auf jeden Fall ein größerer Eintrag in meiner Ideen-Liste.


Grüße
Erik