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

Dueling memory-management performance regressions

By Jonathan Corbet
June 14, 2019

在2019 Linux Storage, Filesystem, and Memory-Management Summit上曾经有过热烈讨论，关于memory-management部分针对一个performance下降问题进行了fix，不过却同时导致了另一个问题。当时这个fix已经马上被revert（从代码库回退）掉了，不过大多数memory-management相关的开发者还是觉得那个fix是正确的。Andrea Arcangeli在五月初又提交了一个patch set，在上个月的时候一直有一些讨论。现在Andrew Morton（Memory-management子系统的maintainer）正在面临一个选择：究竟应该牺牲哪个方向的performance？

问题出现在transparent huge page和NUMA policy两者的配合上。自从Aneesh Kumar在2015年的patch合入后，kernel对那些采用madvise(MADV_HUGEPAGE)配置过的内存区域会尽量从当前的NUMA node上分配huge page（巨页）。目前看来，kernel可能这里有点用力过猛，会在这个NUMA node上触发大量内存回收和整理，甚至哪怕其他node上有空闲内存的情况下，也仍然会把当前node的一些在用page给强制换出。因此根据这个行为，事实上来说，对一块内存区域打开transparent huge page设置，变成了把这块memory给绑定到某个特定的NUMA node上。很多开发者都观察到这个行为会导致swap爆发大量的换入换出操作，从而极大的降低系统性能。

为了fix这个问题，2018年11月Arcangeli提供了一个patch，让这个绑定到当前NUMA node的行为不要那么暴力。不过，有一些任务确实是需要绑定到当前node的。当前node的huge page比起其他node上的huge page要有更好的performance，甚至本地的小page也比远端的huge page性能好。某些任务测试下来，用其他node上的page导致的性能损失非常巨大，因此相关开发者宁可经过大量的swap操作，也要是用本地的huge page。因此上述patch在2018年12月份被David Rientjes回退掉了。

现在的问题是，swap storm影响到的用户非常多，而用其他node导致性能下降影响到的用户少很多。swap storm也更加容易被注意到。因此很多发行版又把原来的Patch打上来了（reverted the revert），因此他们的kernel跟mainline kernel行为很不一样。随着时间的推移，越来越多的人觉得应该避免大量swap，要把Arcangeli的patch再重新打回来，宁可牺牲local huge page的benefit。

不过，并不是所有人都赞同。Rientjes就强烈建议保留local huge page的优势。他认为所有人都在绕回原点，事情的根源在于之前设计API的时候没有给用户程序一个机会来设置是否会分散在多个socket上。已经有3年多的时间，userspace开发者都在根据当前的行为来开发软件，不应该随意改变kernel API的语义和行为。他认为应该增加一个prctl()系统调用，能让application来明确指定说它的workload可以分散在多个NUMA node上。等这个API出现之后，kernel就能针对性的分配huge page了。同时application也能由更多权限来控制NUMA分配huge page的behavior。

原则上来说，大家赞同他说的，API需要被改进。不过正如Morten指出：“实现一套新的API对当前正在受罪的userspace没有什么帮助，而这个patch能有帮助”。他看起来也希望能优先解决swap-storm的问题，后面再慢慢来满足application的其他需求（例如指定必须要用local huge page）.

Rientjes很坚定的认为当前API的行为应该保持原样。并且他也在想些办法能修改内存分配功能的实现代码来改善这个行为，主要是让内存回收在某些情况下（就是回收了也帮助不大的情况下）不用推进的那么极致。Michal Hocko担心这种改动会让transparent huge-page的分配效率变低，并且，修改分配机制本身并没有解决这个问题的根源：根本原因是MADV_HUGEPAGE设计时没有仔细检查，跟NUMA的行为绑定起来，并且引入了副作用导致madvise对大多数场景下都无法达到原始目的。

大家其实希望Rientjes能够贴出来一个例子证明Arcangeli的fix会让性能下降。他倒是提到过“让node本地的memory碎片化，调用MADV_HUGEPAGE对一大块区域配置huge page，测量随机访问的latency”，不过大家并没有被说服。

没有一个实际有效的测试标杆，其他开发者就没法知道他们的方案会对系统有什么影响，或者导致的到底是个大问题还是仅仅是个小问题。Hocko就认为kernel的NUMA balance机制可能会对本来分配在其他NUMA node上的memory进行平衡，重新调整到local node。不过没人能证明这一点。因此Mel Gorman抱怨道：“真的很奇葩啊，你觉得让用户每天都碰到swap storm是件小事，而一直在等待一个无法复现的问题被某些没人实现的memory policy给fix掉”。

Gorman提议对zone_reclaim_mode的sysctl knob增加一个bit，按照类似Rientjes的建议来解决这个问题，就是缺省情况下关闭这个配置，但是对某些特殊workload打开。Rientjes还没有回复他的看法。

很多参与讨论的人都看出来了，这个讨论已经在不断循环了。除了Rientjes之外，没有其他memory-management的开发者站出来帮他说话。讨论中似乎已经初步达成共识要把Arcangeli的patch再打回来。不过如果合入了mainline，今后又有用户抱怨performance有下降的话，很可能导致这个patch被再次revert，因为kernel有一个很严格的“no regression”（性能不能下降）的规则。大家都不想看到这个情况，因此一直在尽量了解清楚情况，找出一个让大家都满意的方案。不过memory management一直都是一个需要不断寻求平衡点的工作。目前没有一个明确的合适测试方法，大家都像在黑暗中摸索寻找方向，这种情况找到平衡点就更加困难了。这么说来，似乎更加应该把这个fix patch再打上去，毕竟已经在多个发行版里面测试过一段时间、并且也确实fix了明确的问题了。

全文完

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

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

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