LWN：关于内存管理部分开发流程的变动！

关注了就能看到更多这么棒的文章哦～

The state of memory-management development

By Jonathan Corbet
May 10, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/894378/

2022 年的 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM）是三年来 Linux 内存管理开发者第一次线下聚会。在第一天结束时由维护者 Andrew Morton 主持的会议上，这些开发者们讨论了内存管理的开发流程。虽然整体的管理结构仍将保持不变，但这里还是会有不少变动。

Morton 首先表示，他终于将他的部分工作流程转移到了 Git 上，这是他多年来一直在抗拒的一个变动。在 kernel.org 上将会有三个 git tree，用来存放目前正在开发的 patch。其中的 "hot fixes" tree 正如其名用来放置 hot fix，它针对不同版本会有不同的 branch，用来对 upstream 了的代码进行重要的 fix。"stable" tree 存放的是准备在下一个合并窗口进入 mainline 的内容，而 "unstable" 则用来放置那些不太成熟的内容。

所有这三个代码 tree 都会被直接混在一起形成 -mm tree，然后送入 linux-next。Morton 明确表示，他仍然会在自己的工作流程中尽可能多地使用 Quilt，他认为在某项工作仍在不断的变动的时候，使用 Quilt 会更加灵活。不过他也说过，"如果有必要"，他愿意从开发者的 Git 来做 pull，但他仍然认为这种模式不可行。他说，从来没有哪个 patch set 在通过 memory-management tree 的时候能够毫无改动的，所以 Git 的 immutable model 并不适合这里的情况。他说，他的管理政策将是 "stabilize forever"，一直到 patch 已经可以进入 stable tree，这时它们将被合并到一个 branch 之中然后等待 upstream。

unstable tree 目前只是作为一个 Quilt queue，尽管它最终也会采用 Git 的形式。当完成切换时（可能是在 5.19 周期），他不希望开发者使用这个 tree 来作为开发的基础。相反，所有的 patch 都应该是针对某一个 upstream 版本的，最好是 previous-rc3。每个 patch 一系列都会被保存在一个单独的 branch 中，即使只涉及一个 patch。这样一来显然会出现许多名字很长的 branch；它们将以 mm-unstable- 开始，并包含 patch 的 subject。他说，当开发者发送后续 patch 时，就需要提供目标 branch 的名称。

stable tree 是不可以改动的，意味着它永远也不会进行 rebase。他说，这是一个很好的想法，但只有在有内容可以放进去的情况下，它才能发挥作用。他一直在寻找有哪些内容可以放到这里，但目前还没有看到什么准备好的内容；一切都在等待 review 和/或 update。如果希望使这个过程发挥作用，开发者就需要更快地把内容确定下来。他计划更加积极地催促开发者，当然通常是在私下里进行，来帮助推动事情进展。

Stability and review

Michal Hocko 说，似乎有很多 patch 进入 -mm 树的时机都太早了。这导致开发者的注意力被转移到下一个看起来很耀眼的东西上。Morton 回答说，他已经开始忽略那些新的 patch 的第一个版本了，部分原因就是如此。但是，他补充说，任何认为合并到 -mm 就意味着他们的工作已经完成的人，都是没有经验的。他试图尽可能为这些人提供指导。

David Hildenbrand 建议 Morton 在接受 patch 进入-mm 之前就应该对其进行更多的 review；目前有很多带有破坏性的 patch 也进来了。他说，总的来说，社区生成代码的能力似乎远远大于 review 代码的能力。莫顿回答说，他不想因为缺乏 review 而阻止 patch 进入-mm；他宁可让这些工作能发布出来从而开始进行测试。但是，如果没有完成相应的 review，他是不会让这个工作继续走到 mainline 去的。

Dan Williams 建议，如果能做得更加透明的话就会更有帮助了；如果开发者可以看到 queue 的状态，以及哪些 patch 正在等待 review，他们可能会感到有动力去帮助推进。Morton 回答说，这些信息现在已经有了。但是，他确实是靠自己来决定是否将 patch 移到 stable tree 中的，他也希望改变这种情况。他认为这个决定应该更透明、更快地做出。目前，他的计划是公开发布他的计划，看看是否有反对意见；但他并不打算在将工作转移到 stable 版之前要去等待有明确的反对意见。

他希望看到更多的人关注走向 stable 的过渡，他说这是 "一件大事"。patch 不需要完美才能被推进 stable；毕竟，一般还有几个月的时间（包括了开发周期的剩余时间，以及 patch 合并后的下一个完整开发周期）来让事情达到 production quality。因此，他的标准是，Linux 是否想要这个 patch，以及它是否已经达到了往下走的基本条件。

Morton 对他是否应该发布 stable tree 提出了一些疑虑。他不希望开发者们以它为基础来做 patch，但如果这个 tree 被公布出来的话就肯定会诱使大家这么去做。

有提议说写一些文档（尤其是相应的判定标准）（尤其是标准）告知大家如何才能把 patch 合入 stable tree，但 Mel Gorman 建议不要这样做。如果公布了一套规则，开发者就会不可避免地试图利用这些规则。他还说，在 non-rebasing 模式下维护 stable tree 并不特别重要。memory-management patch 往往不怎么会发生 merge conflict，所以一般来说 rebase 不太可能给开发者带来问题，尤其是在开发周期的早期阶段。

然后谈到了另一个话题，Morton 说他实际上计划创建第四个 Git tree，其中会包含 kernel-wide patch。这个 tree 总是从 Quilt 队列中生成的，这里应该不会放跟 memory-management 有关的任何内容。Morton 仍然在处理其他子系统的许多 patch，所以很容易理解他为什么想要建立这个 tree。

Submaintainers

Hocko 提出了内存管理子系统中子维护者的问题。目前有几部分内容是由其他开发者的 Git tree 所处理的，而且经常会被直接推送到 mainline 上，这一点他不太满意。他说，这最终导致了内存管理子系统中的分裂，使人们很难对相关进展有完整的了解。他说，可能确实有必要来设立子维护者，但是他们的 tree 应该被拉到 -mm tree 里面。Morton 认为这个方案应该是可行的，他可能会把这些 tree 直接 pull 到 unstable tree 去。

Vlastimil Babka 问道，他的 git tree 里面包含了对 slab allocator 的修改，是否也应该通过-mm 来合入。Morton 回答说，目前的流程仍是有效的，Babka 应该还是直接向 Linus Torvalds 发送 pull request。他说，把他加进来也不会为这个过程增加任何价值。但他指出，slab patch 往往是独立于其他所有内容的。如果希望把内存管理部分的核心内容来分解成很多部分的话，反而会是一场噩梦。

不过，Hocko 指出，即使在内存管理子系统的核心代码中，各领域之间的 conflict 也很少。也许值得让更多的子维护者来负责相应的领域。Morton 表示愿意尝试一下，看看是否比目前的流程更有效，但他说他想等目前的变动稳定一段时间。Hildenbrand 补充说，新的开发者往往不知道该把内存管理的 patch 发到哪里，而 get_maintainer.pl 脚本给出的结果在这一点上经常也没有什么帮助。定义子维护者可能会在这方面有所帮助。他自告奋勇来承担 memory hotplug 的 submaintainer 这一角色。

此时天色已晚，与会者们都很疲惫了。大家在一些细节上还有一些讨论，之后会议很快就结束了。

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

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～