c - 为什么 Linux 内核不使用大页面？

Question

在我浏览的过程中，我遇到了一个叫做大页面的东西，大页面机制可以使用二级和三级页表中的条目映射 2M 甚至 1G 页面，正如内核文档本身所说:

Usage of huge pages significantly reduces pressure on TLB, improves TLB hit-rate and thus improves overall system performance.

我也浏览了内核源代码，但在涉及 mmap 时，我没有看到 MAP_HUGETLB 的任何用法。事实上，/proc/sys/vm/nr_hugepages 默认设置为 0。这是为什么？这是否意味着内核根本不需要大页面？必须使用大页面的场景有哪些示例？

举个例子:

hugepage = mmap(0, getpagesize() * 4, PROT_WRITE | PROT_READ,
                    MAP_ANON | MAP_HUGETLB | MAP_PRIVATE, 0, 0);

Answer 1

Linux内核对大页面的处理方式主要是让系统管理员从用户空间进行管理。这主要是因为大页面虽然听起来很酷，但也有缺点:例如，它们不能交换到磁盘。 This LWN series on huge pages提供了大量关于该主题的信息。

默认情况下没有保留大页面，可以在启动时通过引导参数保留它们hugepagesz=和 hugepages= (为多个大页面大小指定多次)。大页面也可以在运行时通过 /proc/sys/vm/nr_hugepages 保留。和 /sys/kernel/mm/hugepages/hugepages-*/nr_hugepages .此外，如果.../nr_overcommit_hugepages，它们可以被内核“动态”保留。设置高于 .../nr_hugepages .这些数字反射(reflect)在 /proc/meminfo 中。各种下HugePages_XXX统计信息，用于默认大页面大小 ( Hugepagesize )。

如果文件位于 hugetlbfs 中，则文件支持的映射仅支持大页面文件系统，并且仅具有在挂载时指定的特定大小(挂载选项 pagesize= )。 hugeadm 命令行工具，除其他外，可以提供有关当前安装的信息 hugetlbfs FS 与 --list-all-mounts .想要 hugetlbfs 的一个主要原因安装在您的系统上是为了在 QEMU/libvirt guest 中启用大页面支持。

以上所有内容都涵盖了使用 MAP_HUGETLB 完成的“自愿”大页面分配。 .

---

Linux 也支持 transparent huge pages (THP) .当内核需要时，普通页面可以透明地变大(反之亦然，现有的透明大页面可以分解为普通页面)。这不需要 MAP_HUGETLB ，并且不管 nr_hugepages在 sysfs 中。

也有一些 sysfs 旋钮可以控制 THP。最值得注意的是 /sys/kernel/mm/transparent_hugepage/enabled : always意味着即使没有用户空间程序主动建议，内核也会尝试创建 THP； madvise意味着它只有在用户空间程序通过 madvise(addr, len, MADV_HUGEPAGE) 建议时才会这样做; never意味着他们被禁用。您可能会看到此设置为 always默认情况下在现代 Linux 发行版中，例如Debian 或 Ubuntu 的最新版本。

例如，执行 mmap(0x123 << 21, 2*1024*1024, 7, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)与 /sys/kernel/mm/transparent_hugepage/enabled设置为 always由于请求的映射与 2M 对齐(请注意缺少 MAP_HUGETLB )，因此应该会产生一个 2M 的透明大页面。

---

Does it mean the kernel has no need in huge pages at all? What are some examples of scenarios where huge pages are a must?

一般来说，您并不真的需要任何类型的大页面，没有它们您也可以生活得很好。它们只是一种优化。正如@Mgetz 在上面的评论中提到的那样，它们可能有用的场景是您对非常大的文件进行大量随机内存访问的情况(数据库常见)。在这种情况下最小化 TLB 压力可以显着提高性能。