No hay diferencia entre tmpfs y shm. tmpfs es el nuevo nombre para shm. shm significa SHaredMemory.
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 cuadro gentoo. Por cierto, Chromium no se construirá con la línea que falta:
# 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
absoluto. Esto se utiliza para asignaciones anónimas compartidas y
memoria compartida SYSV .
Este montaje no depende de CONFIG_TMPFS. Si no se establece CONFIG_TMPFS, la parte visible del usuario de tmpfs no se compila. Pero los
mecanismos internos siempre están presentes.
2) glibc 2.2 y superior espera que tmpfs se monte en / dev / shm para la
memoria compartida POSIX (shm_open, shm_unlink). La adición de la siguiente
línea a / etc / fstab debería encargarse de esto:
tmpfs / dev / shm tmpfs predeterminado 0 0
Recuerde crear el directorio en el que piensa montar tmpfs si es necesario.
Este montaje no es necesario para la memoria compartida SYSV. El
montaje interno se utiliza para eso. (En las versiones del kernel 2.3 era
necesario montar el predecesor de tmpfs (shm fs) para usar la
memoria compartida SYSV )
3) A algunas personas (incluido yo) les resulta muy conveniente montarlo,
por ejemplo, en / tmp y / var / tmp y tienen una gran partición de intercambio. Y ahora
los montajes en bucle de los archivos tmpfs funcionan, por lo que mkinitrd enviado por la mayoría de las
distribuciones debería tener éxito con un tmpfs / tmp.
4) Y probablemente mucho más que no sé sobre :-)
tmpfs tiene tres opciones de montaje para dimensionar:
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 de la cantidad de páginas de RAM físicas o (en una máquina con highmem) la cantidad de páginas de RAM de baja memoria, la que sea menor.
Del documento transparente del núcleo de Hugepage:
El soporte transparente de Hugepage maximiza la utilidad de la memoria libre en comparación con el enfoque de reserva de hugetlbfs al permitir que toda la memoria no utilizada se use como caché u otras entidades móviles (o incluso inamovibles). No requiere reserva para evitar que las fallas de asignación de páginas grandes se noten desde el país de usuario. Permite que la paginación y todas las demás funciones avanzadas de VM estén disponibles en las grandes páginas. No requiere modificaciones para que las aplicaciones lo 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 por cada malloc (4k). La optimización de la zona de usuario no es, de lejos, obligatoria y khugepaged ya puede encargarse de las asignaciones de páginas de larga duración, incluso para aplicaciones inconscientes de páginas enormes que manejan grandes cantidades de memoria.
Nuevo comentario después de hacer algunos cálculos:
Tamaño de página enorme: 2MB
Página enorme utilizada: Ninguna / Desactivada, como lo demuestran todos los 0, pero habilitada según los 2Mb anteriores.
DirectMap4k: 8.03Gb
DirectMap2M: 16.5Gb
DirectMap1G: 2Gb
Usando el párrafo anterior con respecto a la optimización en THS, parece que las aplicaciones que funcionan con mallocs de 4k, 16.5Gb, han solicitado aplicaciones de mallocs de 2M. Las aplicaciones que usan mallocs de 2M están imitando el soporte de HugePage al descargar las secciones de 2M en el núcleo. Este es el método preferido, porque una vez que el kernel libera el malloc, la memoria se libera al sistema, mientras que el montaje de tmpfs usando la página enorme no daría lugar a una limpieza completa hasta que el sistema se reiniciara. Por último, el más fácil, tenía 2 programas abiertos / en ejecución que solicitaban un malloc de 1Gb
Para aquellos de ustedes que leen que no conocen un malloc, hay 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 un HUGEPAGE SOLO fs solo generaría una ganancia en incrementos de 2 MB, mientras que permitir que el sistema administre la memoria utilizando THS se produce principalmente en bloques de 4k, lo que significa que, en términos de administración de memoria, cada llamada malloc ahorra el sistema 2044k (2048 - 4 ) para algún otro proceso a utilizar.
/proc/meminfoque contienenHugePage(o su versión del kernel no tiene estas)? ¿En qué arquitectura está esto (x86_64, supongo)?