我最近对各种基于 Linux 内核内存的文件系统感到好奇。
Note:
就我而言,与更好地理解标题中提出的问题相比,下面的问题或多或少应该被认为是可选的。我在下面问他们是因为我相信回答他们可以更好地帮助我理解这些差异,但由于我的理解确实有限,因此其他人可能知道得更好。我准备接受任何能够丰富我对标题中提到的三个文件系统之间差异的理解的答案。
最终我想我想挂载一个可用的文件系统hugepages,
尽管一些轻微的研究(以及更轻微的修补)让我相信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/内存信息和/proc/cpu信息)
上面的情况是怎么回事?我已经分配了吗hugepages?
之间有区别吗DirectMap
内存页和hugepages?
更新经过@Gilles 的一点推动,我在上面又添加了 4 行,看来一定有区别,尽管我从未听说过DirectMap
在拉那个之前tail
昨天……也许DMI
或者其他的东西?
只要再多一点点...
没有取得任何成功hugepages
努力,并假设任何图像文件的硬盘备份,从安装循环有什么风险tmpfs?
我的文件系统是swapped
最坏的情况是什么?我明白tmpfs
已安装文件系统缓存 - 我已安装的循环文件是否会因内存不足而出现压力?我可以采取缓解措施来避免这种情况吗?
最后 - 到底是什么shm,
反正?它与其中有何不同或包括hugepages
或者tmpfs?
答案1
tmpfs 和 shm 之间没有区别。 tmpfs 是 shm 的新名称。 shm 代表共享内存。
看:Linux临时文件系统。
今天使用 tmpfs 的主要原因是我的 gentoo 机器上的 /etc/fstab 中的这条注释。顺便说一句,如果缺少该行,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
引用:
tmpfs有以下用途:
总有一个你根本看不到的内核内部挂载
。这用于共享匿名映射和 SYSV 共享
内存。此挂载不依赖于 CONFIG_TMPFS。如果未设置 CONFIG_TMPFS,则不会构建 tmpfs 的用户可见部分。但内部
机制始终存在。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
共享内存)
有些人(包括我)发现将其安装
在 /tmp 和 /var/tmp 上并拥有一个大交换分区非常方便。现在
tmpfs 文件的循环挂载确实可以工作,因此大多数发行
版附带的 mkinitrd 应该能够成功地使用 tmpfs /tmp。可能还有很多我不知道的:-)
tmpfs 具有三个用于调整大小的挂载选项:
尺寸: 为此 tmpfs 实例分配的字节数限制。默认情况下是物理 RAM 的一半,没有交换。如果您的 tmpfs 实例过大,机器将死锁,因为 OOM 处理程序将无法释放该内存。
块数:与大小相同,但以 PAGE_CACHE_SIZE 为单位。
nr_inodes:此实例的最大索引节点数。默认值是物理 RAM 页面数量的一半,或(在具有 highmem 的机器上)lowmem RAM 页面数量的一半,以较小者为准。
来自透明大页内核文档:
与hugetlbfs的预留方法相比,透明大页支持通过允许所有未使用的内存用作缓存或其他可移动(甚至不可移动的实体)来最大化可用内存的有用性。它不需要保留来防止用户空间注意到大页分配失败。它允许在大页面上使用分页和所有其他高级 VM 功能。应用程序无需修改即可利用它。
然而,应用程序可以进一步优化以利用此功能,例如它们之前已经过优化以避免每个 malloc(4k) 的大量 mmap 系统调用。到目前为止,优化用户空间并不是强制性的,并且 khugepaged 已经可以处理长期页面分配,即使对于处理大量内存的巨页不感知应用程序也是如此。
做了一些计算后的新评论:
HugePage 大小:2MB
使用的 HugePages:无/关闭,如全 0 所示,但根据上面的 2Mb 启用。
DirectMap4k:8.03Gb
DirectMap2M:16.5Gb
DirectMap1G:2Gb
使用上面有关 THS 中优化的段落,看起来 8Gb 的内存正在被使用 4k 的 malloc 操作的应用程序使用,而使用 2M 的 malloc 的应用程序已请求 16.5Gb。使用 2M malloc 的应用程序通过将 2M 部分卸载到内核来模仿 HugePage 支持。这是首选方法,因为一旦内核释放 malloc,内存就会释放给系统,而使用大页面挂载 tmpfs 不会导致完全清理,直到系统重新启动。最后,最简单的一个,您有 2 个程序打开/运行,请求 1Gb 的 malloc
对于那些不知道 malloc 是 C 语言标准结构(代表内存分配)的读者来说。这些计算证明了 DirectMapping 和 THS 之间的 OP 相关性可能是正确的。另请注意,安装仅 HUGEPAGE ONLY fs 只会导致 2MB 增量的增益,而让系统使用 THS 管理内存主要发生在 4k 块中,这意味着就内存管理而言,每个 malloc 调用可为系统节省 2044k(2048 - 4 )供其他进程使用。
答案2
为了解决“DirectMap”问题:内核有物理内存的线性(“直接”)映射,与分配给每个用户进程的虚拟映射分开。
内核使用尽可能大的页面进行此映射,以减少 TLB 压力。
如果您的 CPU 支持 1Gb 页面(巴塞罗那以上;某些虚拟环境禁用它们),则 DirectMap1G 可见,并且如果在内核中启用,则默认为 2.6.29+。
答案3
shm
和之间没有区别tmpfs
(实际上,tmpfs
只是 previous 的新名称shmfs
)。 hugetlbfs
是一个tmpfs
基于 - 的文件系统,它从内核大页面分配空间,并且需要一些额外的配置(如何使用它在文档/vm/hugetlbpage.txt)。