HMM讨论纪要

原文网址：https://lwn.net/Articles/636301/

原文题目：Heterogeneous memory management

原文作者：Jonathan Corbet

原文时间：2015年3月13日

异构内存管理

Glisse在LSFMM2015会议内存管理分论坛“首次”提到异构内存管理HMM概念。Glisse认为，最近几年CPU对内存带宽增长的需求正在放缓：这主要是因为需要更多内存带宽的应用负载并不多，应用负载缺乏追求更快运行的动力；相对而言，CPU访问模型呈现随机性，访问延迟往往是影响应用负载性能的决定因素。

与CPU不一样，为了获得更高的计算性能，GPU被设计成可以支持成千上万的硬件线程；GPU对内存带宽的需求是CPU的几十倍。即使这样，为了追求更快的运算性能，GPU仍然可以将内存带宽撑满。

最近越来越多的CPU芯片内部直接包含了GPU，CPU和GPU访问相同的物理内存。在游戏引擎加速、用户界面渲染等方面，GPU发挥作用。在这样的系统上，绝大部分内存带宽被GPU占用。

HMM代码的作用是：CPU和GPU可以共享相同的物理内存和相同的地址空间；除了GPU之外，也可以用于其他访存的外设。在GPU运行上的软件行为和在CPU类似：访存时需要页表，也会触发页故障等等。

HMM机制会管理每个内存块的所属权，避免CPU和GPU对内存块的竞态（并行）访问。为了保证在任意时刻只有一方能访问内存块，HMM提供了在CPU和GPU之间的内存迁移方法。如果CPU访问了当前属于GPU的内存块就会触发页故障；随后页故障处理程序将该内存块迁移回来，CPU就可以继续访问。

上述功能要求在CPU和GPU之间实现页表同步；CPU这端采用MMU notifier回调方法。只要内存块的状态改变了，CPU就会将相应的页表项设置为失效。这里还存在一个问题：为了确保正确运行，notifier需要支持休眠模式，但是当前的MMU notifier实现还不支持。这也是该补丁至今还未被接纳的原因。

Andrew Morton则担心这种系统能否获得推广普及。他说，GPU发展很快，如果HMM代码一定要纳入Linux进行维护的话，五年后很可能没人再用HMM代码。Glisse则相信，从长远来看，这种系统对GPU、数字信号处理器等设备有好处，能够获得推广普及。

Glisse最后发言说，为了让GPU对应用编程完全透明就需要支持HMM机制。除了HMM机制，编译器还要能够对运行在GPU上循环代码进行向量化，这样应用编程才能做到完全不需要GPU相关知识。

Rik van Riel问小组是否还有关于HMM代码的问题要讨论。Mel Gorman问，有多少人真正阅读过补丁；其实没有多少人阅读过。Rik看过老版本的补丁，没有发现实质性问题。Andrew提醒说，大部分人还没有审阅HMM代码，这就意味着并没有多少用户期待HMM机制。

分论坛最后零散地讨论了一下HMM机制的细节。例如，如何将匿名页迁移到设备端？回答：设备看上去就像一个特殊的、交换类型的文件。这里需要修改fork()函数，即让所有相关的内存块在一开始就必须全部迁移到CPU端。只有CPU端将相关物理内存页映射成只读属性，设备端才能对内存块进行原子访问；后续CPU写访问就会触发写故障，写故障就采用类似“写时拷贝”（copy-on-write）故障的方式进行处理。如果HMM系统能支持文件后备页（file-backed pages：这些内存页被换出时，是换出到文件上而不是交换分区上），那就非常棒；这要在页缓存中创建专门类型的数据结构。这就会引发和MMU notifier类似的问题：文件系统一般都要求以原子操作方式查询页缓存，这要求代码支持休眠。还不清楚该如何解决这个问题。会上还提到，HMM机制需要对每种文件系统进行相应的修改，这似乎也不太妙。