Thema: Idee zum 36 bzw. 64 bit großen Addressraum

[BadBeu]

Hallo,

im Buch von Tanenbaum habe ich eine interessante Idee gelesen.
Da ja ab dem Pentium II (oder III - muss ich nochmal nachlesen) ja lineare Addressräume bis 64 GByte unterstützt werden bzw. bei 64 bit CPUs sogar einige tausend Terrabyte, habe ich mir gedacht, da ich sowieso auf moderne Architekturen setzen wollte, dass ich Dateien nicht nur lese, sondern einfach komplett in den Addressraum des Programs lade, das diese Datei öffnet.
Durch Paging kann ich ja dann, wenn darauf zugegriffen wird, den entsprechenden Teil laden - geht ja dann einfach von Festplatte - und das Programm ließt dann nur noch aus dem RAM. Falls dann irgendwann weitergelesen wird, brauch ich gar kein I/O mehr, da ich ja einfach aus meinem Addressraum lese - es sei denn, ich muss eine neue Page laden.
Es gibt da nur zwei Probleme, die mir jetzt eingefallen sind:

1. Der Page-Daemon muss das Dateiformat verstehen, in welchem die Dateien vorliegen. Wenn man also mehrere Datei-Format unterstützt müsste dann immer zunächst der Treiber für dieses Format aufgerufen werden - d.h. mehr Overhead

2. Der Programmierstil ändert sich gravierend gegenüber anderen OS. Ich bekomme dann nicht mehr meine Bytes, die ich auslesen wollte, sondern einen Pointer zum Begin der Datei, die in meinem Addressraum liegt. Durch einfach Pointerarithmetik komme ich dann zu meinen Bytes, die ich haben möchte, aber es ist eine Umstellung.

Haltet ihr sowas für realisierbar. Eben einmal OS-technisch und einmal User-technisch?

Schonmal Danke für die Antworten

[Termite]

Hi

wieso sollter der Page-Daemon das dateiformat kennen? er bildet die datei doch nur bitweise im speicher ab. nicht mehr und nicht weniger. Wieso sollte er dazu das format kennen?

