Il n'y a pas de différence entre tmpfs et shm. tmpfs est le nouveau nom de shm. shm signifie SHAredMemory.
Voir :Linux tmpfs.
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 compilera 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
Citation :
tmpfs a les utilisations suivantes :
1) Il y a toujours un montage interne du noyau que vous ne verrez pas à
tout. Ceci est utilisé pour les mappages anonymes partagés et SYSV partagé
Mémoire.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 construite. Mais l'interne
les mécanismes sont toujours présents.2) glibc 2.2 et supérieur s'attend à ce que tmpfs soit monté sur /dev/shm pour
Mémoire partagée POSIX (shm_open, shm_unlink). Ajout de ce qui suit
la ligne vers /etc/fstab devrait s'en occuper :tmpfs /dev/shm tmpfs par défaut 0 0
N'oubliez pas de créer le répertoire sur lequel vous avez l'intention de monter tmpfs si nécessaire.
Cette monture n'est pas nécessaire pour la mémoire partagée SYSV. L'interne
le montage 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 SYSV
mémoire partagée)3) Certaines personnes (dont moi) trouvent très pratique de le monter
par exemple. sur /tmp et /var/tmp et avoir une grande partition de swap. Et maintenant
les montages en boucle des fichiers tmpfs fonctionnent, donc mkinitrd est livré par la plupart
les distributions doivent 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 swap. Si vous surdimensionnez vos instances tmpfs, la machine se bloquera puisque le gestionnaire de MOO ne pourra pas libérer cette mémoire.
nr_blocks : Identique à la taille, mais en blocs de PAGE_CACHE_SIZE.
nr_inodes : Le nombre maximal d'inodes pour cette instance. La valeur par défaut correspond à la moitié du nombre de vos pages de RAM physique ou (sur une machine à mémoire élevée) au nombre de pages de RAM à faible mémoire, selon la valeur la plus faible.
À partir de la documentation transparente du noyau Hugepage :
Transparent Hugepage Support 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 d'autres entités mobiles (ou même non mobiles). Il ne nécessite pas de réservation pour éviter que les échecs d'allocation de pages énormes ne soient perceptibles depuis l'espace utilisateur. Il permet à la pagination et à toutes les autres fonctionnalités avancées de la machine virtuelle d'être disponibles sur les énormes pages. Il ne nécessite aucune modification pour que les applications en profitent.
Les applications peuvent cependant être optimisées pour tirer parti de cette fonctionnalité, comme par exemple elles ont été optimisées auparavant pour éviter un flot d'appels système mmap pour chaque malloc(4k). L'optimisation de userland n'est de loin pas obligatoire et khugepaged peut déjà prendre en charge les allocations de pages à long terme, 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 :
Taille de page énorme :2 Mo
HugePages Used : Aucun/Désactivé, comme en témoignent tous les 0, mais activé selon les 2 Mo ci-dessus.
DirectMap4k :8,03 Go
DirectMap2M :16,5 Go
DirectMap1G :2 Go
En utilisant le paragraphe ci-dessus concernant l'optimisation dans THS, il semble que 8 Go de votre mémoire sont utilisés par des applications qui fonctionnent avec des mallocs de 4k, 16,5 Go, ont été demandés 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 sur le noyau. C'est la méthode préférée, car une fois que le malloc est libéré par le noyau, la mémoire est libérée dans le système, alors que le montage de tmpfs à l'aide de hugepage n'entraînerait pas un nettoyage complet tant que le système n'aurait pas été redémarré. Enfin, la plus facile, vous aviez 2 programmes ouverts/en cours d'exécution qui demandaient un malloc de 1 Go
Pour ceux d'entre vous qui ne savent pas, un malloc est une structure standard en C qui signifie ALLOCation de mémoire. 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'un HUGEPAGE ONLY fs n'entraînerait qu'un gain en incréments de 2 Mo, alors que laisser le système gérer la mémoire à l'aide de THS se produit principalement dans des blocs de 4k, ce qui signifie qu'en termes de gestion de la mémoire, chaque appel malloc enregistre le système 2044k (2048 - 4 ) pour un autre processus à utiliser.
Pour résoudre le problème "DirectMap":le noyau dispose d'un mappage linéaire ("direct") de la mémoire physique, distinct des mappages virtuels alloués à chaque processus utilisateur.
Le noyau utilise les plus grandes pages possibles pour ce mappage afin de réduire la pression TLB.
DirectMap1G est visible si votre processeur prend en charge les pages de 1 Go (à partir de Barcelone; certains environnements virtuels les désactivent) et s'il est activé dans le noyau - la valeur par défaut est activée pour 2.6.29+.
Il n'y a pas de différence entre shm et tmpfs (en fait, tmpfs n'est que le nouveau nom de l'ancien shmfs ). hugetlbfs est un tmpfs - système de fichiers basé sur qui alloue son espace à partir d'énormes pages du noyau et nécessite une configuration supplémentaire (comment l'utiliser est expliqué dans Documentation/vm/hugetlbpage.txt).