Sulla memoria di sistema ... in particolare la differenza tra `tmpfs,` `shm,` e `hugepages ...`

Ultimamente sono stato curioso dei vari filesystem basati sulla memoria del kernel Linux.

Note:Per quanto mi riguarda, le seguenti domande dovrebbero essere considerate più o meno opzionali rispetto a una migliore comprensione di quella posta nel titolo. Glielo chiedo di seguito perché credo che risponderle possa aiutarmi meglio a capire le differenze, ma poiché la mia comprensione è certamente limitata, ne consegue che altri potrebbero conoscerlo meglio. Sono pronto ad accettare qualsiasi risposta che arricchisca la mia comprensione delle differenze tra i tre filesystem menzionati nel titolo.

In definitiva, penso che mi piacerebbe montare un filesystem utilizzabile, hugepages,anche se qualche leggera ricerca (e ancora più leggero armeggiamento) mi ha portato a credere che a rewritable hugepage mountnon sia un'opzione. Mi sbaglio? Quali sono le meccaniche in gioco qui?

Anche riguardo hugepages:

     uname -a
3.13.3-1-MANJARO \
#1 SMP PREEMPT \
x86_64 GNU/Linux

    tail -n8 /proc/meminfo
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     8223772 kB
DirectMap2M:    16924672 kB
DirectMap1G:     2097152 kB

(Ecco le versioni full-text di / proc / meminfo e / proc / cpuinfo )

Cosa sta succedendo sopra? Sto già allocando hugepages?C'è una differenza tra DirectMaple pagine di memoria ehugepages?

Aggiornamento Dopo un po 'di spintone da @Gilles, ho aggiunto altre 4 righe sopra e sembra che ci debba essere una differenza, anche se non ne avevo mai sentito parlare DirectMapprima di averlo estratto tailieri ... forse DMIo qualcosa del genere?

Solo un po 'di più ...

Se non ci si hugepagesriesce, e si presume che il backup del disco rigido di tutti i file di immagine sia eseguito da backup, quali sono i rischi del montaggio di loop dal tmpfs?mio filesystem è swappedlo scenario peggiore? Capisco che tmpfsè la cache del filesystem montata - il mio file loop montato può essere scaricato dalla memoria? Ci sono azioni attenuanti che posso intraprendere per evitarlo?

Ultimo: che cos'è esattamente shm,? In che modo differisce o include uno hugepagesotmpfs?

Non c'è differenza tra tmpfs e shm. tmpfs è il nuovo nome di shm. shm sta per SHaredMemory.

Vedi: Linux tmpfs .

Il motivo principale per cui tmpfs è persino usato oggi è questo commento nel mio / etc / fstab sulla mia scatola di Gentoo. BTW Chromium non si costruirà con la linea 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 usi:

1) C'è sempre un mount interno del kernel che non vedrai
affatto. Viene utilizzato per mappature anonime condivise e
memoria condivisa SYSV .

Questo montaggio non dipende da CONFIG_TMPFS. Se CONFIG_TMPFS non è impostato, la parte visibile dell'utente di tmpfs non viene creata. Ma i
meccanismi interni sono sempre presenti.

2) glibc 2.2 e versioni successive si aspettano che tmpfs venga montato su / dev / shm per la
memoria condivisa POSIX (shm_open, shm_unlink). L'aggiunta della seguente
riga a / etc / fstab dovrebbe occuparsi di questo:

tmpfs / dev / shm valori predefiniti di tmpfs 0 0

Ricorda di creare la directory su cui intendi montare tmpfs, se necessario.

Questo montaggio non è necessario per la memoria condivisa SYSV. Il
supporto interno viene utilizzato per questo. (Nelle versioni del kernel 2.3 era
necessario montare il predecessore di tmpfs (shm fs) per usare la
memoria condivisa SYSV )

3) Alcune persone (incluso me) trovano molto conveniente montarlo ad
esempio su / tmp e / var / tmp e hanno una grande partizione di swap. E ora i
montaggi in loop dei file tmpfs funzionano, quindi mkinitrd fornito dalla maggior parte delle
distribuzioni dovrebbe avere successo con un tmpfs / tmp.

