☰

实际问题

tag-icon • tag-icon memory virtual-memory mmap huge-pages
实际问题

搬家通知

我刚刚从 StackOverflow 问题（我已删除该问题，因为强烈反对交叉发布）中移出了这个问题（稍加修改），该问题在那里尚未得到解答，可能更适合这里。

StackOverflow 问题上有两条评论（但没有答案）。以下是这些评论的简短摘要（请注意，您可能需要阅读实际问题才能理解这一点）：

  • 文件系统方法使您能够使用libhugetlbfs它来做各种各样的事情。
    • 这并不能真正说服我 - 如果我作为应用程序程序员可以在不通过文件系统的情况下分配大页面，那么也可以libhugetlbfs，对吧？
  • 通过文件系统，您可以设置谁可以分配大页面的权限。
    • 当然可以，但不需要通过文件系统。如果任何人都能做到mmap(…, MAP_HUGETLB, …)，那么任何在文件系统级别被拒绝访问的人仍然可以通过这种方式耗尽所有大页面mmap。

实际问题

我目前正在探索Linux下大页分配内存的各种方式。不知何故，我无法理解 HugeTLB“文件系统”的概念。请注意，我不是在谈论透明的大页面 - 这些是完全不同的野兽。

传统方式

传统观点（例如在Debian 维基或者内核文档） 似乎是：

  • 确保正确设置你的内核配置
  • 正确设置各种内核参数
  • 比如说，将一个特殊的文件系统 ( hugetlbfs) 挂载到某个任意目录/dev/hugepages/（这似乎是 Fedora 上的默认设置……）
  • mmap()该目录中的文件到您的地址空间，即，类似：
int fd = open("/dev/hugepages/myfile, O_CREAT | O_RDWR, 0755);
void * addr = mmap(0, 10*1024*1024, (PROT_READ | PROT_WRITE), MAP_SHARED, fd, 0);

…如果这两个调用成功，我应该addr指向分配在 5 个 2 MB 大页面中的 10 MB 内存。好的。

简单的方法

但这似乎太复杂了？

至少在 Linux 5.15 上，整个文件系统的事情似乎完全没有必要。我刚刚尝试过这个：

  • 配置了 HugeTLBfs 的内核
  • 内核参数设置正确（即vm.nr_hugepages > 0）
  • 没有hugetlbfs安装在任何地方

然后做一个mmap匿名内存：

void *addr = mmap(0, 10*1024*1024, (PROT_READ | PROT_WRITE),
                  (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB), 0, 0);

这为我提供了在大页中分配的 10 MB 内存（至少如果我在解释页表中的标志时没有失败的话）。

为什么是文件系统？

所以我的问题是：为什么是文件系统？正如各种指南所建议的那样，是否真的“有必要”通过文件系统，而我上面的尝试只是幸运？文件系统方法是否还有其他优点（除了拥有一个代表 RAM 部分的文件，这看起来像一把巨大的枪……）？或者这可能只是以前MAP_ANONYMOUS | MAP_HUGETLB不允许的时候的残余？

相关内容