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 heute noch verwendet wird, ist dieser Kommentar in meiner /etc/fstab auf meiner Gentoo-Box. Übrigens wird Chromium nicht bauen, wenn die Zeile fehlt:
# 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
die aus der Linux-Kernel-Dokumentation stammt
Zitat:
tmpfs hat die folgenden Verwendungen:
1) Es gibt immer einen Kernel-internen Mount, den Sie nicht sehen werden
alle. Dies wird für freigegebene anonyme Zuordnungen und SYSV-Freigabe verwendet
Erinnerung.
Dieser Mount hängt nicht von CONFIG_TMPFS ab. Wenn CONFIG_TMPFS nicht gesetzt ist, wird der für den Benutzer sichtbare Teil von tmpfs nicht erstellt. Aber das Innere
Mechanismen sind immer vorhanden.
2) glibc 2.2 und höher erwartet, dass tmpfs unter /dev/shm gemountet wird
Gemeinsamer POSIX-Speicher (shm_open, shm_unlink). Folgendes hinzufügen
Zeile nach /etc/fstab sollte sich darum kümmern:
tmpfs /dev/shm tmpfs-Standardwerte 0 0
Denken Sie daran, bei Bedarf das Verzeichnis zu erstellen, in dem Sie tmpfs mounten möchten.
Dieses Reittier ist nicht benötigt für SYSV Shared Memory. Das Innere
mount wird dafür verwendet. (In den 2.3-Kernel-Versionen war es
notwendig, um den Vorgänger von tmpfs (shm fs) zu mounten, um SYSV zu verwenden
gemeinsamer Speicher)
3) Einige Leute (einschließlich mir) finden es sehr praktisch, es zu montieren
z.B. auf /tmp und /var/tmp und haben eine große Swap-Partition. Und nun
Loop-Mounts von tmpfs-Dateien funktionieren, daher wird mkinitrd von den meisten ausgeliefert
Distributionen sollten mit einem tmpfs /tmp.
4) Und wahrscheinlich noch viel mehr, von denen ich nichts weiß :-)
tmpfs hat drei Mount-Optionen für die Größenanpassung:
Größe: Das Limit der zugewiesenen Bytes für diese tmpfs-Instanz. Der Standardwert ist die Hälfte Ihres physischen Arbeitsspeichers ohne Swap. Wenn Sie Ihre tmpfs-Instanzen überdimensionieren, kommt es zu Deadlocks, da der OOM-Handler diesen Speicher nicht freigeben kann.
nr_blocks: Das gleiche wie Größe, aber 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 einer Maschine mit Highmem) die Anzahl der Lowmem-RAM-Seiten, je nachdem, welcher Wert niedriger ist.
Aus dem Transparent Hugepage Kernel Doc:
Transparent Hugepage Support maximiert die Nützlichkeit von freiem Speicher im Vergleich zum Reservierungsansatz von hugetlbfs, indem zugelassen wird, dass nicht verwendeter Speicher als Cache oder andere bewegliche (oder sogar nicht bewegliche) Einheiten verwendet wird. Es ist keine Reservierung erforderlich, um zu verhindern, dass Fehler bei der Zuordnung riesiger Seiten vom Userland aus wahrgenommen werden. Es ermöglicht Paging und alle anderen erweiterten VM-Funktionen, die auf den Hugepages verfügbar sind. Es sind keine Änderungen erforderlich, damit Anwendungen davon profitieren können.
Anwendungen können jedoch weiter optimiert werden, um diese Funktion zu nutzen, so wie sie beispielsweise zuvor optimiert wurden, um eine Flut von mmap-Systemaufrufen für jedes malloc(4k) zu vermeiden. Das Optimieren von Userland ist bei weitem nicht obligatorisch und khugepaged kann sich bereits um langlebige Seitenzuweisungen kümmern, sogar für Anwendungen, die keine Hugepage kennen und mit großen Speichermengen umgehen.
Neuer Kommentar nach einigen Berechnungen:
HugePage-Größe:2 MB
HugePages Used:None/Off, wie durch alle Nullen belegt, aber gemäß den 2 MB oben 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 ob 8 GB Ihres Speichers von Anwendungen verwendet werden, die mit Mallocs von 4 KB arbeiten, 16,5 GB, wurden von Anwendungen angefordert, die Mallocs von 2 MB verwenden. Die Anwendungen, die Mallocs von 2M verwenden, ahmen HugePage Support nach, indem sie die 2M-Abschnitte an den Kernel auslagern. Dies ist die bevorzugte Methode, da der Speicher nach der Freigabe von malloc durch den Kernel für das System freigegeben wird, während das Mounten von tmpfs mithilfe von hugepage erst nach einem Neustart des Systems zu einer vollständigen Bereinigung führen würde. Zuletzt, die einfache, Sie hatten 2 Programme geöffnet/ausgeführt, die einen Malloc von 1 GB angefordert haben
Für diejenigen unter Ihnen, die lesen und nicht wissen, dass Malloc eine Standardstruktur in C ist, die für Memory ALLOCation steht. Diese Berechnungen dienen als Beweis dafür, dass die Korrelation des OP zwischen DirectMapping und THS möglicherweise korrekt ist. Beachten Sie auch, dass das Mounten eines HUGEPAGE ONLY fs nur zu einem Gewinn in Schritten von 2 MB führen würde, während das System den Speicher mit THS verwalten lässt, meistens in 4k-Blöcken erfolgt, was bedeutet, dass in Bezug auf die Speicherverwaltung jeder malloc-Aufruf dem System 2044k (2048 - 4 ) für einen anderen zu verwendenden Prozess.
Um das "DirectMap"-Problem anzugehen:Der Kernel hat eine lineare ("direkte") Zuordnung des physischen Speichers, getrennt von den virtuellen Zuordnungen, die jedem Benutzerprozess zugewiesen sind.
Der Kernel verwendet die größtmöglichen Seiten für dieses Mapping, um den TLB-Druck zu verringern.
DirectMap1G ist sichtbar, wenn Ihre CPU 1-GB-Seiten unterstützt (ab Barcelona; einige virtuelle Umgebungen deaktivieren sie), und wenn sie im Kernel aktiviert ist, ist die Standardeinstellung für 2.6.29+ aktiviert.
Es gibt keinen Unterschied zwischen shm und tmpfs (eigentlich tmpfs ist nur der neue Name des ehemaligen shmfs ). hugetlbfs ist ein tmpfs -basiertes Dateisystem, das seinen Platz von Kernel-Huge-Pages zuweist und einige zusätzliche Konfigurationsleistungen benötigt (wie man dies verwendet, wird in Documentation/vm/hugetlbpage.txt erklärt).