21CTO导读：Linux内核的编译时间正在加速提高性能，最新的Kbuild优化补丁在高端服务器上将标准内核编译压缩至约15秒，下一步预计在10秒之内完成。详情请看本文。

对于从未经历过内核编译的人来说，编译时间本身可能意义不大。但对于 Linux 社区而言，编译时间长期以来一直是衡量硬件和工具发展程度的非正式指标。将干净的编译时间缩短到个位数，这种成果的影响力远远超出了内核邮件列表的范围。

是什么让 Linux 内核编译时间大幅缩短？

这里面有两个技术因素在朝着同一个方向推动。

硬件方面，现代桌面处理器现在拥有数十个核心和线程，内核构建的并行化能力极强，因为在最终链接阶段之前，可以独立编译数千个源文件。再加上高速 NVMe 存储和充足的内存用于缓存，如今构建系统的原始吞吐量远超五年前发烧友所能达到的水平。

更有意思的部分在于软件方面。

编译器工具链已经开始整合人工智能辅助优化，以便更智能地决定代码的内部结构，例如内联、寄存器分配和指令调度。

在过去，这些决策完全依赖于编译器工程师手动编写的启发式算法。而现在，通过引入数据驱动或机器学习引导的模型（LLVM 等项目已经探索过这种方法），编译器可以更快地做出更优的调用，从而直接缩短编译时间。

此次性能提升之所以引人注目，是因为它并非通过捷径实现的。一些发烧友会通过将编译过程直接写入 RAM 磁盘来加速编译，从而完全避免磁盘延迟。这种方法虽然合法，但多少有些人为，目的是为了追求更快的速度。而此次最新的性能提升，将编译时间缩短了近三分之一，是通过真正优化编译流程本身的效率来实现的，这意味着即使在普通存储设备上，这种优势也应该能够保持。

为什么内核编译时间对发烧友来说一直很重要

自从 20 世纪 90 年代以来，从源代码编译 Linux 内核一直是用户学习过程中的一个重要环节。当时，在当时的硬件条件下，完整编译可能需要几个小时。

伴随着 CPU 核心数的增加，以及LLVM 和 Ninja 等编译器项目等构建工具在并行处理方面日趋成熟，编译时间缩短到了几分钟，之后对于配置较高的机器甚至可以缩短到几十秒。每一次时间的缩短，都如同秒表一般，记录着消费级计算的发展历程。

这不仅是为了炫耀，更是一个实际问题的真正解决。

内核开发者在测试补丁、排查漏洞或验证驱动程序变更时，需要不断地重新构建内核。发行版维护者和自定义内核构建者，包括那些为游戏掌机或特定硬件优化内核的开发者，都会定期运行完整构建，作为其工作流程的一部分。每次构建节省的每一秒，都会在每天数百次的迭代中累积成巨大的优势。

15秒到底是个什么水平？

此次测试用的是非常强大的服务器。

测试机器搭载了两颗 AMD EPYC 9575F 处理器，每颗拥有 64 个核心，因此整机提供 128 个 CPU 核心和 256 个线程，同时配备 1.5TB DDR5-6400 内存以及 3.84TB PCIe 5.0 NVMe SSD，系统运行 Ubuntu 26.04 LTS。

值得注意的是，这次测试没有使用 RAMDisk 来人为压榨存储性能，而是直接使用 PCIe 5.0 SSD 完成编译。最终，最新 Kbuild 补丁将标准 defconfig 内核构建时间从 22 秒左右降低到了约 15 秒。

当然，这并不意味着普通笔记本电脑现在也可以 15 秒编译 Linux 内核。测试成绩高度依赖 CPU 核心数量、内存带宽、存储性能以及编译任务的并行程度。

不过这项工作的意义在于，软件优化本身也能够让不同档次的处理器获得收益。它并不是只服务于最顶级的服务器。

更大的内核也开始接近两分钟

如果只是编译一个比较精简的默认内核配置，15 秒已经相当惊人。但 Linux 内核还存在一个更加极端的测试方式，也就是 allmodconfig。

这个配置会启用大量内核模块和驱动，编译量远高于普通 defconfig。

在同一套 EPYC 服务器上，最新补丁让 allmodconfig 的编译时间从约 169 秒降低到了 134 秒，直接减少了 35 秒，已经逐渐接近两分钟以内。

对于普通 Linux 桌面用户来说，这个数字可能只是一个有趣的性能测试，但对于内核开发者、发行版维护者以及大规模构建环境来说，意义完全不同。

内核开发经常需要反复修改代码、编译、测试，再继续修改。如果每次构建都需要等待较长时间，那么整个开发周期就会被不断拉长。编译时间缩短以后，同样的时间里可以完成更多测试，也能让问题定位和回归测试更加高效。

然而 15 秒并非是终点。

测试人员已经把目光放到了下一代 AMD EPYC 平台。随着 Zen 6 架构处理器、MRDIMM 高带宽内存以及 PCIe 6.0 存储设备逐渐进入市场，再结合 Kbuild 后续优化，标准 x86-64 Linux 内核 defconfig 编译突破 10 秒已被认为存在现实之可能。

如果在性能强大的硬件上，内核编译的耗时真的能缩短到 10 秒以内，那么内核开发人员的反馈循环将会更加高效、更快的迭代，也意味着 bug 能更快被发现，补丁在提交前能得到更彻底的测试，内核开发的整体速度也能略微提升，因为等待时间是软件工程中为数不多的真正浪费的资源之一。

它还对更广泛的 Linux 生态系统具有连锁效应。构建自定义内核的发行版维护者、针对特定硬件进行优化的游戏 Linux 项目以及尝试内核配置的爱好者都能从中受益。而且，这一切都不需要特殊的设备；这些改进已经融入主流编译器和构建系统代码中，因此应该能够惠及所有使用较新桌面 CPU 的用户，而不仅仅局限于高端工作站。

这里还蕴含着更广泛的信号。人工智能辅助优化正越来越多地出现在开发者工具本身，而不仅仅局限于那些炫目的消费级产品。编译器、构建系统乃至调试工具都开始吸收机器学习技术，从而对日常工程任务进行渐进式但切实有效的改进。

而Linux的内核编译时间，恰好是这一趋势在公共领域中一个格外明显且易于衡量的实例典范。

作者：场长