Wann sollte ich mmap für den Dateizugriff verwenden?

POSIX-Umgebungen bieten mindestens zwei Möglichkeiten für den Zugriff auf Dateien. Es gibt die Standard - Systemaufrufe open(), read(), write(), und Freunde, aber es gibt auch die Möglichkeit der Verwendung mmap()der Datei in den virtuellen Speicher abzubilden.

Wann ist es vorzuziehen, eine über die andere zu verwenden? Was sind ihre individuellen Vorteile, die zwei Schnittstellen verdienen?

mmapist großartig, wenn mehrere Prozesse schreibgeschützt auf Daten aus derselben Datei zugreifen, was bei den von mir geschriebenen Serversystemen üblich ist. mmapErmöglicht all diesen Prozessen, dieselben physischen Speicherseiten gemeinsam zu nutzen, wodurch viel Speicherplatz gespart wird.

mmapAußerdem kann das Betriebssystem Paging-Vorgänge optimieren. Betrachten Sie beispielsweise zwei Programme. Programm, Adas eine 1MBDatei in einen Puffer einliest , der mit erstellt malloc, und Programm B, das mmapsdie 1-MB-Datei in den Speicher legt. Wenn das Betriebssystem einen Teil des ASpeichers austauschen muss, muss es den Inhalt des zu austauschenden Puffers schreiben, bevor es den Speicher wiederverwenden kann. In diesem BFall können unveränderte mmapSeiten sofort wiederverwendet werden, da das Betriebssystem weiß, wie sie aus der vorhandenen Datei wiederhergestellt werden können, aus der sie stammen mmap. (Das Betriebssystem kann erkennen, welche Seiten unverändert sind, indem es beschreibbare mmapSeiten zunächst als schreibgeschützt markiert und Seg-Fehler abfängt , ähnlich wie bei der Strategie "Beim Schreiben kopieren" .)

mmapist auch nützlich für die Kommunikation zwischen Prozessen . Sie können mmapeine Datei als Lese- / Schreibzugriff in den Prozessen verwenden, die kommunizieren müssen, und dann Synchronisationsprimitive in der mmap'dRegion verwenden (dafür ist das MAP_HASSEMAPHOREFlag vorgesehen).

Ein mmapunangenehmer Ort kann sein, wenn Sie mit sehr großen Dateien auf einem 32-Bit-Computer arbeiten müssen. Dies liegt daran mmap, dass im Adressraum Ihres Prozesses ein zusammenhängender Adressblock gefunden werden muss, der groß genug ist, um in den gesamten Bereich der zugeordneten Datei zu passen. Dies kann zu einem Problem werden, wenn Ihr Adressraum fragmentiert wird und möglicherweise 2 GB Adressraum frei sind, aber kein einzelner Bereich für eine Dateizuordnung von 1 GB geeignet ist. In diesem Fall müssen Sie die Datei möglicherweise in kleineren Blöcken zuordnen, als Sie möchten, dass sie passt.

Eine weitere mögliche Unannehmlichkeit mmapals Ersatz für Lesen / Schreiben besteht darin, dass Sie Ihre Zuordnung für Offsets der Seitengröße starten müssen. Wenn Sie nur einige Daten mit Offset Xabrufen möchten, müssen Sie diesen Offset korrigieren, damit er mit kompatibel ist mmap.

Und schließlich, Lesen / Schreiben der einzige Weg sind Sie können mit einigen Arten von Dateien. mmapkann nicht für Dinge wie Pipes und Ttys verwendet werden .

Ein Bereich, in dem ich fand, dass mmap () kein Vorteil ist, war das Lesen kleiner Dateien (unter 16 KB). Der Overhead von Seitenfehlern beim Lesen der gesamten Datei war sehr hoch im Vergleich zu nur einem einzigen read () - Systemaufruf. Dies liegt daran, dass der Kernel einen Lesevorgang in Ihrer Zeitscheibe manchmal vollständig zufriedenstellen kann, was bedeutet, dass Ihr Code nicht wegschaltet. Bei einem Seitenfehler schien es wahrscheinlicher, dass ein anderes Programm geplant wird, wodurch der Dateivorgang eine höhere Latenz aufweist.

