在系统内存上，尤其是tmpfs，shm和hugepages之间的区别。

最近，我对基于Linux内核内存的各种文件系统感到好奇。

Note:就我而言，与更好地理解标题中提出的问题相比，以下问题应被视为或多或少是可选的。我在下面问他们，因为我相信回答它们可以更好地帮助我理解这些差异，但是由于我的理解有限，因此其他人可能会更好。我准备接受任何可以丰富我对标题中提到的三个文件系统之间差异的理解的答案。

最终，我认为我想挂载一个可用的文件系统，hugepages,尽管一些轻松的研究（并且仍在进行更轻松的修改）使我相信a rewritable hugepage mount不是一个选择。我错了吗？这里有什么机制？

另外关于 hugepages:

     uname -a
3.13.3-1-MANJARO \
#1 SMP PREEMPT \
x86_64 GNU/Linux

    tail -n8 /proc/meminfo
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     8223772 kB
DirectMap2M:    16924672 kB
DirectMap1G:     2097152 kB

（以下是/ proc / meminfo和/ proc / cpuinfo的全文版本）

以上是怎么回事？我是否已经分配hugepages?了DirectMap内存页和hugepages?

更新 @Gilles稍加推敲之后，我在上面再添加了4行，似乎必须有所区别，尽管DirectMap在tail昨天取消之前我从未听说过……也许DMI是什么？

再多一点...

如果hugepages尝试失败，并假设对任何映像文件进行硬盘备份，那么从tmpfs?文件系统挂载到循环的风险是swapped什么？我的文件系统是否是最坏的情况？我了解tmpfs已挂载的文件系统缓存-可以将我已挂载的循环文件的内存不足吗？我是否可以采取缓解措施来避免这种情况？

最后-到底是什么shm,？它是如何从不同或者包括两种hugepages或tmpfs?

tmpfs和shm之间没有区别。tmpfs是shm的新名称。shm代表SHaredMemory。

请参阅：Linux tmpfs。

今天甚至使用tmpfs的主要原因是我的gentoo框上的/ etc / fstab中的此注释。BTW Chromium无法在缺少该行的情况下进行构建：

# 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 

它来自linux内核文档

报价：

tmpfs具有以下用途：

1）总会有一个内核内部装载，您根本看不到
。这用于共享匿名映射和SYSV共享
内存。

此安装不依赖于CONFIG_TMPFS。如果未设置CONFIG_TMPFS，则不会构建tmpfs的用户可见部分。但是内部
机制始终存在。

2）glibc 2.2及更高版本期望将tmpfs安装在/ dev / shm上以用于
POSIX共享内存（shm_open，shm_unlink）。将以
下行添加到/ etc / fstab中应注意这一点：

tmpfs / dev / shm tmpfs默认值0 0

请记住，如有必要，请创建要在其上装载tmpfs的目录。

是该安装不需要SYSV共享存储器。内部
安装用于此目的。（在2.3内核版本中，
必须挂载tmpfs（shm fs）的前身才能使用SYSV
共享内存）

3）有些人（包括我在内）发现将其安装
在/ tmp和/ var / tmp上非常方便，并且具有很大的交换分区。现在
tmpfs文件的循环挂载可以正常工作，因此大多数
发行版附带的mkinitrd 应该在tmpfs / tmp下成功。

4）也许还有更多我不知道的地方:-)

tmpfs具有三个用于调整大小的安装选项：

size： 为此tmpfs实例分配的字节数限制。默认值为不交换的物理RAM的一半。如果您的tmpfs实例过大，则计算机将死锁，因为OOM处理程序将无法释放该内存。
nr_blocks：与大小相同，但以PAGE_CACHE_SIZE为单位。
nr_inodes：此实例的最大索引节点数。默认值是物理RAM页数的一半，或者（在具有高内存的机器上）低内存RAM页数，以较低者为准。

从透明的Hugepage内核文档中：

与允许使用所有未使用的内存作为高速缓存或其他可移动（或什至不可移动的实体）的缓存方法相比，与Hugelbfs的保留方法相比，透明的Hugepage支持最大程度地提高了可用内存的利用率。不需要保留即可防止用户页面注意到巨大的页面分配失败。它允许在大页面上使用页面调度和所有其他高级VM功能。它不需要应用程序的修改就可以利用它。

但是，可以进一步优化应用程序以利用此功能，例如，在避免对每个malloc（4k）的mmap系统调用泛滥之前，对它们进行了优化。到目前为止，优化用户空间并不是强制性的，并且即使对于处理大量内存的无大型页面应用程序，khugepaged已经可以处理长期的页面分配。

经过一些计算后的新评论：

HugePage大小：2MB使用的
HugePages：无/关闭，如全0所示，但已根据上述2Mb启用。
DirectMap4k：8.03Gb
DirectMap2M：16.5Gb
DirectMap1G：2Gb

使用上面关于THS中的优化的段落，看起来使用4k malloc的应用程序正在使用大约8Gb的内存，而使用2M mallocs的应用程序已请求使用16.5Gb。使用2M malloc的应用程序通过将2M部分卸载到内核来模仿HugePage支持。这是首选方法，因为一旦内核释放了malloc，内存就会释放到系统中，而使用巨型页面挂载tmpfs不会导致完全清除，直到重新引导系统为止。最后，最简单的一个是，您有2个程序正在打开/运行，它们要求1Gb的malloc

对于那些不知道malloc是C中的标准结构（代表内存分配）的读者。这些计算证明了DirectMapping和THS之间的OP相关性可能是正确的。还要注意，仅挂载HUGEPAGE fs只会使增量增加2MB，而让系统使用THS管理内存主要发生在4k块中，这意味着就内存管理而言，每个malloc调用都可以节省系统2044k（2048-4 ）供其他过程使用。

解决“ DirectMap”问题：内核具有物理内存的线性（“直接”）映射，与分配给每个用户进程的虚拟映射分开。

内核使用最大的页面进行此映射，以减少TLB压力。

如果您的CPU支持1Gb页面（从巴塞罗那开始；某些虚拟环境禁用了它们），并且在内核中启用了DirectMap1G，则将可见DirectMap1G-默认值为2.6.29+。

shm和之间没有区别tmpfs（实际上tmpfs只是前者的新名称shmfs）。 hugetlbfs是一个tmpfs基于文件系统，它从内核大页面分配空间，并且需要一些额外的配置（如何使用此方法在Documentation / vm / hugetlbpage.txt中进行了说明）。