LWN：针对direct-map碎片的解决方案！

最新推荐文章于 2024-09-25 10:59:43 发布

LinuxNews搬运工

最新推荐文章于 2024-09-25 10:59:43 发布

阅读量204

点赞数

文章标签： java python linux 大数据编程语言

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

版权

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

Solutions for direct-map fragmentation

By Jonathan Corbet
May 12, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/894557/

内核的 "direct map" 机制使一个系统的全部物理内存都可以在内核的虚拟地址空间中使用。通常情况下，会使用 huge page 来做这种映射，这使得访问 direct map 的时候更加高效。但是，越来越多的人需要从 direct map 中分割出一些 page；这就把这些 huge page 给打散了，使得整个系统的效率降低。在 2022 年 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM）的内存管理会议上，Mike Rapoport 主持了一个关于 direct-map fragmentation 以及如何避免这种碎片的会议。

Rapoport 首先说，direct map fragmentation 问题目前只在 x86 架构上有需要。因为其他一些架构根本无法对 direct map 进行打碎使用。很多事件会导致 direct map fragmentation，比如 BPF program 的分配，各种秘密的内存机制（https://lwn.net/Articles/865256/ ），以及像 SNP 和 TDX 这些虚拟化技术。未来预计还会有，包括 permission vmalloc() API 以及使用 protection keys supervisor (PKS) 来保护 page table，这都会使事情变得更糟。随着更多的子系统从 direct map 中分割出一些碎片区域，系统的性能就会下降；这需要尽量避免。

Rapoport 的建议是将这些不同的用途都汇聚到一个独立的内存区域中，从而尽量减少它们所产生的碎片。一旦一个 huge page 被分割出来使用了，那么后续就应该尽可能把接下来的对这类内存请求都用这一个 huge page 来满足。为此，他建议新增一个 GFP flag（__GFP_UNMAPPED），这样一来，就可以使用通常的 page allocator 调用来获取到已经从 direct map 区域中删除掉的内存。使用这个 flag 的代码就需要自己按他们的需求来对这部分内存进行 map。还有新增一个迁移类型（MIGRATE_UNMAPPED）将被添加，以避免这些内存意外地迁移回 direct map 的内存中。他已经发布了一组 patch set，按照这个想法实现了此原型。他说，这个补丁 "基本可以用"。

Michal Hocko 说，使用 page allocator 可能不是最好的方法。因为这会给极少数情况下的那些已经进行过极致优化的快速路径增加了额外开销。Mel Gorman 同意，使用 page allocator 应该算是矫枉过正，为单个使用场景创造了一个特殊情况。他补充说，Rapoport 增加了一个单独的迁移类型，这最终会导致内存碎片化，因为这些 page 不能被移动了。Rapoport 回答说，在一个长期运行的机器中，direct map fragmentation 是不可避免的，于是 Gorman 回答说，他不希望看到在 page allocator 上增加额外复杂性来解决一个仍然会发生的问题。

Rapoport 说，一个替代方案是在 page allocator 之外设立一个并行的分配机制。在这种情况下，每个用户都会有自己的 cache，这个方案不太有吸引力。但是 Gorman 回答说，迁移类型（migration type）也不是没有开销的；每个新增的迁移类型都会增加一组链表，并增加了 page-block bitmap 的 size。他说更好的解决方案可能是使用一个专门 slab cache。

David Hildenbrand 说，在他进行 memory hotplug 工作时，他讨厌那些不可移动的内存；Rapoport 的提案将创造出更多的不可移动的内存，使问题变得更糟。Rapoport 说，他的 patch 在进行 unmapped allocation 时会尽量避免使用 movable zone，这应该会使影响最小化。不过，Hocko 重申，page allocator 并不是进行这种分配的最佳场所；用户对内存分配过程会 "在乎每一个 CPU cycle"，在那里增加任何额外开销都是不受欢迎的。他说，最好是在 page allocator 的基础上建立一个类似 slab allocator 的机制。

在会议结束时，Rapoport 说，他将尝试创建某种类似 slab 的解决方案。Vlastimil Babka 提醒说，现有的 slab allocator 无法用于 BPF 程序。slab allocator 发放出来的对象都是有一样的 size 的，但每个 BPF 程序都希望有差异。Rapoport 最后说，他不确定如何解决所有的问题，但会很快进行尝试。

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

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

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