Es gibt keinen Unterschied zwischen tmpfs und shm. tmpfs ist der neue Name für shm. shm steht für SHaredMemory.
Siehe: Linux tmpfs .
Der Hauptgrund, warum tmpfs auch heute noch verwendet wird, ist dieser Kommentar in meiner / etc / fstab auf meiner Gentoo-Box. BTW Chromium wird nicht mit der fehlenden Linie bauen:
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
das kam aus der Linux-Kernel-Dokumentation
Zitat:
tmpfs hat die folgenden Verwendungen:
1) Es gibt immer einen kernelinternen Mount, den Sie überhaupt nicht sehen werden
. Dies wird für gemeinsam genutzte anonyme Zuordnungen und gemeinsam genutzten SYSV-
Speicher verwendet.
Dieser Mount hängt nicht von CONFIG_TMPFS ab. Wenn CONFIG_TMPFS nicht festgelegt ist, wird der vom Benutzer sichtbare Teil von tmpfs nicht erstellt. Aber die internen
Mechanismen sind immer vorhanden.
2) glibc 2.2 und höher erwartet, dass tmpfs für
POSIX Shared Memory (shm_open, shm_unlink) in / dev / shm gemountet werden. Das Hinzufügen der folgenden
Zeile zu / etc / fstab sollte dafür sorgen:
tmpfs / dev / shm tmpfs ist standardmäßig 0 0
Denken Sie daran, das Verzeichnis zu erstellen, in das Sie tmpfs bei Bedarf einbinden möchten.
Dieser Mount wird für SYSV Shared Memory nicht benötigt.
Dafür wird der interne Mount verwendet. (In den 2.3-Kernelversionen musste
der Vorgänger von tmpfs (shm fs) eingehängt werden, um SYSV-
Shared Memory zu verwenden.)
3) Einige Leute (einschließlich mir) finden es sehr praktisch, es zu mounten,
zB auf / tmp und / var / tmp und haben eine große Swap-Partition. Und jetzt
funktionieren auch Loop-Mounts von tmpfs-Dateien, sodass mkinitrd, das von den meisten
Distributionen geliefert wird, mit einem tmpfs / tmp erfolgreich sein sollte.
4) Und wahrscheinlich noch viel mehr, von dem ich nichts weiß :-)
tmpfs bietet drei Mount-Optionen zur Größenanpassung:
size: Das Limit der zugewiesenen Bytes für diese tmpfs-Instanz. Die Standardeinstellung ist die Hälfte Ihres physischen Arbeitsspeichers ohne Swap. Wenn Sie Ihre tmpfs-Instanzen überdimensionieren, blockiert der Computer, da der OOM-Handler diesen Speicher nicht freigeben kann.
nr_blocks: Entspricht der Größe, jedoch in Blöcken von PAGE_CACHE_SIZE.
nr_inodes: Die maximale Anzahl von Inodes für diese Instanz. Der Standardwert ist die Hälfte der Anzahl Ihrer physischen RAM-Seiten oder (auf einem Computer mit HighMem) die Anzahl der LowMem-RAM-Seiten, je nachdem, welcher Wert niedriger ist.
Aus dem Transparent Hugepage Kernel Doc:
Transparenter Hugepage-Support maximiert die Nützlichkeit des freien Speichers im Vergleich zum Reservierungsansatz von hugetlbfs, indem alle nicht verwendeten Speicher als Cache oder andere bewegliche (oder sogar unbewegliche) Einheiten verwendet werden können. Es ist keine Reservierung erforderlich, um zu verhindern, dass Fehler bei der Zuweisung großer Seiten vom Benutzerland bemerkt werden. Damit können Paging und alle anderen erweiterten VM-Funktionen auf den riesigen Seiten verfügbar gemacht werden. Es sind keine Änderungen erforderlich, damit Anwendungen davon profitieren können.
Anwendungen können jedoch weiter optimiert werden, um diese Funktion zu nutzen, wie sie beispielsweise zuvor optimiert wurden, um eine Flut von mmap-Systemaufrufen für jeden malloc (4k) zu vermeiden. Die Optimierung des Benutzerlandes ist bei weitem nicht obligatorisch, und khugepaged kann bereits für langlebige Seitenzuordnungen sorgen, selbst für Anwendungen, die keine großen Seiten erkennen und viel Speicher benötigen.
Neuer Kommentar nach einigen Berechnungen:
HugePage-Größe: 2 MB
HugePages-Verwendung: Keine / Aus, wie durch die Nullen belegt, aber gemäß den obigen 2 MB aktiviert.
DirectMap4k: 8,03
GB
DirectMap2M: 16,5 GB DirectMap1G: 2 GB
Unter Verwendung des obigen Abschnitts zur Optimierung in THS sieht es so aus, als würden 8 GB Ihres Speichers von Anwendungen verwendet, die mit Mallocs mit 4 KB und 16,5 GB arbeiten. Anwendungen, die Mallocs mit 2 MB verwenden, forderten dies an. Die Anwendungen, die Mallocs von 2M verwenden, ahmen den HugePage-Support nach, indem sie die 2M-Abschnitte in den Kernel auslagern. Dies ist die bevorzugte Methode, da nach der Freigabe des malloc durch den Kernel der Speicher für das System freigegeben wird, während das Mounten von tmpfs mit hugepage erst nach einem Neustart des Systems zu einer vollständigen Bereinigung führt. Als letztes, das einfache, hatten Sie 2 Programme geöffnet / ausgeführt, die ein Malloc von 1 GB verlangten
Für diejenigen unter Ihnen, die nicht wissen, dass ein Malloc eine Standardstruktur in C ist, die für Memory ALLOCATION steht. Diese Berechnungen dienen als Beweis dafür, dass die OP-Korrelation zwischen DirectMapping und THS möglicherweise korrekt ist. Beachten Sie auch, dass das Mounten von NUR RIESIGEN Fs nur zu einem Zuwachs von Inkrementen von 2 MB führen würde, wohingegen das Verwalten des Speichers mithilfe von THS hauptsächlich in 4-KB-Blöcken erfolgt ), damit ein anderer Prozess verwendet wird.
/proc/meminfo, die diese enthaltenHugePage(oder hat Ihre Kernel-Version diese nicht)? Auf welcher Architektur ist das (x86_64, nehme ich an)?