Linuxeden开源社区
用于在 Linux 内核中实现 1GB PUD 级 THP 的早期实验性代码显示出积极的基准测试结果，但其他上游利益相关者对这一系列补丁的出现感到惊讶，看起来可能需要一段时间，如果/当补丁被主 line 以帮助在不使用 Hugetlbfs 的情况下减少翻译旁路缓冲区（TLB）压力。
Usama Arif 发布了一个关于 1GB Page Upper Directory (PUD) 透明大页 (THP) 支持的请求评论 (RFC) 补丁系列。这项工作的目的是让 1GB PUD 级别的 THP 能够让应用程序在不使用 Hugetlbfs 的情况下受益于较低的 TLB 压力。补丁系列的封面信解释如下：
“虽然 hugetlbfs 目前提供 1GB 的大页，但它存在显著限制，使其不适合许多工作负载：
1. 静态预留：hugetlbfs 需要在启动时或运行时预先分配大页，占用内存。这需要容量规划、管理开销，并使工作负载编排变得非常复杂，特别是与非使用 hugetlbfs 的工作负载共置时。”
4. 无回退机制：如果无法分配 1GB 的大页，hugetlbfs 会失败而不是回退到更小的页。这使其在内存压力下变得脆弱。
4. 无拆分功能：当只需要部分访问时，hugetlbfs 页无法拆分，导致内存浪费并阻止部分回收。
5. 内存统计：hugetlbfs 内存单独统计，且难以与常规内存池共享。
PUD THP 通过将 1GB 页集成到现有的 THP 基础设施中，解决了这些限制。
补丁系列的基准测试看起来非常有前景：
这些补丁在 Intel Xeon Platinum 8321HC 上的基准测试结果：
测试：True Random Memory Access [1] 测试 4GB 内存区域，使用指针追逐工作负载（通过内存进行 4M 随机指针解引用）：
| 指标 | PUD THP (1GB) | PMD THP (2MB) | 变化 |
|——————-|—————|—————|————–|
| 内存访问时间 | 88 ms | 134 ms | 快 34% |
| 页面错误时间 | 898 ms | 331 ms | 慢 2.7 倍 |处理 1G 页面错误慢 2.7 倍（分配 1G 页面很困难 :)). 对于长时间运行的工作负载，这将是一次性的成本，而访问延迟的 34%提升提供了显著的好处。”
虽然前景光明，但其他上游内核开发者对其中的一些元素提出了质疑，并对新的补丁系列感到意外。例如，Oracle 工程师 Lorenzo Stoakes 评论道：
“好吧，这有点出乎意料 :)”
很希望能在大页（THP）小团体或会议上讨论此事，以便我们提前讨论解决方案。沟通很重要，尤其是像这样的大规模变更。
PUD THP 尤其存在问题，因为它需要页面分配器无法提供的页面，推测你正在使用 CMA 和…这完全是另一回事。
这也因我们已经在 DAX、VFIO 情况下支持它而变得复杂，但这有点像是一种我们需要继续支持的奇怪特殊案例。
关于此事如何与 khugepaged、MADV_COLLAPSE、mTHP（以及我确实希望在我们认真考虑之前看到 Nico 的系列发布）交互，存在一些问题。
所以总的来说，我想要非常谨慎并放慢速度。所以请等我和 David 都同意后再去掉 RFC 标签？
此外，THP 代码库急需重构，说实话，我不想在不偿还一些技术债务的情况下添加主要新功能。
所以让我们谨慎行事，将这视为一个非常早期的实验性代码。
我们将在未来几个月中看到这项 1G THP 工作将走向何方。
转自 Experimental Linux Code For 1GB PUD-Level THPs Shows 34% Faster Memory Access Times – Phoronix