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