Grenzen von mmap()?

rüdiger

- ein 32-Bit System welches keinen Gebrauch von LFS
(Large File Support) macht?
- ein 32-Bit System welches Gebrauch von LFS macht?
- ein 64-Bit System

1. 2³²
2.,3. 2⁶⁴

- I zweifel irgendwie dran, das die vollen 64-Bit (wäre irgendwas mit
Exabyte) verfügbar sind auf jeder Maschine. Weiss jemand mehr?

Wieso nicht? Ist doch nur vom physischen Speicher limitiert.

- Weiss jemand ob das immer noch zutrifft für die aktuellen Kernel
bzw. was es noch alles für Einschränkungen gibt?

Irgend wie kann man die Speicherlimits glaube ich aus /proc oder /sys auslesen. Weiß jetzt aber nicht wo. Auf jeden Fall kann man die glaube ich bei der Kernelerstellung verändern

Die glibc Dokumentation redet ja hier
von "Pages" die bei Bedarf rein- bzw. rausgemapped werden (ähnlich Swap)

Nein, genau das ist Swaping.

Ich denke dein Problem ist einfach, dass du dir vorstellst, dass dein Arbeitsspeicher auf den physischen RAM beschränkt ist. Aber Pages (Speicherseiten) werden eben ständig aus dem RAM in den Swap Space kopiert und umgekehrt. Such dir vielleicht mal Artikel über modernes Speichermanagement.

immortal

kingruedi schrieb:

1. 2³²
2.,3. 2⁶⁴

hab ich mir fast gedacht, zumindest fuer den theoretischen adressraum...

kingruedi schrieb:

Irgend wie kann man die Speicherlimits glaube ich aus /proc oder /sys auslesen. Weiß jetzt aber nicht wo. Auf jeden Fall kann man die glaube ich bei der Kernelerstellung verändern

ok, das werd ich mal pruefen

kingruedi schrieb:

Wieso nicht? Ist doch nur vom physischen Speicher limitiert.

Nein, genau das ist Swaping.

Ich denke dein Problem ist einfach, dass du dir vorstellst, dass dein Arbeitsspeicher auf den physischen RAM beschränkt ist. Aber Pages (Speicherseiten) werden eben ständig aus dem RAM in den Swap Space kopiert und umgekehrt. Such dir vielleicht mal Artikel über modernes Speichermanagement.

danke fuer die blumen, aber es ging blos um den zusammenhang und der ist jetzt klar wenn es so ablaeuft wie du schreibst

Wenn die Größe also theoretisch keine Rolle spielt, warum werden dann Dateien nicht grundsätzlich mit mmap() geöffnet und bearbeitet? Müsste doch eigentlich schneller sein als das normale Filepointer-Rumgeschiebe, zumindest bei gewolltem wahlfreiem Zugriff, oder? Es muss doch auch nen Nachteil geben...

Ringding

Ja.

Es kommt auf die Größe an - wenn du zwei 900MB-Files gemapped hast und nebenbei noch ein bisschen Heap haben willst, hast du schon ein Problem auf einem 32bit-System.
Ist nicht portabel.
Die Größe muss von vornherein bekannt sein.

TriPhoenix

immortal schrieb:

Hab ich auch gedacht, aber was bedeutet dann dieser Satz aus der glibc Doku?
"If the LFS interface is used the file size on 32-bit systems is not limited to 2GB (offsets are signed which reduces the addressable area of 4GB by half); the full 64-bit are available."

d.h. in meinen Augen, dass es mit dem LFS Interface zumindest möglich ist z.B. 8 GB an einem Stueck zu mappen wenn ich das hier richtig verstehe. Wie der Kernel die Sache effizient verwaltet ist für mich die interessante Frage, da ja nicht dieser Platz im RAM zur Verfügung steht.

Nein auf 32 Bit hilft dir LFS nicht um die ganze Dateireinzumappen. Dazu bräuchtest du 33-Bit-Adressen und die kann man in 32 Bit nunmal nicht darstellen. Du kannst nur auf die gesamte Datei zugreifen und entsprechend Häppchen davon reinmappen. Ohne LFS hättest du keine Chance überhaupt mehr als 2GiB von der Datei je zu sehen. Effektiv gibts also zwei Limits
1. Das Adressraumlimit (wieviel kann ich auf einmal mmap()en?)
2. Das Dateizugriffslimit (auf welchen Teil der Datei kann ich zugreifen?)

Das erste wird von der Architektur und der bestehenden Belegung bestimmt, bei 32-Bit hast du 4GiB Adressraum von dem du dann je nach Kernel ca. 2-3 Gi abzüglich Stack, Heap etc. hast. Auf ner 64-Bit Architektur hast du dementsprechend 2^64 Byte.

LFS regelt dann auf welche Bereiche der Datei du zugreifen kannst, ohne LFS nur auf die ersten 2 GiB, ansonsten auf bis zu 2^64 Byte.

HTH

immortal

danke vielmals, das war genau die loesung die ich gebraucht hab...

Ringding schrieb:

Ist nicht portabel.

portabel inwiefern? wenn ich z.B. die glibc fuer win32 und linux verfuegbar hab muesste es doch funktionieren, oder? (momentan waeren fuer mich nur die 2 systeme wichtig)

Ringding

Ich habe noch nie glibc auf win32 gesehen.

TriPhoenix

Ringding schrieb:

Ich habe noch nie glibc auf win32 gesehen.

Cygwin und Mingw sollten ansich eine haben?

Edit: Wobei ein Google nach glibc win32 tatsächlich anderes andeutet...

immortal

jo, ich benutze mingw und dacht bis grad eben eigentlich auch das sie zumindest ne abgespeckte version von glibc mitliefern, aber sie scheint etwas zu sehr mit linux verzahnt zu sein als das sie sich so einfach portieren laesst.

wird anscheinend alles auf win32 api abgebildet, d.h. wenn ich mmap() benutze muesste ich mindestens ne #ifdef WIN32 variante fuer windoof einbauen. -> schoene scheisse, aber waer net des erste mal in dem programm

ich glaub damit haben wir das ganze soweit erstmal komplett aufgedeckt, danke nochmal.

rüdiger

Cygwin ist zB eine POSIX Implementierung für Windows. Solltest du dir vll. mal angucken, dann hast du weniger Portierungsarbeit.

immortal

kingruedi schrieb:

Cygwin ist zB eine POSIX Implementierung für Windows. Solltest du dir vll. mal angucken, dann hast du weniger Portierungsarbeit.

da hast du recht, leider liegt meine prioritaet auch etwas in kompletter standalone application ohne zusaetzliche dll's oder registry-eintraege wie ich sie z.b. bei cygwin benoetige. zudem hab ich einiges gelesen das die laufzeit mit mingw besser sein soll da es eben versucht native binaries zu bauen, aber das kann unterschliedlich sein, denn mingw is im vergleich zum msvc ja auch grottenlangsam.

im prinzip ist beides nix gescheites, "linux only" waer des beste, da gaebs keine probleme und (fast :)) alle waeren gluecklich