LWN：减少TLB压力的措施！

转载于 2025-04-10 13:34:11 发布 · 1.5k 阅读

CC 4.0 BY-SA版权

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg2MjE0NDE5OA==&mid=2247489173&idx=1&sn=f8b71098a3872012a48d32cdb967bc66&chksm=cf7fc471d9947e21e243e3eacd8f73eb413c6677a55646f2fe4534ca82d92470678ff3175472&scene=126&sessionid=0

关注了就能看到更多这么棒的文章哦～

Approaches to reducing TLB pressure

By Jonathan Corbet
April 2, 2025
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/1016009/

CPU 的 TLB（Translation Lookaside Buffer）缓存了虚拟地址转换的结果，从而显著加速了内存访问。TLB 失效(miss) 的话会有高昂代价，因此人们投入了大量精力来尽可能高效地利用 TLB。在 2025 年 Linux 存储、文件系统、内存管理和 BPF 峰会上，Rik van Riel 的内存管理主题会议讨论了如何减少 TLB 的压力。会上考虑了一些方法，但没有得出确定的结论。

每当内核更改虚拟地址映射时，必须小心移除所有引用旧映射的 TLB 条目，否则内存访问最终可能会访问到错误的位置。这种 TLB 清除动作（invalidation）可能是一项代价高昂的操作，因为它可能需要向系统上的每个 CPU 发送处理器间中断（Inter-Processor Interrupts，IPI）。Van Riel 在会议开始时表示，他一直在优化 AMD CPU 上的 TLB invalidation，使用了一种专用指令来消除对 IPI 的需求；这项工作已经合并到 6.15 版本中。

他还一直在努力减少页面回收时所需的 TLB 刷新次数。他原本期望能看到不错的性能提升，但结果表明，这种优化几乎没有任何效果。通过更仔细地观察相关的工作负载，他发现每个 CPU 每秒大约发生 200 万次 TLB miss。这是一个拥有 200 个 CPU 的系统。因此，减少几千次 TLB invalidation 并没有太大帮助。

因此，他开始寻找更多使用透明大页（Transparent Huge Pages，THP）的方法。大页的一个优势是，一个 TLB 条目可以引用整个大页，从而大大增加 TLB 可以覆盖的地址空间量。但是，内存管理子系统面向的是 PMD 级别的大页，在许多系统上，PMD 级别的大页大小为 2MB；由于内部碎片，它们会产生更大的内存压力，从而抵消了它们提供的节省。不过，更新的 AMD 和 Arm CPU 可以合并较小组的物理连续页面的 TLB 条目。如果内核可以使用更多的多尺寸透明大页（multi-size Transparent Huge Pages，mTHP），则可以更好地利用此功能，并在减少内部碎片的同时获得更好的 TLB 利用率。

不幸的是，他说，内核现有的用于管理透明大页的机制（ khugepaged 线程和 huge-page shrinker）目前无法对 mTHP 做太多处理。依靠运气来创建 mTHP 是行不通的，尤其是在 Arm CPU 上，必须设置显式的页表条目 bit 才能启用合并。因此，内核需要学习创建 mTHP，并在必要时将较大的大页拆分为 mTHP。

目前有正在进行的工作来解决这些问题；会议期间提出了这些问题，但没有进行详细讨论。会议花了一些时间讨论 “max_pte_none” 问题（在链接提供的文章中有详细描述），该问题确定了在可以将多少个连续页面合并为一个大页之前必须使用它们。

Shakeel Butt 询问用户空间是否可以帮助解决此问题。Van Riel 回答说，开发人员可以考虑切换到不同的分配大小；将分配放在一起也有助于减少 TLB 失效。但是这是一个难题，因为像 malloc() 这样的函数不知道更高级别的代码将如何使用分配的内存。

一位听众指出，AMD 在没有显式页表条目位的情况下执行 TLB 合并的能力很好，但这仅在应用程序已访问 mTHP 中至少一半的页面时才有效。从这个细节中得出的更广泛的结论是，适用于一种架构甚至一代 CPU 的 mTHP 管理技术可能不适用于其他架构。

Matthew Wilcox 说，使用 mTHP 的最大好处是减少内核的最近最少使用（Least-Recently-Used，LRU）列表的大小。这可以减少执行回收时的锁持有时间，并大大减少总体争用。因此，即使没有 TLB 利用率的提高，使用更大的页面也是值得的。

讨论的最后一部分涉及与 mTHP 管理相关的许多细节。Ryan Roberts 指出，如果应用程序在 mTHP 的一部分上调用 madvise()，则必须从 TLB 中刷新整个 mTHP，这会带来很高的成本。在这种情况下，最好一开始就不创建 mTHP。Van Riel 建议内核可以观察用户空间正在做什么，如果发现大量 madvise() 调用或 mTHP 中未使用的页面，则做出相应的反应。Roberts 补充说，内核的写时复制（Copy-on-Write，COW）机制适用于单个页面，从而导致 mTHP 被拆分；最好研究在更大的页面组（folios）上执行 COW。同样，交换（swapping）也会拆分页面组，正如 Van Riel 补充说，这不是最佳的。当应用于更大的内存块时，像 zswap 这样的压缩交换机制更有效。

随着时间临近尾声，David Hildenbrand 指出，对于 AMD CPU，一系列页面的页表条目必须匹配才能进行 TLB 合并。他建议，也许需要更多地考虑如何设置这些位，以避免无意中阻止合并。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～