原文网址:HMM (Heterogeneous Memory Management) [LWN.net]
邮件ID:1457469802-11850-1-git-send-email-jglisse@redhat.com
邮件作者:Jerome Glisse
邮件时间:2016年5月8日
HMM补丁提交说明书
上次我给Linus和Andrew讲到过,将HMM补丁提交到上游社区的需求是,我们希望无论闭源驱动还是开源驱动,除了Mellanox之外HMM还能获得其他真实硬件支持(当前Mellanox还没有采用HMM所有特性)。开源驱动的相关工作正在开展中,我估计NVIDIA和第三方很快就会有更新。
现在我重新提交是因为我希望大家能有时间重新审查HMM代码。在新硬件发布之前,开源驱动在窗口关闭之前不会更新(窗口/门:我理解为主线接纳补丁的时间窗口)。如果有人需要,我可以请上游维护者介绍相关进展情况(应该是指上游社区接纳HMM代码的进展情况)。
诸如IBM和Mediatek等第三方对HMM也很感兴趣。我期待他们能从各自硬件角度出发对HMM做点评。
我希望,HMM很快被上游接纳。
这次提交的HMM补丁版本基本上和上次提交的一样。补丁代码在(现在已经没有了)git://people.freedesktop.org/~glisse/linux hmm-v12 branch。
HMM是设备驱动的帮助层,主要特点是:
——按照设备专用格式,创建一个进程CPU页表的影子页表,并保持CPU页表和影子页表的同步(理解:影子页表其实就是GPU页表)。
——根据影子页表的页表项,替设备处理好DMA所需的系统内存的映射工作。
——将私有匿名内存迁移到私有设备内存上,并处理CPU页故障(CPU页故障又会将页重新迁回到系统主存上,这样CPU才可以访问了)
HMM的优点:
——设备驱动不再需要PIN住内存页,否则内核很多其他特性(内核共享内存KSM、迁移等)都不能用。
——对已有的、不使用HMM的工作场景没有影响(在通用代码路径上增加了两个if条件执行)。
——可以为更广泛的硬件提供通用框架。
——应用程序员编程不再需要手动管理系统主存和设备内存之间的数据拷贝。
——用户空间透明化,例如,库函数使用GPU,而应用程序不需要直接链接GPU。
HMM的动机?
OpenCL2.0和其他GPU计算API要求,可以对进程地址空间做镜像。OpenCL2.0允许各种级别API的实现,当前Linux仅仅支持最低两级的API实现。更高级别API的实现要求,CPU和GPU能并行访问数据,而且要保证缓存一致性,因此我们提出HMM机制,还有其他类似功能被提出,例如通过平台硬件。
但是基于PCIe总线 的ATS/PASID硬件方案,在实现系统内存镜像方面有局限性,还不能将内存迁移到设备内存中(因为这对带宽需求量很大,几乎是现在“独立GPU+常规系统主存”的10倍带宽需求量;而且这对延迟也有要求,要低于PCIe总线延迟)。
AMD、Intel在处理器芯片内部集成了GPU,并采用了ATS/PASID技术,Intel还专门实现了大量的、特殊的快速缓存,专门用作缓存池。
将来依然以独立GPU为主流,因为与集成GPU相比,独立GPU配有更多、更快的设备内存。
我们相信,HMM机制会让应用程序透明访问独立GPU内存,同时对Linux内核内存管理代码修改最小。而且HMM可以和硬件方案一起工作:常规情况让ATS/PASID来处理,而HMM专门处理页迁移。
设计:
补丁1/2/3/4主要是MMU notifier API,能有效地更新CPU页表镜像。
补丁5到14是HMM的主要工作,实现进程地址空间镜像。这里用到第二个页表,HMM将设备需要使用的内存做镜像。HMM本身并不访问任何页,它用MMU notifier API来记录CPU页表的修改,以及更新镜像页表。HMM仅仅是提供简单的API给设备驱动程序。文章来源:https://www.toymoban.com/news/detail-493569.html
为此,我们采用通用页表而不是基数树(radix tree基数树:是将指针与long整数键值相关联的机制,它存储有效率,并且可以快速查询,用于指针与整数值的映射、内存管理等),因为我们需要记录更多的标记,而基数树满足不了这个需求,例如dma地址(在一些平台上long类型长度小于dma_addr_t类型长度)。文章来源地址https://www.toymoban.com/news/detail-493569.html
到了这里,关于HMM补丁说明2016的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!