Non c'è differenza tra tmpfs e shm. tmpfs è il nuovo nome di shm. shm sta per SHeredMemory.
Vedere:Linux tmpfs.
Il motivo principale per cui tmpfs è ancora usato oggi è questo commento nel mio /etc/fstab sulla mia macchina gentoo. BTW Chromium non verrà compilato con la riga mancante:
# 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
che è uscito dalla documentazione del kernel Linux
Citando:
tmpfs ha i seguenti utilizzi:
1) C'è sempre un montaggio interno del kernel che non vedrai
tutto. Viene utilizzato per mapping anonimi condivisi e SYSV condivisi
memoria.Questo montaggio non dipende da CONFIG_TMPFS. Se CONFIG_TMPFS non è impostato, la parte visibile all'utente di tmpfs non è compilata. Ma l'interno
i meccanismi sono sempre presenti.2) glibc 2.2 e versioni successive si aspettano che tmpfs sia montato su /dev/shm per
Memoria condivisa POSIX (shm_open, shm_unlink). Aggiunta di quanto segue
line a /etc/fstab dovrebbe occuparsi di questo:tmpfs /dev/shm tmpfs predefinito 0 0
Ricordati di creare la directory su cui intendi montare tmpfs se necessario.
Questa montatura non necessario per la memoria condivisa SYSV. L'interno
mount è usato per questo. (Nelle versioni del kernel 2.3 lo era
necessario montare il predecessore di tmpfs (shm fs) per usare SYSV
memoria condivisa)3) Alcune persone (me compreso) trovano molto comodo montarlo
per esempio. su /tmp e /var/tmp e avere una grande partizione di swap. E adesso
i montaggi in loop dei file tmpfs funzionano, quindi mkinitrd viene fornito dalla maggior parte dei file
le distribuzioni dovrebbero riuscire con tmpfs /tmp.4) E probabilmente molto altro di cui non so :-)
tmpfs ha tre opzioni di montaggio per il dimensionamento:
dimensione: Il limite di byte allocati per questa istanza tmpfs. L'impostazione predefinita è metà della RAM fisica senza swap. Se sovradimensioni le tue istanze tmpfs, la macchina andrà in stallo poiché il gestore OOM non sarà in grado di liberare quella memoria.
nr_blocks: Uguale alla dimensione, ma in blocchi di PAGE_CACHE_SIZE.
nr_inodes: Il numero massimo di inode per questa istanza. L'impostazione predefinita è la metà del numero delle tue pagine RAM fisiche o (su una macchina con memoria elevata) il numero di pagine RAM con memoria ridotta, qualunque sia il minore.
Dal trasparente Hugepage Kernel Doc:
Il supporto trasparente di Hugepage massimizza l'utilità della memoria libera rispetto all'approccio di prenotazione di hugetlbfs consentendo a tutta la memoria inutilizzata di essere utilizzata come cache o altre entità mobili (o anche non mobili). Non richiede prenotazione per evitare che enormi errori di allocazione delle pagine siano visibili dall'area utente. Consente di rendere disponibili il paging e tutte le altre funzionalità avanzate della VM nelle pagine enormi. Non richiede alcuna modifica affinché le applicazioni ne traggano vantaggio.
Le applicazioni tuttavia possono essere ulteriormente ottimizzate per trarre vantaggio da questa caratteristica, come ad esempio sono state ottimizzate in precedenza per evitare una marea di chiamate di sistema mmap per ogni malloc (4k). L'ottimizzazione di userland non è di gran lunga obbligatoria e khugepaged può già occuparsi di allocazioni di pagine di lunga durata anche per applicazioni inconsapevoli di hugepage che gestiscono grandi quantità di memoria.
Nuovo commento dopo aver fatto alcuni calcoli:
Dimensione enorme della pagina:2 MB
HugePages Usato:Nessuno/Off, come evidenziato da tutti gli 0, ma abilitato come da 2Mb sopra.
DirectMap4k:8,03 GB
DirectMap2M:16,5 GB
DirectMap1G:2 GB
Utilizzando il paragrafo precedente relativo all'ottimizzazione in THS, sembra che 8 Gb della tua memoria siano utilizzati da applicazioni che operano utilizzando malloc di 4k, 16,5 Gb, sono stati richiesti da applicazioni che utilizzano malloc di 2M. Le applicazioni che utilizzano i malloc di 2M imitano HugePage Support scaricando le sezioni 2M nel kernel. Questo è il metodo preferito, perché una volta che il malloc viene rilasciato dal kernel, la memoria viene rilasciata al sistema, mentre il montaggio di tmpfs usando hugepage non comporterebbe una pulizia completa fino al riavvio del sistema. Infine, quello facile, avevi 2 programmi aperti/in esecuzione che richiedevano un malloc di 1Gb
Per quelli di voi che leggono che non conoscono un malloc è una struttura standard in C che sta per Memory ALLOCation. Questi calcoli servono come prova che la correlazione dell'OP tra DirectMapping e THS potrebbe essere corretta. Si noti inoltre che il montaggio di HUGEPAGE ONLY fs comporterebbe solo un guadagno in incrementi di 2 MB, mentre consentire al sistema di gestire la memoria utilizzando THS avviene principalmente in blocchi 4k, ovvero in termini di gestione della memoria ogni chiamata malloc salva il sistema 2044k (2048 - 4 ) per qualche altro processo da utilizzare.
Per risolvere il problema "DirectMap":il kernel ha una mappatura lineare ("diretta") della memoria fisica, separata dalle mappature virtuali assegnate a ciascun processo utente.
Il kernel utilizza le pagine più grandi possibili per questa mappatura per ridurre la pressione del TLB.
DirectMap1G è visibile se la tua CPU supporta pagine da 1 Gb (da Barcellona in poi; alcuni ambienti virtuali le disabilitano) e se abilitato nel kernel - l'impostazione predefinita è attiva per 2.6.29+.
Non c'è differenza tra shm e tmpfs (in realtà, tmpfs è solo il nuovo nome dell'ex shmfs ). hugetlbfs è un tmpfs - basato su un filesystem che alloca il suo spazio da enormi pagine del kernel e necessita di qualche configurazione aggiuntiva (come usarlo è spiegato in Documentation/vm/hugetlbpage.txt).