LWN：NVIDIA在追求能一次分配1GB的连续内存空间

点击上方蓝色字关注我们~

Improving access to physically contiguous memory

By Jonathan Corbet
May 8, 2019

---

LSFMM

一直以来，内核开发者都尽量避免分配大块的物理连续内存，因为系统运行一段时间之后内存碎片化了，就很难分配得出大块物理连续的内存空间了。不过，在2019 Linux Storage, Filesystem, and Memory-Management Summit上，Zi Yan指出，分配连续内存有时候还是必要的，如何能让这种类型的分配更容易成功呢？

Yan讲到有很多种场景里面都是需要分配物理连续内存的。如果利用huge page（2MB）或者gigantic page（1GB）的话，能够通过提高CPU TLB（translation lookaside buffer）的利用率来改善系统性能。还有一些高带宽的外设也想要用物理连续内存，这些外设也都有TLB会希望提高利用效率。每次TLB miss的时候，都需要去重新做一次page table的解析，通常外设做TLB解析的速度比起CPU更加慢得多。

目前有三种方法可以分配大块连续的物理内存。一种是通过libhugetlbfs虚拟文件系统，这种需要在Linux启动阶段就扣除这部分内存区域。用户可能拿不到最合适的size，并且在kernel里面没有API能够通过libhugetlbfs来分配内存。第二种方法是transparent huge pages（透明巨页），可是没有解决碎片化问题因此需要经常对系统内存做整理，并且它依赖于kernel的buddy allocator分配机制，也就是说能分到的最大的buffer size受MAX_ORDER（一般系统里设置为11，意味着最大就是2048个4K page）限制。这样它完全没法提供gigantic pages所需的空间。第三种方法是利用alloc_contig_range()函数，这是CMA内存分配器提供的函数，不过这个机制在user space无法使用。

Dave Hansen指出libhugetlbfs现在能在系统启动之后再进行resize了，也就是一个主要缺陷现在已经不存在了。Andrea Arcangeli认为如果能从libhugtlbfs来分配到transparent huge pages的话会非常有用，这个可能也不难实现。看起来这里真正的问题，并不是分配大块内存的能力，而是这个分配会花费多少时间。因为想要获得这种大块连续内存的话，可能总是绕不过对碎片化的内存先进行compaction。还有一些开发者争论如何才能快速分配一些更高order的内存，不过没有结论。

Mel Gorman认为大块内存分配时候的latency是一个老问题了，kernel此前在碰到这种情况的时候，可能会出现几秒钟的卡顿，不过那是很久以前的事情了。需要先有人调查清楚当前最新kernel里面是什么情况，否则我们讨论的可能只是一个假想问题。Transparent huge pages在kernel 3.0之后已经经过几次大改动了，网上搜集到的信息可能都是针对老版本的实现，不一定符合当前最新kernel的情况。所以有人如果碰到在分配大块内存的时候有长延迟的情况，应该仔细调查一下系统环境，打开tracepoints，把测试结果报告出来，当然是要用最新版本的kernel测试的情况。

不过Yan还没有讲完。他也带来了一个方案，希望能在内存被分配之后减少VMA（virtual memory area）的碎片化。希望能找到一些配对的page能够交换内容，这样来改善系统表现。这个方案跟内核的khugepaged线程还不一样，会在原地址来做defgrament，而不是分配另一个huge page来把数据搬移过去。这个page-exchange（page交换）的主意让在场的很多开发者非常惊讶，因为这个翻案可能会非常复杂。Yan认为，这种方案的优势在于它不需要再额外分配新的page，而两个互相交换内容的page会通过CPU的寄存器来做copy和交还。

Gorman问这里人们为什么需要避免分配临时page，Yan的回答是对大page来说是有价值的，不过在场的开发者没有被说服。然后Gorman问性能数据的时候，Yan回答说这个data exchange要比简单搬移两个page要快，不过不清楚为什么。Hansen问，这个改动最后到底解决了什么问题，Yan指出用这个方案，就能在不修改内核MAX_ORDER参数的情况下获得一个1GB gigantic page。与会者也没有被这个好处说服。目前的CPU对gigantic pages有tiny TLB，此前没有人提供性能数据证明用这种方案的性能优势。

Yan（他是NVIDIA员工）跟在场的另一位NVIDIA开发者讨论了一段时间，看起来NVIDIA可能希望用1GB page来在某些未来产品里面提升性能。不过他们目前目前没法提供关于这个这个未来产品的更多细节，因此kernel开发者也没有兴趣支持这个需求。

最终，这个议题结束了，Gorman的结论是目前没有必要实现这个机制，khugepaged已经足够了。如果kernel的page-migration执行的太慢了，那么大家应该想办法改善它，而不是绕过它。例如目前还没有人来帮助实现migration的批量化操作。

全文完

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

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～