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

原文题目：Heterogeneous memory management

原文作者：Jonathan Corbet

原文时间：2016年4月27日

异构内存管理

在大多数系统上，中央处理器CPU并不是唯一存在的处理器；实际上，这个CPU也不是系统中计算最快的部件。一些外接设备，尤其是图形处理器GPU，也可以启动大量的计算任务（我们称这样的处理器为异构处理器）。这些计算任务都要访问系统主存，因此要在CPU和其他处理器之间完全共享内存，这里显然要面临很多挑战。HMM子系统旨在实现这种共享机制；Glisse在2016 Linux存储、文件系统和内存管理会议的内存管理分论坛上开启了关于HMM的讨论。

Glisse介绍了HMM关键特征，【mirror a process’s address space within the attached processor】当中央处理器上运行异构计算（CDUA/OpenCL计算）的进程时，GPU等异构处理器的页表项设置应该与中央处理器上当前进程页表项保持一致（仅仅是地址部分）。这样一来，在中央处理器上软件栈就不需要实现用户态内存分配器。从硬件角度来看，已经有两项相关的技术：一项是PowerPC CAPI接口技术；另一项是基于PCIe总线的PASID机制。从软件角度来看，也存在两种选择：将CPU页表直接镜像给异构处理器（如何理解？可以理解为共享一份页表吗？）；或者将页表在CPU和异构处理器之间进行迁移。无论采用什么样的技术，最终希望提供给用户空间的API接口都一样。

Glisse接着说道，关注HMM是因为业界已经有硬件产品，并重点提到Mellanox和NVIDIA两家产品。这两家产品的设备驱动也做好了，现在这些硬件产品的价格虽然还比较昂贵，但几年后就会便宜。如果我们不能提供内核级解决方案，异构计算系统的运行就会比较慢，也需要PIN住更多的内存（PIN住内存：在内存访问之前，就分配好了物理内存，并将其和虚拟地址之间建立映射关系；而且被PIN住的内存不会被换出到交换分区，一直到内存被主动释放）。现在的方法需要在相应的设备驱动中增加MMU notifiers，每款设备驱动都要做修改；没人愿意这样做。这样一来，OpenCL只能被某些集成的GPU支持。最好能在内核级支持这个功能。Glisse说，我们最好尽可能在内核级实现HMM方案（感觉：在这之前的是设备驱动级方案）。

上述问题的解决方案就是HMM补丁集，给内存管理任务提供了简单的驱动API（感觉：这个API是在内核级实现的，供驱动程序调用的API）。这个补丁集可以将CPU页表直接镜像给异构处理器，并且确保在CPU端内存状态发生变化时保持页表同步。页表可以在CPU和异构处理器之间迁移；已经从CPU端迁移出去的页被标注为一个特殊的交换类型的表项（即表征被交换出的状态的页表项）——换句话说，这个页看上去已经被交换出了。HMM还处理了异构处理器的DMA映射（感觉：异构处理器要访问这些被交换出去的页，在正确访问之前，也需要处理好这些页相关的页表项）。

Andrew Morton提到补丁代码量太大了，合并到主流内核中比较困难。有人提议将补丁集分成若干个可被接受的小块；有些补丁对KVM虚拟化有明显好处。Andrew告诉Glisse要给潜在用户准备好相关文档。Andrew接着说“it's a matter of getting off our asses and reviewing the code.”他解释道，使用MMU notifiers可能有点麻烦，因为Linus不喜欢这种方式。

总体来说，对HMM核心思想没有异议。HMM代码也已经开发了好几年了；也越来越接近被主版本内核接受了。