Mir fallen nur ein paar andere sachen ein.
- Speichern von dateien? Wie soll das gehandahbt werden?
- Dateien read only öffnen?
- Arbeiten mit mehreren dateien? ( was passiert wenn eine datei, z.B. eine log datei immer grösser wird. was passiert mit der datei, die danach im speicher liegt?
- Wie soll sich das system verhalten, wenn dateien von anderen prozessen verändert werden? z.B. logdateien, die du mit einem program beobachtest?

gruss

[n3Ro]

Also bei PII/PIII und den anderen IA32 Prozessoren liegst du leider voll daneben. Der Physische Adressraum kann da 36Bit sprich 64GB fassen, virtuell hast du aber immernoch nur 32Bit sprich 4GB, auf die du zu einem Zeitpunkt zugreifen kannst, geht also nicht. Nur Teile der Datei können so im Speicher gemappt werden, was aber nix neues ist, Linux macht das schon möglich.
Bei 64Bit kann man es komplett machen. Momentan hat man da 256TB (48Bit) auf AMD64 Prozzis an Adressraum und maximal 2^52 Byte an RAM zur Verfügung.
I/O Operation fallen auch nicht wirklich weg, man verlagert nur die Aufgabe auf einen Page-Fault-Handler, wobei dieser sehr genau darauf achten muss, wo wann was geschreiben wurde, damit es am Ende auch auf der Festplatte landet.

[n3Ro]

- Speichern von dateien? Wie soll das gehandahbt werden?

Dirty-Bits abfragen und geänderte Daten zurückschreiben

- Dateien read only öffnen?

Read-Only Bit setzen

- Arbeiten mit mehreren dateien? ( was passiert wenn eine datei, z.B. eine log datei immer grösser wird. was passiert mit der datei, die danach im speicher liegt?

Vorher maximalen Bereich festlegen, Dateiverlängerungen können durch Page-Faults abgefangen werden.

- Wie soll sich das system verhalten, wenn dateien von anderen prozessen verändert werden? z.B. logdateien, die du mit einem program beobachtest?

Ganz einfaches Leser-Schreiber-Problem, kann man mit Semphoren, Monitoren etc. lösen.

[Legend]

im Buch von Tanenbaum habe ich eine interessante Idee gelesen.Da ja ab dem Pentium II (oder III - muss ich nochmal nachlesen) ja lineare Addressräume bis 64 GByte unterstützt werden bzw. bei 64 bit CPUs sogar einige tausend Terrabyte, habe ich mir gedacht, da ich sowieso auf moderne Architekturen setzen wollte, dass ich Dateien nicht nur lese, sondern einfach komplett in den Addressraum des Programs lade, das diese Datei öffnet.

Jop, unter Linux könnte dir mmap wahrscheinlich weiterhelfen, Windows hat da auch Mechanismen dafür.

1. Der Page-Daemon muss das Dateiformat verstehen, in welchem die Dateien vorliegen. Wenn man also mehrere Datei-Format unterstützt müsste dann immer zunächst der Treiber für dieses Format aufgerufen werden - d.h. mehr Overhead

Wozu? Bei Pagefault einfach die entsprechenden 4kb in denen der Offset der zum Fault geführt hat aus der Datei laden. Wenn du physische Speicherseiten freimachen willst ein paar dieser Seiten in die Datei speichern. Kein Problem, auch ohne Kenntnis des Dateiformates.

2. Der Programmierstil ändert sich gravierend gegenüber anderen OS. Ich bekomme dann nicht mehr meine Bytes, die ich auslesen wollte, sondern einen Pointer zum Begin der Datei, die in meinem Addressraum liegt. Durch einfach Pointerarithmetik komme ich dann zu meinen Bytes, die ich haben möchte, aber es ist eine Umstellung.

Manche Programme müssten eher umgestellt werden wenn du so eine Funktion nicht bietes, hab leider grad nicht den c't Artikel wo darüber (im Rahmen von 64 Bit glaub ich war das) gesprochen wurde.

Haltet ihr sowas für realisierbar. Eben einmal OS-technisch und einmal User-technisch?

Nicht nur für realisierbar, sondern sogar schon realisiert.

[Termite]

- Arbeiten mit mehreren dateien? ( was passiert wenn eine datei, z.B. eine log datei immer grösser wird. was passiert mit der datei, die danach im speicher liegt?

Vorher maximalen Bereich festlegen, Dateiverlängerungen können durch Page-Faults abgefangen werden.

länge vorher setzen find ich persönlich unpraktikabel. z.B. ein VideoRecorder anwendung. woher will ich vorher wissen ob ich 2Minuten aufzeichne oder doch 2Stunden.

Beim arbeiten mit mehreren Dateien, ich mein jetzt nicht 2 oder 3 sondern wenn ich z.B. mehrere hundert dateien auf und zumache. Dadurch entsteht eine fragmention im hauptspeicher. ggf kann es sogar soweit kommen, das garnichts mehr geht.

- Wie soll sich das system verhalten, wenn dateien von anderen prozessen verändert werden? z.B. logdateien, die du mit einem program beobachtest?

Ganz einfaches Leser-Schreiber-Problem, kann man mit Semphoren, Monitoren etc. lösen.

Ich mein ja nur. der Daemon muss erkennen , das process A die datei verändert hat. -> datei auf platte aktuallisieren. Der Daemom muss dann wissen das B die datei auch geöffnet hat und kopiert die daten wieder in die zugehörigen Speicherbereiche. Oder löscht die pages, damit beim erneuten zugriff neu geladen wird. Alternativ könnte man auch den gleichen speicher verwenden ( aufpassen wenn 2 schreibend öffnen, dann wirds lustig )

- Dateien read only öffnen?

Read-Only Bit setzen

was hab ich dadurch gewonnen? belegten arbeitsspeicher, den ich nicht verändern darf. Ich wollte die datei ja nur lesend öffnen. somit OK. nur was ist, wenn ich die daten unter einem anderen dateinamen speichern will. Und sie dort ggf verändern möchte.

Deamen copiert datei in den speicher setzt read only bit. Anwendung erzeugt neue ziel-datei, und kopiert die dateien von a nach b. Das ist mir ein kopiervorgang zuviel und zwar genau der, der im speicher statfindet.


So wie ich das bisher verstanden habe.

- beim öffnen einer datei bekomme ich einen speicherpointer der auf eine Adresse im speicher zeigt an dem die datei abgebildet wird.
- Der Deamon kümmert sich dann darum, das bei entsprechenden zugriffen, die notwendigen dateifragmente in den speicher gelangen.

Das sowas ggf sinn macht mag ich nicht bezweifeln. nur als generelles interface für Datei IO, bezweifle ich die Praxistauglichkeit.

gruss

[BadBeu]

Erstmal Danke für die vielen Antworten.

Also wenn mehrere Programme die gleich Datei öffnen, kann ich die gleich Datei ja mehrmals in den Addressbereich des jeweiligen Programms mappen. Dann schreibe ich nur auf bzw. von Festplatte, wenn es wirklich notwendig ist. Also wenn ich die Page auf Platte schreibe oder wenn ich sie lese.
Man muss halt nur darauf achten, was noch gebraucht wird, und was nicht.

Wieso kriege ich Probleme bei mehreren hundert Dateien? Wie soll ich mit heutigen Festplatten 265TB voll kriegen. Und selbst wenn du soviele bzw. so große Dateien hast, wird es eh viel zu langsam werden, da du nie soviel RAM hast - jedenfalls nicht in absehbarer Zeit.

Und bezüglich der Fragmentierung: Zur Not kann ich ja eine Daemon laufen lassen, der alles Unnütze rausschmeißt bzw. alles kompremiert - das dauert halt nur ziemlich lange.

[Termite]

Hi

mit fragmentierung mein ich, das problem, das man im realmode hatte in verbindung mit dynamischer speicherzuweisung. das jetzt durch das paging im pm gelöst ist.

Das problem ist z.B. das viele kleine dateien so ungünstig in deinen 256TB verstreut sind, das du nirgendwo genug platz hast eine grosse datei zu öffnen. Das problem entsteht erst nach einer gewissen zeit, nachdem mehrere tausend Dateizugriffe statgefunden haben. Dateien um 1 Stelligen GB bereich haben wir ja schon. Die im 2 stelligen werden sicher bald folgen.

und das umsortieren der dateien? wie soll das funktionieren? die programme haben doch pointer auf den speicherbereich. damit kannst du nicht einfach was durch die gegendschieben. die programme würden auf falsche dateien zugreifen was mit sicherheit zu problemen und abstürtzen führt. Die pointer in der anwendung manipolieren währe ja die naheliegende lösung. nur woher willst du wissen wieviele pointer das programm auf die gleiche datei hat? Dein OS hat keinen einfluss auf die implementierung der anwendung und deren umgang mit dem pointer.

Ich will eigentlich nur auf ggf auftretende probleme aufmerksam machen, über die man sich gedanken machen sollte.

gruss.

[BadBeu]

Nunja. Aber das sind ja auch mehr oder weniger, die Probleme, die man sowieso lösen muss. Bei einem Multiprogramm-System mit meheren Prozessen bzw. Threads gleichzeitig alle mit dynammisch alloziertem Speicher treten ja ähnlich Probleme auf. Zumindest in einem 4GB oder kleineren Adressraum. Außerdem kann man ja auch evtl. Fragmentierten Speicher zulassen. Dann muss man halt die Verwendung von Pointern einschränken und nur über Funktionen, die das OS bereitstellt auf die Dateien zugreifen.
Ist dann natürlich wieder mehr Overhead. Ob es dann noch wirklich schneller ist müsste man halt ausprobieren.

[bluecode]

Dann muss man halt die Verwendung von Pointern einschränken und nur über Funktionen, die das OS bereitstellt auf die Dateien zugreifen. Ist dann natürlich wieder mehr Overhead. Ob es dann noch wirklich schneller ist müsste man halt ausprobieren.

Jo, es gibt kein Problem, das sich nicht durch noch eine Indirektion lösen lässt...   Aber was ist dadurch denn dann gewonnen? Ich find die Idee jedes mal bei einem (Schreib-)Zugriff auf eine Datei nen Pagefault auslösen zu müssen nicht sonderlich performat. Da mach ich doch lieber einen Syscall mit nem ganen Block an zu schreibenden Daten und gut is.

[BadBeu]

Japp. Das habe ich mir auch gedacht, dass es dann wieder zuviel Overhead gibt. Tja, schade. Anscheinend überwiegen die Probleme den Nutzen.
Danke für die Tipps.