Na memória do sistema… especificamente a diferença entre 'tmpfs', '' shm 'e' hugepages… '

14

Eu tenho estado curioso ultimamente sobre os vários sistemas de arquivos baseados em memória do kernel Linux.

Note: No que me diz respeito, as questões abaixo devem ser consideradas mais ou menos opcionais quando comparadas com uma melhor compreensão daquilo que é colocado no título. Eu lhes pergunto abaixo porque acredito que respondê-las pode me ajudar a entender melhor as diferenças, mas como meu entendimento é reconhecidamente limitado, segue-se que os outros podem conhecer melhor. Estou preparado para aceitar qualquer resposta que enriquece minha compreensão das diferenças entre os três sistemas de arquivos mencionados no título.

Em última análise, eu acho que gostaria de montar um sistema de arquivos utilizável com hugepages, embora algumas pesquisas leves (e ajustes mais leves) tenham me levado a acreditar que um rewritable hugepage mount não é uma opção. Estou enganado? Quais são as mecânicas em jogo aqui?

Também relacionado a 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

(Aqui estão versões em texto completo de / proc / meminfo e /proc/cpuinfo )

O que está acontecendo no acima? Já estou alocando hugepages? Existe uma diferença entre DirectMap páginas de memória e hugepages?

Atualização Depois de um empurrãozinho do @Gilles, adicionei mais 4 linhas acima e parece que deve haver uma diferença, embora eu nunca tenha ouvido falar de DirectMap antes de puxar esse tail ontem ... talvez DMI ou algo assim?

Apenas um pouco mais ...

Não obtendo êxito com o esforço hugepages e assumindo backups de disco rígido de qualquer arquivo de imagem, quais são os riscos de montar loops de tmpfs? Meu sistema de arquivos sendo swapped o pior cenário? Eu entendo tmpfs é montado cache do sistema de arquivos - meu arquivo de loop montado pode ser pressionado para fora da memória? Há ações atenuantes que posso tomar para evitar isso?

Last - exatamente o que é shm, ? Como ela difere ou inclui hugepages ou tmpfs?

    
por mikeserv 20.03.2014 / 06:11

3 respostas

12

Não há diferença entre tmpfs e shm. tmpfs é o novo nome para shm. shm significa SHaredMemory.

Veja: Linux tmpfs .

O principal motivo pelo qual o tmpfs é usado até hoje é esse comentário no meu / etc / fstab na minha caixa do gentoo. O BTW Chromium não será criado com a linha ausente:

# 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 

que saiu da documentação do kernel do linux

Citações:

tmpfs has the following uses:

1) There is always a kernel internal mount which you will not see at
all. This is used for shared anonymous mappings and SYSV shared
memory.

This mount does not depend on CONFIG_TMPFS. If CONFIG_TMPFS is not set, the user visible part of tmpfs is not build. But the internal
mechanisms are always present.

2) glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
POSIX shared memory (shm_open, shm_unlink). Adding the following
line to /etc/fstab should take care of this:

tmpfs /dev/shm tmpfs defaults 0 0

Remember to create the directory that you intend to mount tmpfs on if necessary.

This mount is not needed for SYSV shared memory. The internal
mount is used for that. (In the 2.3 kernel versions it was
necessary to mount the predecessor of tmpfs (shm fs) to use SYSV
shared memory)

3) Some people (including me) find it very convenient to mount it
e.g. on /tmp and /var/tmp and have a big swap partition. And now
loop mounts of tmpfs files do work, so mkinitrd shipped by most
distributions should succeed with a tmpfs /tmp.

4) And probably a lot more I do not know about :-)

tmpfs has three mount options for sizing:

size: The limit of allocated bytes for this tmpfs instance. The default is half of your physical RAM without swap. If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory.
nr_blocks: The same as size, but in blocks of PAGE_CACHE_SIZE.
nr_inodes: The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower.

Do documento do Kernel de Hugepage transparente:

Transparent Hugepage Support maximizes the usefulness of free memory if compared to the reservation approach of hugetlbfs by allowing all unused memory to be used as cache or other movable (or even unmovable entities). It doesn't require reservation to prevent hugepage allocation failures to be noticeable from userland. It allows paging and all other advanced VM features to be available on the hugepages. It requires no modifications for applications to take advantage of it.

Applications however can be further optimized to take advantage of this feature, like for example they've been optimized before to avoid a flood of mmap system calls for every malloc(4k). Optimizing userland is by far not mandatory and khugepaged already can take care of long lived page allocations even for hugepage unaware applications that deals with large amounts of memory.

Novo comentário depois de fazer alguns cálculos:

Tamanho do HugePage: 2MB
HugePages Usado: None / Off, como evidenciado por todos os 0s, mas habilitado conforme os 2Mb acima.
DirectMap4k: 8.03Gb
DirectMap2M: 16,5 GB
DirectMap1G: 2Gb

Usando o Parágrafo acima com relação à Otimização no THS, parece que o 8Gb de sua memória está sendo usado por aplicativos que operam usando mallocs de 4k, 16.5Gb, foi solicitado por aplicações usando mallocs de 2M. Os aplicativos que usam mallocs da 2M estão imitando o suporte do HugePage ao descarregar as seções 2M para o kernel. Este é o método preferido, porque uma vez que o malloc é liberado pelo kernel, a memória é liberada para o sistema, enquanto a montagem de tmpfs usando a hugepage não resultaria em uma limpeza completa até que o sistema fosse reinicializado. Por fim, o mais fácil, você tinha 2 programas abertos / em execução que solicitavam um malloc de 1Gb

Para aqueles de vocês que não sabem que um malloc é uma estrutura padrão em C que significa Memory ALLOCation. Esses cálculos servem como prova de que a correlação do OP entre o DirectMapping e o THS pode estar correta. Note também que a montagem de um HUGEPAGE ONLY fs resultaria apenas em um ganho de Incrementos de 2MB, enquanto que o sistema gerenciaria a memória usando THS ocorre principalmente em blocos de 4k, significando em termos de gerenciamento de memória toda chamada malloc salva o sistema 2044k (2048 - 4 ) para algum outro processo para usar.

    
por 14.04.2014 / 23:28
4

Para resolver o problema "DirectMap": o kernel tem um mapeamento linear ("direto") de memória física , separado dos mapeamentos virtuais alocados para cada processo do usuário.

O kernel usa as maiores páginas possíveis para esse mapeamento para reduzir a pressão do TLB.

O DirectMap1G fica visível se a sua CPU suportar páginas de 1 Gb (Barcelona em diante; alguns ambientes virtuais as desativam) e, se ativado no kernel - o padrão é ativado para 2.6.29 +.

    
por 20.09.2014 / 15:04
2

Não há diferença entre shm e tmpfs (na verdade, tmpfs é apenas o novo nome do antigo shmfs ). hugetlbfs é um sistema de arquivos baseado em tmpfs que aloca seu espaço de páginas enormes do kernel e precisa de alguma configuração adicional (como usar isso é explicado em Documentation / vm / hugetlbpage.txt ).

    
por 24.03.2014 / 12:49