4) E probabilmente molto di più non so :-)

tmpfs ha tre opzioni di montaggio per il dimensionamento:

dimensione: il limite di byte allocati per questa istanza di tmpfs. L'impostazione predefinita è metà della RAM fisica senza scambio. Se si sovradimensionano le istanze di tmpfs, la macchina si bloccherà 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. Il valore predefinito è la metà del numero di pagine RAM fisiche o (su una macchina con highmem) il numero di pagine RAM lowmem, a seconda di quale sia il valore più basso.

Dal documento del kernel Hugepage trasparente:

Il supporto trasparente Hugepage massimizza l'utilità della memoria libera rispetto all'approccio di prenotazione di hugetlbfs consentendo a tutta la memoria non utilizzata di essere utilizzata come cache o altre entità mobili (o anche immobili). Non richiede prenotazione per evitare che gli errori di allocazione di hugepage siano rilevabili da userland. Consente il paging e tutte le altre funzionalità VM avanzate disponibili negli hugepage. Non richiede modifiche affinché le applicazioni ne possano trarre vantaggio.

Tuttavia, le applicazioni possono essere ulteriormente ottimizzate per sfruttare questa funzionalità, come ad esempio sono state ottimizzate in precedenza per evitare un flusso di chiamate al sistema mmap per ogni malloc (4k). L'ottimizzazione delle aree utente non è di gran lunga obbligatoria e khugepaged può già occuparsi di allocazioni di pagine di lunga durata anche per applicazioni ignote di hugepage che gestiscono grandi quantità di memoria.

Nuovo commento dopo aver fatto alcuni calcoli:

HugePage Dimensioni: 2 MB
HugePages utilizzati: Nessuno / Off, come evidenziato da tutti gli 0, ma abilitato secondo i 2 MB sopra.
DirectMap4k: 8.03Gb
DirectMap2M: 16.5Gb
DirectMap1G: 2Gb

Usando il Paragrafo sopra riguardante l'ottimizzazione in THS, sembra che 8Gb della tua memoria siano usati da applicazioni che funzionano usando malloc di 4k, 16.5Gb, è stato richiesto da applicazioni che usano malloc di 2M. Le applicazioni che usano malloc di 2M stanno imitando il supporto di HugePage scaricando le sezioni 2M sul kernel. Questo è il metodo preferito, perché una volta che il kernel viene rilasciato dal kernel, la memoria viene rilasciata al sistema, mentre il montaggio di tmpfs tramite hugepage non comporterebbe una pulizia completa fino al riavvio del sistema. Infine, quello semplice, avevi 2 programmi aperti / in esecuzione che richiedevano un malloc di 1Gb

Per quelli di voi che non conoscono un malloc c'è una struttura standard in C che sta per Memory ALLOCation. Questi calcoli servono come prova che la correlazione del PO tra DirectMapping e THS potrebbe essere corretta. Si noti inoltre che montare SOLO HUGEPAGE provocherebbe solo un guadagno in incrementi di 2 MB, mentre lasciare che il sistema gestisca la memoria usando THS si verifica principalmente in blocchi da 4k, il che significa che in termini di gestione della memoria ogni chiamata malloc salva il sistema 2044k (2048 - 4 ) per altri processi da utilizzare.

Per affrontare il problema "DirectMap": il kernel ha una mappatura lineare ("diretta") della memoria fisica , separata dalle mappature virtuali assegnate a ciascun processo utente.

Il kernel usa le pagine più grandi possibili per questa mappatura per ridurre la pressione del TLB.

DirectMap1G è visibile se la tua CPU supporta pagine da 1Gb (da Barcellona in poi; alcuni ambienti virtuali le disabilitano), e se abilitato nel kernel - il valore predefinito è attivo per 2.6.29+.

Non c'è alcuna differenza tra shme tmpfs(in realtà, tmpfsè solo il nuovo nome di ex shmfs). hugetlbfsè un tmpfsfilesystem basato su che alloca il suo spazio da enormi pagine del kernel e ha bisogno di qualche configurazione aggiuntiva (come usarlo è spiegato nella Documentazione / vm / hugetlbpage.txt ).