Não há diferença entre tmpfs e shm. tmpfs é o novo nome para shm. shm significa SHaredMemory.
Veja: Linux tmpfs .
A principal razão pela qual o tmpfs é usado até hoje é esse comentário no meu / etc / fstab na minha caixa do gentoo. O BTW Chromium não será construído 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ção:
O tmpfs tem os seguintes usos:
1) Há sempre uma montagem interna do kernel que você não verá
. Isso é usado para mapeamentos anônimos compartilhados e memória compartilhada SYSV
.
Esta montagem não depende de CONFIG_TMPFS. Se CONFIG_TMPFS não estiver definido, a parte visível do usuário do tmpfs não será criada. Mas os
mecanismos internos estão sempre presentes.
2) O glibc 2.2 e superior esperam que os tmpfs sejam montados em / dev / shm para
memória compartilhada POSIX (shm_open, shm_unlink). A adição da seguinte
linha ao / etc / fstab deve cuidar disso:
Padrão tmpfs / dev / shm tmpfs 0 0
Lembre-se de criar o diretório no qual você pretende montar o tmpfs, se necessário.
Esta montagem não é necessária para a memória compartilhada SYSV. A
montagem interna é usada para isso. (Nas versões do kernel 2.3, era
necessário montar o antecessor do tmpfs (shm fs) para usar a memória
compartilhada SYSV )
3) Algumas pessoas (inclusive eu) acham muito conveniente montá-lo,
por exemplo, em / tmp e / var / tmp e possuem uma grande partição de troca. E agora as
montagens em loop dos arquivos tmpfs funcionam, portanto, o mkinitrd enviado pela maioria das
distribuições deve ter sucesso com um tmpfs / tmp.
4) E provavelmente muito mais eu não sei sobre :-)
O tmpfs possui três opções de montagem para dimensionamento:
tamanho: o limite de bytes alocados para esta instância tmpfs. O padrão é metade da sua RAM física sem troca. Se você sobredimensionar suas instâncias tmpfs, a máquina travará, pois o manipulador de OOM não poderá liberar essa memória.
nr_blocks: o mesmo que tamanho, mas em blocos de PAGE_CACHE_SIZE.
nr_inodes: o número máximo de inodes para esta instância. O padrão é metade do número de suas páginas de RAM físicas ou (em uma máquina com memória alta) o número de páginas de memória RAM baixa, o que for menor.
No Documento transparente do kernel Hugepage:
O Suporte a páginas enormes transparentes maximiza a utilidade da memória livre, se comparado à abordagem de reserva do hugetlbfs, permitindo que toda a memória não utilizada seja usada como cache ou outro móvel (ou mesmo entidades móveis). Ele não requer reserva para impedir que falhas de alocação de páginas enormes sejam perceptíveis na área do usuário. Ele permite que a paginação e todos os outros recursos avançados da VM estejam disponíveis nas grandes páginas. Não requer modificações para os aplicativos tirarem vantagem disso.
No entanto, os aplicativos podem ser otimizados ainda mais para aproveitar esse recurso, como por exemplo, eles foram otimizados antes para evitar uma enxurrada de chamadas do sistema mmap para todos os malloc (4k). A otimização da área do usuário não é obrigatória e o khugepaged já pode cuidar de alocações de páginas de longa duração, mesmo para aplicativos desconhecidos de grandes páginas que lidam com grandes quantidades de memória.
Novo comentário depois de fazer alguns cálculos:
HugePage Tamanho: 2MB
HugePages Usado: Nenhum / Desligado, como evidenciado por todos os 0s, mas ativado conforme os 2Mb acima.
DirectMap4k: 8.03Gb
DirectMap2M: 16.5Gb
DirectMap1G: 2Gb
Usando o parágrafo acima sobre otimização no THS, parece que 8 GB de sua memória estão sendo usados por aplicativos que operam usando mallocs de 4k, 16,5Gb, foram solicitados por aplicativos usando mallocs de 2M. Os aplicativos que usam mallocs da 2M estão imitando o HugePage Support, transferindo 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 Hugepage não resultaria em uma limpeza completa até que o sistema fosse reiniciado. 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 conhecem um malloc, é uma estrutura padrão em C que significa ALLOCation de memória. Esses cálculos servem como prova de que a correlação do OP entre o DirectMapping e o THS talvez esteja correta. Observe também que a montagem de um HUGEPAGE ONLY fs resultaria apenas em ganhos de incrementos de 2 MB, enquanto permitir que o sistema gerencie a memória usando THS ocorre principalmente em blocos de 4k, o que significa que, em termos de gerenciamento de memória, cada chamada malloc salva o sistema em 2044k (2048 - 4 ) para algum outro processo usar.
/proc/meminfoque contêmHugePage(ou a sua versão do kernel não as possui)? Em que arquitetura está (x86_64, suponho)?