mmaphat den Vorteil, wenn Sie wahlfreien Zugriff auf große Dateien haben. Ein weiterer Vorteil ist, dass Sie mit Speicheroperationen (memcpy, Zeigerarithmetik) darauf zugreifen können, ohne sich um die Pufferung zu kümmern. Normale E / A können bei Verwendung von Puffern manchmal recht schwierig sein, wenn Sie Strukturen haben, die größer als Ihr Puffer sind. Der zu handhabende Code ist oft schwer zu finden, mmap ist im Allgemeinen einfacher. Das heißt, es gibt bestimmte Fallen bei der Arbeit mit mmap. Wie bereits erwähnt, mmapist die Einrichtung recht kostspielig, daher lohnt es sich, sie nur für eine bestimmte Größe (von Maschine zu Maschine unterschiedlich) zu verwenden.

Für reine sequentielle Zugriffe auf die Datei ist dies auch nicht immer die bessere Lösung, obwohl ein entsprechender Aufruf madvisedas Problem mindern kann.

Sie müssen mit Ausrichtungsbeschränkungen Ihrer Architektur (SPARC, itanium) vorsichtig sein. Bei Lese- / Schreib-E / A sind die Puffer häufig richtig ausgerichtet und werden beim Dereferenzieren eines gegossenen Zeigers nicht abgefangen.

Sie müssen auch darauf achten, dass Sie nicht außerhalb der Karte zugreifen. Dies kann leicht passieren, wenn Sie Zeichenfolgenfunktionen auf Ihrer Karte verwenden und Ihre Datei am Ende keine \ 0 enthält. Dies funktioniert meistens, wenn Ihre Dateigröße nicht ein Vielfaches der Seitengröße beträgt, da die letzte Seite mit 0 gefüllt ist (der zugeordnete Bereich hat immer die Größe eines Vielfachen Ihrer Seitengröße).

Neben anderen netten Antworten ein Zitat aus der Linux-Systemprogrammierung von Googles Experte Robert Love:

Vorteile von mmap( )

Das Bearbeiten von Dateien über mmap( )hat eine Handvoll Vorteile gegenüber Standard- read( )und write( )Systemaufrufen. Unter ihnen sind:

• Durch das Lesen und Schreiben in eine speicherabgebildete Datei wird die überflüssige Kopie vermieden, die bei Verwendung der read( )oder write( )Systemaufrufe auftritt , bei denen die Daten in einen und aus einem Benutzerbereichspuffer kopiert werden müssen.

• Abgesehen von möglichen Seitenfehlern verursacht das Lesen und Schreiben in eine speicherabgebildete Datei keinen Systemaufruf oder Kontextwechselaufwand. Es ist so einfach wie der Zugriff auf den Speicher.

• Wenn mehrere Prozesse dasselbe Objekt in den Speicher abbilden, werden die Daten von allen Prozessen gemeinsam genutzt. Schreibgeschützte und gemeinsam genutzte beschreibbare Zuordnungen werden in ihrer Gesamtheit gemeinsam genutzt. Bei privaten beschreibbaren Zuordnungen werden die noch nicht COW-Seiten (Copy-on-Write) gemeinsam genutzt.

• Das Suchen in der Zuordnung erfordert triviale Zeigermanipulationen. Der lseek( )Systemaufruf ist nicht erforderlich .

Aus diesen Gründen mmap( )ist es eine kluge Wahl für viele Anwendungen.

Nachteile von mmap( )

Bei der Verwendung sind einige Punkte zu beachten mmap( ):

