No hay diferencia entre tmpfs y shm. tmpfs es el nuevo nombre de shm. shm significa memoria compartida.
Ver:Linux tmpfs.
La razón principal por la que tmpfs se usa hoy en día es este comentario en mi /etc/fstab en mi caja de gentoo. Por cierto, Chromium no se compilará si falta la línea:
# 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 salió de la documentación del kernel de Linux
Citando:
tmpfs tiene los siguientes usos:
1) Siempre hay un montaje interno del núcleo que no verá en
todos. Esto se usa para asignaciones anónimas compartidas y SYSV compartido
memoria.
Este montaje no depende de CONFIG_TMPFS. Si no se establece CONFIG_TMPFS, la parte visible del usuario de tmpfs no se construye. Pero el interno
los mecanismos están siempre presentes.
2) glibc 2.2 y versiones posteriores esperan que tmpfs se monte en /dev/shm para
Memoria compartida POSIX (shm_open, shm_unlink). Agregando lo siguiente
la línea a /etc/fstab debería encargarse de esto:
tmpfs /dev/shm tmpfs por defecto 0 0
Recuerde crear el directorio en el que desea montar tmpfs si es necesario.
Esta montura no necesario para la memoria compartida SYSV. El interno
mount se usa para eso. (En las versiones del kernel 2.3 era
necesario montar el predecesor de tmpfs (shm fs) para usar SYSV
memoria compartida)
3) A algunas personas (incluyéndome a mí) les resulta muy conveniente montarlo
p.ej. en /tmp y /var/tmp y tiene una gran partición de intercambio. Y ahora
los montajes en bucle de los archivos tmpfs funcionan, por lo que mkinitrd lo envían la mayoría
las distribuciones deberían tener éxito con un tmpfs /tmp.
4) Y probablemente muchas más que no conozco :-)
tmpfs tiene tres opciones de montaje para el tamaño:
tamaño: El límite de bytes asignados para esta instancia de tmpfs. El valor predeterminado es la mitad de su RAM física sin intercambio. Si sobredimensiona sus instancias tmpfs, la máquina se bloqueará, ya que el controlador OOM no podrá liberar esa memoria.
nr_blocks: Igual que el tamaño, pero en bloques de PAGE_CACHE_SIZE.
nr_inodes: El número máximo de inodos para esta instancia. El valor predeterminado es la mitad del número de páginas RAM físicas o (en una máquina con memoria alta) el número de páginas RAM de memoria baja, lo que sea menor.
Del documento transparente del kernel de Hugepage:
El soporte de página enorme transparente maximiza la utilidad de la memoria libre si se compara con el enfoque de reserva de enormes lbfs al permitir que toda la memoria no utilizada se use como caché u otras entidades móviles (o incluso inmóviles). No requiere reserva para evitar que las fallas de asignación de grandes páginas sean perceptibles desde el área de usuario. Permite que la paginación y todas las demás funciones avanzadas de VM estén disponibles en las páginas gigantes. No requiere modificaciones para que las aplicaciones las aprovechen.
Sin embargo, las aplicaciones se pueden optimizar aún más para aprovechar esta característica, como por ejemplo, se han optimizado antes para evitar una avalancha de llamadas al sistema mmap para cada malloc (4k). Optimizar el espacio de usuario no es obligatorio y khugepaged ya puede encargarse de las asignaciones de páginas de larga duración, incluso para aplicaciones que desconocen las páginas enormes y que manejan grandes cantidades de memoria.
Nuevo comentario después de hacer algunos cálculos:
Tamaño de página enorme:2 MB
HugePages Used:Ninguno/Desactivado, como lo demuestran todos los 0, pero habilitado según los 2Mb anteriores.
DirectMap4k:8,03 Gb
DirectMap2M:16,5 Gb
DirectMap1G:2 Gb
Usando el párrafo anterior con respecto a la optimización en THS, parece que 8 Gb de su memoria están siendo utilizados por aplicaciones que operan con mallocs de 4k, 16.5Gb, aplicaciones que usan mallocs de 2M han solicitado. Las aplicaciones que usan mallocs de 2M imitan el soporte de HugePage al descargar las secciones de 2M al kernel. Este es el método preferido, porque una vez que el núcleo libera el malloc, la memoria se libera al sistema, mientras que montar tmpfs usando la página enorme no daría como resultado una limpieza completa hasta que se reinicie el sistema. Por último, el más fácil, tenías 2 programas abiertos/ejecutando que solicitaron un malloc de 1 Gb
Para aquellos de ustedes que leen y no saben, un malloc es una estructura estándar en C que significa asignación de memoria. Estos cálculos sirven como prueba de que la correlación del OP entre DirectMapping y THS puede ser correcta. También tenga en cuenta que montar SÓLO un ENORME fs solo daría como resultado una ganancia en incrementos de 2 MB, mientras que dejar que el sistema administre la memoria usando THS ocurre principalmente en bloques de 4k, lo que significa que, en términos de administración de memoria, cada llamada malloc ahorra al sistema 2044k (2048 - 4 ) para que lo use algún otro proceso.
Para solucionar el problema de "DirectMap":el núcleo tiene una asignación lineal ("directa") de la memoria física, separada de las asignaciones virtuales asignadas a cada proceso de usuario.
El kernel usa las páginas más grandes posibles para este mapeo para reducir la presión de TLB.
DirectMap1G es visible si su CPU admite páginas de 1 Gb (Barcelona en adelante; algunos entornos virtuales las deshabilitan), y si está habilitado en el kernel, el valor predeterminado es para 2.6.29+.
No hay diferencia entre shm y tmpfs (en realidad, tmpfs es solo el nuevo nombre del anterior shmfs ). hugetlbfs es un tmpfs basado en un sistema de archivos que asigna su espacio desde las páginas grandes del kernel y necesita una configuración adicional (se explica cómo usar esto en Documentation/vm/hugetlbpage.txt).