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搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章