当前位置：首页>Linux>强如 Linux 内核,里面也塞满了“屎山”

强如 Linux 内核,里面也塞满了“屎山”

  • 2026-09-07 21:20:57
强如 Linux 内核,里面也塞满了“屎山”
很多人对 Linux 内核的印象停留在教科书式的优雅架构上，认为这里的每一行代码都是深思熟虑的杰作。但作为内核相关模块的维护者，我想用我每天都在面对的真实世界，来戳破这种完美的滤镜。
实话说，哪怕是在 Linux 内核的核心子系统里，也塞满了由于历史妥协而遗留下的代码包袱。只要稍微不注意，这些代码就会演变成谁也不想触碰的雷区。上周在内核邮件列表（LKML）里发生的一场讨论，恰好完整地展现了 HugeTLB 的屎山困境。

请停止对 HugeTLB 新增任何特性

在 2026 年 7 月的内存管理子系统（MM）邮件列表中，有开发者提交了一组补丁：
[RFC PATCH 0/6] mm/hugetlb: Dynamic, NUMA-aware HugePage Cache & Free Page Reporting
https://lore.kernel.org/linux-mm/20260707064235.1386552-1-souravpanda@google.com/
这组补丁的初衷很明确：为了解决云环境在大页内存（HugeTLB，特别是 1GB 巨大的 gigantic page）分配时的延迟问题，作者设计了一个动态的、具备 NUMA 感知的缓存机制，并结合了virtio-balloon的 Free Page Reporting 功能。
从业务和厂商的需求来看，这个优化完全是合理的。但负责核心 MM 的维护者 David Hildenbrand 很快给出了原则性的拒绝：
"In general, we consider hugetlb nowadays to be mostly in feature freeze..."（大意：目前我们普遍认为 HugeTLB 模块已经处于功能冻结状态，因为我们意识到，在整个 MM 子系统之上为这个本就特殊的模块添加更多的特殊逻辑，长期来看只会带来更严重的维护伤害。）
我是非常认同这个观点的，因为只有修改过这部分代码的人才知道，这个模块的内部现状到底有多让人头疼。

为什么说它是一个“平行宇宙”？

这组补丁的改动行数非常直观：
mm/hugetlb.c | 590 ++++++++++++++++++-
另一位 MM 核心维护者 Lorenzo Stoakes 在邮件里直言不讳地指出了问题所在。这接近 600 行的新增代码，本质上是在把hugetlb变得更加特殊。

为什么我们如此排斥这种“特殊化（Special casing）”？

hugetlb（大页内存fs）在内核里的历史太久了。由于早期的设计局限，它并没有很好地复用核心内存管理（Core MM）的基础设施，而是在内部实现了一套相对独立的逻辑。这意味着很多通用的内存操作，一旦遇到大页内存，就必须引入类似if (hugetlb) { ... }的判断。它就像是内核里的一个“国中国”，自己有一套平行的代码实现。
Lorenzo 在邮件中说了句很重但很真实的话：“Hugetlb 已经成为 MM 领域不良决策的典型代表。由于过去我们总是抱着‘就再加这一个功能’的心态，导致现在的维护成本极高。”
作为维护者，每天看着这坨复杂的历史代码，坦白讲我完全不想往里面再多看一眼，更不用说再去叠加新的特殊逻辑了。如果不加克制，任何一个小优化的加入，都会让未来的重构和维护变成彻底的灾难。

维护者的防守：重构是新功能的“入场券”

在讨论的后半段，负责虚拟化维护的 Michael S. Tsirkin 提出了一个很务实的问题：如果维护者觉得代码太特殊需要重构，那是不是应该给提交者提供一个高层面的重构设计方案？否则这么高的要求，提交者可能无从下手。
Lorenzo 的回应非常直接，也代表了开源顶级项目维护者的共同共识：
“重构的负担在于提交者，而不是维护者。维护者的拒绝并不意味着必须同时提供一个替代方案。”
这种态度听起来可能有些冷酷，但这是庞大软件工程里唯一的防守策略。
任何大型软件系统在缺乏克制的情况下都会走向无序。一个特殊功能的引入可能只需要几百行，但它带来的长尾维护成本、隐藏的 Corner case，最终都会由模块维护者和整个社区买单。当技术债累积到一定程度时，“功能冻结”是倒逼架构回归健康的唯一手段。
你想加入新特性？可以，代价是你必须先帮社区清理历史烂账，把原有的平行代码普通化（Ordinary），而不是继续在历史包袱上盖高楼。Lorenzo 提到他自己当时也在进行匿名反向映射（anon rmap）模块的重构，同样没有人给他写好指南。这才是真实的内核日常——大量的精力实际上是在做艰苦的去特化和重构，对抗系统演进中的熵增。

结语

软件工程往往是一门妥协的艺术。强如 Linux 内核，其内部也布满了前人为了快速解决问题而留下的“捷径”。但在项目走向成熟和庞大时，这些曾经的捷径往往会变成死代码和维护者的噩梦。
作为模块维护者，守住代码库的底线比盲目增加功能要重要得多。这也给所有的软件架构师和开发者带来了一个朴素的启示：多写几句判断、多搞一条特殊通道总是容易的；但如果不在架构层面保持克制，系统最终会被自己堆砌的功能所吞噬。保持项目的生命力，往往不在于我们“多做了什么”，而在于我们“克制了什么”。
最后，关于 HugeTLB后续的发展，其实社区的方向是非常明确的——那就是“去特殊化”与“去独立化”。我们的目标是逐步剥离它现有的平行宇宙，让它能够真正复用核心 MM 的基础设施，成为一个普通的内核公民。
正因如此，虽然我们拒绝了做加法的优化，但内核社区非常欢迎任何人对该模块进行重构。如果你能提出方案减少 HugeTLB的现有代码行数，或者能把它内部的特殊实现合理地合并回核心内存管理中，这是整个内核 MM 社区最希望看到并会全力支持的贡献。
本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：596563534@qq.com 。

Linux系统基础8:进程管理命令

300 条 Linux 命令汇总,新手入门直接收藏

最新文章

随机文章