内核配置文件在哪个目录_Linux内核的构建速度很快就会提高50%到80%

来源：Linux内核构建速度即将提升50%至80% - CNX中文网

根据我最近对 ​​GTi 11 迷你电脑的评测，在配备 16 GB RAM 和快速 SSD 的 Intel Core i5 Lake 迷你电脑上构建 Linux 内核（不包括模块）大约需要 5 分钟。在此过程中，内核开发人员可能必须针对不同的目标和配置以及所有模块进行构建，因此实际构建时间可能会增加。虽然可以通过投资更多硬件来加快内核构建速度，但如果您可以“直接通过软件优化实现更快的构建速度”，那也是一件好事。

这其实就是 Linux 内核调度模块负责人 Ingo 自 2020 年底以来一直在做的事情。他的“Fast ”旨在消除 Linux 内核中的地狱问题。他最初提出时的目标是将速度提高 20%，但一年多后的今天，成果令人惊叹。根据目标平台（x86-64、arm64 等）和配置的不同，Linux 内核的构建速度提高了 50% 到 80%。

构建更快的 Linux 内核

这其实是一项非常艰巨的任务，该项目由 25 个内部子树组成，有超过 2200 段代码需要提交，您可以通过以下方式获取：

前往“CNX中文站”官网查看完整信息

Ingo 还详细解释了为什么减少头文件依赖如此困难，需要如此多的代码提交。解释如下：

大多数内核开发人员都知道，Linux 内核的 / 和 arch/*// 层次结构中大约有 10,000 个主要的 .h 头文件。在过去 30 多年里，它们已经发展成为一组复杂的交叉依赖关系，我们亲切地称之为“地狱”。

我在 2020 年底启动这个项目的时候，就预测会有 50-100 个 patch，当时也做了一些粗略的测量，发现通过减少头文件依赖，可以提升 20% 左右的编译速度，而且对内核的运行影响不大，这似乎足以证明 50-100 个代码提交是合理的。

随着补丁数量的增加，我看到的性能提升有限。然而，到 2021 年年中，我在这个分支中已经提交了 500 多次，所以我不得不放弃第二次尝试 (!)。这两种解决方案都是不可扩展、不可维护的，而且只带来了微不足道的 4% 的构建速度提升。不值得用 500 个补丁弄乱整个项目，甚至不值得告诉公众。

在第三次尝试时，我引入了 () 机制，它提供了灵活性，可以大幅减少依赖项，这是一种提高可维护性的类型清理方法。使用这种方法似乎并没有让情况变得更好，即使在 1,000 次提交后，我的构建速度也没有提高 10%。此时，我仍然觉得这不是我可以推动上游甚至公开宣布的事情。

但这次尝试提供的数据确实非常清晰，让我感觉 20% 的性能提升还是非常有可能的。所以我一直在开发这个分支，在 2021 年秋季提交了 1500 多段代码之后，我发现大部分加速比开始显现。当加速比超过 20% 甚至更多的时候，我其实非常惊讶。然后，我在参考配置中达到了目前 78% 的加速比。

事实上，一旦依赖项的数量减少到最低限度，内核构建开销就会明显线性改善。

你可能会认为内核维护人员会对接受大量补丁持谨慎态度，但 Greg KH 的反馈是积极的，尽管他也警告了潜在的维护问题：

这很“有趣”，但您如何在将来保持 /sched/_defs.h 和定义同步？似乎您需要手动创建它（这对于测试非常有用）。但从长远来看，通过“手动决定需要在这里做什么”来保持一切正常工作将是一件痛苦的事。

除此之外，我再次查看了这个分支。总体而言，它看起来会更好地清理之前复杂的依赖关系。其中大部分可能会经过各种子系统树，一旦您将它们拆分，就应该可以清理“主”.h 文件。我想知道您是否打算这样做？

关于维护人员将如何进行清理的讨论仍在进行中。让我们来看看数据：

前往“CNX中文站”官网查看完整信息

通过快速头文件优化，Linux 5.16-rc7 的完整构建时间从 231 秒缩短至 130 秒，速度提高了约 78%。您可能认为这只对总是从头开始构建内核的人有用，但实际上，增量构建从头文件清理中获益颇多：

前往“CNX中文站”官网查看完整信息

构建速度提升了 173%。提升的主要原因是“关键内核头文件的有效后预处理大小”大幅减少，下面列出了其中一些：

前往“CNX中文站”官网查看完整信息

上面的 LOC 是代码行数，可以看到使用 fast--v1 选项后 LOC 值大幅减少。“”列也是如此，表示间接包含的头文件数量。支持的平台包括 x86 32 位和 64 位（启动测试和主机）、ARM64（启动测试）、MIPS 32 位和 64 位以及 Sparc 32 位和 64 位。不过这些平台目前还只是在构建阶段，尚未在实际硬件上进行测试。

事实上这些测试结果确实令人印象深刻，如果将Fast code 合并到上游代码中，可以延长现有build farm的生命周期，并在一定程度上加快Linux开发进程。