• Speicherzuordnungen sind immer eine ganzzahlige Anzahl von Seiten. Somit wird der Unterschied zwischen der Größe der Sicherungsdatei und einer ganzzahligen Anzahl von Seiten als Leerraum "verschwendet". Bei kleinen Dateien kann ein erheblicher Prozentsatz der Zuordnung verschwendet werden. Bei 4-KB-Seiten verschwendet eine 7-Byte-Zuordnung beispielsweise 4.089 Byte.

• Die Speicherzuordnungen müssen in den Adressraum des Prozesses passen. Bei einem 32-Bit-Adressraum kann eine sehr große Anzahl von Zuordnungen unterschiedlicher Größe zu einer Fragmentierung des Adressraums führen, wodurch es schwierig wird, große freie zusammenhängende Bereiche zu finden. Dieses Problem ist bei einem 64-Bit-Adressraum natürlich viel weniger offensichtlich.

• Das Erstellen und Verwalten der Speicherzuordnungen und der zugehörigen Datenstrukturen im Kernel ist mit einem Mehraufwand verbunden. Dieser Overhead wird im Allgemeinen durch den Wegfall der im vorherigen Abschnitt erwähnten Doppelkopie vermieden, insbesondere bei größeren Dateien, auf die häufig zugegriffen wird.

Aus diesen Gründen werden die Vorteile von mmap( )am stärksten realisiert, wenn die zugeordnete Datei groß ist (und somit jeder verschwendete Speicherplatz einen kleinen Prozentsatz der gesamten Zuordnung ausmacht) oder wenn die Gesamtgröße der zugeordneten Datei gleichmäßig durch die Seitengröße teilbar ist ( und somit gibt es keinen verschwendeten Platz).

Die Speicherzuordnung kann im Vergleich zu herkömmlichen E / A einen enormen Geschwindigkeitsvorteil bieten. Das Betriebssystem kann die Daten aus der Quelldatei lesen, wenn die Seiten in der Speicherzuordnungsdatei berührt werden. Dies funktioniert, indem fehlerhafte Seiten erstellt werden, die vom Betriebssystem erkannt werden, und dann lädt das Betriebssystem die entsprechenden Daten automatisch aus der Datei.

Dies funktioniert genauso wie der Paging-Mechanismus und wird normalerweise für Hochgeschwindigkeits-E / A optimiert, indem Daten zu Seitengrenzen und -größen des Systems (normalerweise 4 KB) gelesen werden - eine Größe, für die die meisten Dateisystem-Caches optimiert sind.

Ein Vorteil, der noch nicht aufgeführt ist, ist die Möglichkeit mmap(), eine schreibgeschützte Zuordnung als saubere Seiten beizubehalten. Wenn man einen Puffer im Adressraum des Prozesses zuweist und dann read()den Puffer aus einer Datei füllt, sind die diesem Puffer entsprechenden Speicherseiten jetzt verschmutzt, seit sie geschrieben wurden.

Schmutzige Seiten können vom Kernel nicht aus dem RAM gelöscht werden. Wenn Swap Space vorhanden ist, können sie zum Swap ausgelagert werden. Dies ist jedoch kostspielig und auf einigen Systemen, z. B. kleinen eingebetteten Geräten mit nur Flash-Speicher, gibt es überhaupt keinen Austausch. In diesem Fall bleibt der Puffer im RAM stecken, bis der Prozess beendet wird, oder gibt ihn möglicherweise mit zurück madvise().

Nicht auf mmap()Seiten geschrieben sind sauber. Wenn der Kernel RAM benötigt, kann er diese einfach löschen und den RAM verwenden, in dem sich die Seiten befanden. Wenn der Prozess, bei dem das Mapping durchgeführt wurde, erneut darauf zugreift, führt dies zu einem Seitenfehler. Der Kernel lädt die Seiten aus der Datei neu, aus der sie ursprünglich stammen . Genauso wie sie überhaupt besiedelt waren.

Dies erfordert nicht mehr als einen Prozess, bei dem die zugeordnete Datei verwendet wird, um von Vorteil zu sein.