Il n'y a aucune différence entre tmpfs et shm. tmpfs est le nouveau nom de shm. shm signifie SHaredMemory.
Voir: tmpfs Linux .
La principale raison pour laquelle tmpfs est même utilisé aujourd'hui est ce commentaire dans mon / etc / fstab sur ma boîte gentoo. BTW Chromium ne se construit pas avec la ligne manquante:
# 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
qui est sorti de la documentation du noyau linux
Citant:
tmpfs a les utilisations suivantes:
1) Il y a toujours un montage interne du noyau que vous ne verrez pas du
tout. Ceci est utilisé pour les mappages anonymes partagés et la
mémoire partagée SYSV .
Ce montage ne dépend pas de CONFIG_TMPFS. Si CONFIG_TMPFS n'est pas défini, la partie visible par l'utilisateur de tmpfs n'est pas créée. Mais les
mécanismes internes sont toujours présents.
2) la glibc 2.2 et les versions ultérieures s'attendent à ce que tmpfs soit monté sur / dev / shm pour
la mémoire partagée POSIX (shm_open, shm_unlink). L'ajout de la
ligne suivante à / etc / fstab devrait prendre en charge ceci:
tmpfs / dev / shm valeurs par défaut de tmpfs 0 0
N'oubliez pas de créer le répertoire sur lequel vous souhaitez monter tmpfs si nécessaire.
Ce montage n'est pas nécessaire pour la mémoire partagée SYSV. Le
support interne est utilisé pour cela. (Dans les versions du noyau 2.3, il était
nécessaire de monter le prédécesseur de tmpfs (shm fs) pour utiliser
la mémoire partagée SYSV )
3) Certaines personnes (dont moi) trouvent très pratique de le monter,
par exemple sur / tmp et / var / tmp et ont une grande partition de swap. Et maintenant
, les montages en boucle des fichiers tmpfs fonctionnent, donc mkinitrd fourni par la plupart des
distributions devrait réussir avec un tmpfs / tmp.
4) Et probablement beaucoup plus que je ne connais pas :-)
tmpfs propose trois options de montage pour le dimensionnement:
taille: la limite d'octets alloués pour cette instance tmpfs. La valeur par défaut est la moitié de votre RAM physique sans échange. Si vous surdimensionnez vos instances tmpfs, la machine se bloquera car le gestionnaire OOM ne pourra pas libérer cette mémoire.
nr_blocks: Identique à size, mais en blocs de PAGE_CACHE_SIZE.
nr_inodes: le nombre maximal d'inodes pour cette instance. La valeur par défaut est la moitié du nombre de vos pages RAM physiques ou (sur une machine avec highmem) le nombre de pages RAM lowmem, la valeur la plus faible étant retenue.
Du document transparent Hugepage Kernel Doc:
La prise en charge transparente de Hugepage maximise l'utilité de la mémoire libre par rapport à l'approche de réservation de hugetlbfs en permettant à toute la mémoire inutilisée d'être utilisée comme cache ou autres entités mobiles (ou même inamovibles). Il ne nécessite pas de réservation pour éviter que d'énormes échecs d'allocation de pages ne soient visibles depuis l'espace utilisateur. Il permet à la pagination et à toutes les autres fonctionnalités avancées de VM d'être disponibles sur les pages géantes. Il ne nécessite aucune modification pour que les applications puissent en profiter.
Cependant, les applications peuvent être encore optimisées pour tirer parti de cette fonctionnalité, comme par exemple, elles ont été optimisées auparavant pour éviter une inondation d'appels système mmap pour chaque malloc (4k). L'optimisation de l'espace utilisateur n'est de loin pas obligatoire et khugepaged peut déjà prendre en charge les allocations de pages de longue durée, même pour les applications ignorant les pages énormes qui traitent de grandes quantités de mémoire.
Nouveau commentaire après avoir fait quelques calculs:
HugePage Size: 2MB
HugePages Used: None / Off, comme en témoignent les 0, mais activé selon les 2 Mo ci-dessus.
DirectMap4k: 8.03Gb
DirectMap2M: 16.5Gb
DirectMap1G: 2Gb
En utilisant le paragraphe ci-dessus concernant l'optimisation dans THS, il semble que les 8 Go de votre mémoire soient utilisés par des applications qui fonctionnent avec des mallocs de 4k, 16,5 Go, ont été demandées par des applications utilisant des mallocs de 2M. Les applications utilisant des mallocs de 2M imitent le support HugePage en déchargeant les sections 2M vers le noyau. C'est la méthode préférée, car une fois le malloc libéré par le noyau, la mémoire est libérée sur le système, tandis que le montage de tmpfs à l'aide d'énorme page n'entraînerait pas un nettoyage complet jusqu'à ce que le système soit redémarré. Enfin, le plus simple, vous aviez 2 programmes ouverts / en cours d'exécution qui demandaient un malloc de 1 Go
Pour ceux d'entre vous qui ne connaissent pas un malloc, c'est une structure standard en C qui signifie Memory ALLOCation. Ces calculs servent de preuve que la corrélation de l'OP entre DirectMapping et THS peut être correcte. Notez également que le montage d'une HUGEPAGE UNIQUEMENT fs n'entraînerait qu'un gain en incréments de 2 Mo, tandis que laisser le système gérer la mémoire à l'aide de THS se produit principalement en blocs de 4k, ce qui signifie en termes de gestion de la mémoire que chaque appel malloc enregistre le système 2044k (2048-4 ) pour un autre processus à utiliser.
/proc/meminfoqui contiennentHugePage(ou votre version du noyau ne les a-t-elle pas)? Sur quelle architecture est-ce (x86_64 je suppose)?