LWN: Linux内存管理代码合入的工作流程

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

The memory-management subsystem development process

By Jonathan Corbet
May 7, 2019

---

LSFMM

在2019 Linux Storage, Filesystem, and Memory-Management Summit上，内核子系统维护者Andrew Morton跟大家讨论了开发流程的状态。这次的会议上看起来memory-management相关的开发者大多都对现在的工作流程感到满意，不过还是有一些小地方希望能够继续改进。其中一些问题是老问题了，很难处理好，其他也有一些能够短期见效的建议被提出来。

Morton首先提醒与会者，2018年的development-process会议中已经达成一致意见，所有的memory-management相关的patch都需要先通过review，然后才能合入upstream上游代码。他认为这个目标已经很容易的达成了。大多数的review反馈都是很不错的，当然也有一些稍差。不过，他提了一个问题，大家觉得review整体来说是有帮助吗？在座者的回答很明确“Yes”。Aneesh Kumar指出，因为坚持需要review才能合入的规则，就让开发者有更多压力来推动review进展。Morton也希望各位管理者能够让相应的developer花更多时间来帮助进行patch review。

此时，Mel Gorman引出了一段长篇大论，阐述他的看法。他认为memory-management subsystem里面的patch review并不是每次都能达到目的。举例来说，开发者有时候贴出一些很复杂的patch set改动，却没有讲述清楚这样改动的理由。review者指出这一点之后，下一版的patch却变得更加复杂。Memory management这个子系统不能用一个非黑即白的判断来简单评判代码改动，这里的改动会对整个系统有全方位的影响，可是很多patch作者却只提供了一些极少的数据来证明这个改动有益。

Gorman同时指出，有些大家认为非常重要的fix patch，有时候会被拒绝合入，可能只是因为有一位反对者，就阻止了它的合入。其他子系统的维护者可能会对这种patch直接下结论一定需要合入，不过在memory management子系统，这种情况可能会让patch拖很长时间无法合入。他提到删除legacy block layer的那次改动，经过了几轮讨论，当时仍有反对意见，不过作者都提供了解释，最终维护者直接合入了这组改动，Gorman觉得这个行为是正确的。

而memory-management这部分的patch review就跟这个不太一致了。例如，在讨论回退掉Andrea Arcangeli的修复transparement huge page分配的性能问题的patch的时候，就应该更果断一点结束讨论。最终这组patch因为“一位开发者提出的一个大家未能复现出来的场景”而被revert了。他的结论是，有时候必须要推动工作前进。假如一直等着争议自己解决，那么永远没法推进。

Michal Hocko提出了一个长久以来一直存在的问题：写patch的人一直比读patch的人多。Johannes Weiner问这个是否导致了质量问题。Hocko认为是肯定的，memory management子系统里面有某些部分比其他部分的问题更加多。Gorman认为除了memory-management子系统以外，其他很多模块都有这个问题，也确实会影响质量，不过大家别认为这只是memory-management子系统独有的问题。Morton希望开发者后面碰到这类问题的时候能提醒他注意。Gorman说只要某些人在某些邮件讨论中出现后快速fix了一些东西，然后又消失了，那就说明一般有什么东西出错了。

Morton介绍道，在传统的kernel maintainer模式下，maintainer（维护者）通常都是在一个patch set的开发后期、快要结束的时候才介入。maintainer的任务就是来确保这个patch能合入upstream上游分支。一般来说patch打入maintainer的git仓库之后就不会改变了。不过Morton没有采用这种工作方式，他经常在早期介入，来帮助开发者能把他们的工作做的更完美一些。他的-mm代码树是开发过程的一部分，而不是开发的终点。这种模式大家觉得好还是不好？

Vlastimil Babka指出开发者们通常并没有意识到-mm代码库是按照这种模式工作的。他们觉得只要合入了-mm库，工作就结束了。Morton的回答是他现在也尽量不要那么早参与了，很多patch set的第一版他就不看了。Hocko介绍，他作为reviewer的时候，某个patch set如果后来有fix被合入-mm库的话，他有可能意识不到这个后续改动。他认为这是一个大问题，会导致一些不合适的代码被合入。这就是这种early merge策略会导致的一个负面影响，他更希望开发者能发送一个新版本的patch set，解决了问题之后再进行合入。

Gorman觉得这种early merging的策略既有好处也有局限性。它会让开发者在linux-next上工作感到更加困难，因为linux-next分支包含很多尚未完善的代码。Gorman自己的patch通常都会提供很多数据来支持，不过那些数据都是基于mainline的kernel来测试得到的，如果是在-mm库上测试的话，这个数据可能会有很大区别，会导致他需要把所有测试工作全部重做一遍。他觉得，如果-mm代码库能有几个topic branch供开发者工作，那就太好了。这个观点得到了会场的广泛赞同。Hocko觉得memory-management子系统的各个不同部分应该用不同的代码分支来开发，-mm代码库现在作为唯一一个分支容易有各种错误。其他子系统也有的在开发流程中加入更多冗余备份，他认为这个也有借鉴价值。

Mortan觉得如果大家直接基于mainline开展工作，并且也能正常的进行工作，那他也没有异议。不过，Gorman指出，很难确认-mm代码库里的哪些patch会在近期合入upstream。这个可以通过在-mm这里增加几个标准的分支来改善，开发者们就能比较清楚下一个merge window会是大概什么样子（哪些patch会得到合入）。

会议结束时间差不多到了，大家迫不及待要去吃大餐了，Babka还指出大多数maintainer都会在他们的pull request里面写一个详细的总结，不过-mm仓库上没有这么做。我也觉得这是个问题。Morton承诺他会想办法改善，然后结束了会议。

全文完

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

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

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