如何加快 Linux 内核编译速度？答案

【问题标题】：How to speed up Linux kernel compilation?如何加快 Linux 内核编译速度？
【发布时间】：2014-06-10 08:16:56
【问题描述】：

我有核心 i5 和 8GB RAM。我的机器上安装了 VMware 工作站 10.0.1。我在 VMware 上安装了 fedora 20 Desktop Edition 作为客户操作系统。

我正在研究 Linux 内核源代码 v 3.14.1。我正在为 Linux 内核开发一个 I/O 调度程序。每次对代码进行任何修改后，编译和安装整个内核代码大约需要 1 小时 30 分钟才能看到更改。

编译和安装命令： make menuconfig, make, make modules, make modules_install, make install

所以我的问题是可以将 1 小时 30 分钟的时间缩短到 10 到 15 分钟吗？

【问题讨论】：

有一个鲜为人知的menu gconfig 比make menuconfig 更方便得令人难以置信
我建议获得更多的 RAM，因为这会使事情变得更快。如果您拥有超快的 SSD（例如 Intel Optane），则差异不会那么大。我建议内核开发人员至少使用 16 GB，尤其是在您使用虚拟机的情况下。我不清楚您是在主机还是虚拟客户端上编译代码，但无论什么机器进行编译都需要有大量 RAM 才能始终将所有文件保存在 RAM 中。如果你有足够的资源，你也应该了解distcc和ccache。
也值得一试：make localconfig 而不是 make menuconfig，以尽量减少您正在构建的模块和功能的数量。
这是一篇文章，它给出了大约 90 秒而不是 90 分钟的构建时间：nickdesaulniers.github.io/blog/2018/06/02/… - 不过，该文章并未制作模块。

标签： linux time compilation kernel

【解决方案1】：

不要为您对源代码所做的每一项更改都执行make menuconfig，因为它会触发对所有内容的完整编译，无论您的更改多么微不足道。仅当内核的配置选项发生更改时才需要这样做，并且在您的开发过程中不应该发生这种情况。

只要做：

make

或者如果您更喜欢并行编译：

make -j4

或您喜欢的任何数量的并发任务。

当然，部署最近构建的二进制文件可能需要make install 等。

另一个技巧是将内核配置为测试所需的最低限度。我发现对于许多任务，UML 编译（用户模式 Linux）是最快的。您可能还会发现有用的 make localmodconfig 而不是 make menuconfig。

【讨论】：

-j 参数应该是核心数的 1.5 倍
使用机器中的CPU核心数+1往往可以达到最好的效果；例如，使用 2 核处理器运行 make -j3
我通常使用make -j$(( $(nproc) * 2 )) 并传递 CFLAGS 选项，如 mtune=native、march=native、O3、fno-plt、pipe 等，以使内核更快。它被证明可以产生更好的二进制文件。在我的 intel i3 haswell 3.5 GHz 桌面处理器上，使用 GCC 10.2.0 完成编译大约需要 1 小时。不过对于 Xanmod 和 liquix 内核，编译时间不少于 2 个半小时...
@noɥʇʎԀʎzɐɹƆ 我不知道你是如何得出这个乘数的，但它对我来说效果很好。

【解决方案2】：

使用make 并行构建和-j 选项
仅为目标架构编译，否则 make 将为每个列出的架构构建内核。

即例如，而不是运行：

make

运行：

make ARCH=<your architecture> -jN

其中N 是您机器上的核心数（cat /proc/cpuinfo 列出核心数）。例如，对于i386 目标和主机，4 cores（cat /proc/cpuinfo 的输出）：

make ARCH=i386 -j4

同样，您可以使用 -jN 标志运行其他 make 目标（modules、modules_install、install）。

注意：make 会检查已修改的文件并仅编译已修改的文件，因此只有初始构建需要时间，后续构建会更快。

【讨论】：

抱歉，我对内核有点陌生，所以请您详细说明“make ARCH= -jN”。是的，你是对的，只编译修改后的代码大约需要 10 分钟，但“make modules_install”命令需要大约 45 分钟来制作 .ko 文件。请问有cmets吗？
说如果目标机器是i386并且你的机器有4 cores，那么你可以运行你的make为：make ARCH=i386 -j4。
make ARCH=$(arch) -j$(nproc) 一般

【解决方案3】：

您无需在每次进行更改时再次运行make menuconfig — 创建内核.config 文件只需要一次。（或者，如果您编辑 Kconfig 文件以添加或修改配置选项，也可能再次发生，但这当然不应该经常发生。）

只要您的.config 不受影响，运行make 应该只重新编译您更改的文件。有几个文件每次都必须编译，但绝大多数不是。

【讨论】：

感谢您的 cmets。正如你所说，只运行一次“make menuconfig”。没关系。显然，每次更改代码后都会运行“make”命令。但是每次代码更改后是否还需要运行“make modules”、“make modules_install”和“make install”才能看到我的更改？
make modules 构建模块，make modules_install 将模块安装到它们的默认目录 /lib/{your-kernel-version-name}/modules 和 make install “安装”新内核，就像将压缩的内核映像复制到默认位置，通常是 /boot/ 以及 System.map 和 .config 文件。因此，回到您的问题，如果您对模块进行了一些更改，那肯定是需要的。由于您显然正在使用调度程序，您很可能使用核心内核，因此无需执行make modules，因为它不会做任何事情

【解决方案4】：

make -j 将使用所有可用的 CPU。

【讨论】：

它产生数百个编译器进程并且系统冻结
关于原始答案：利用所有可用的cpu内核：make -j$(nproc)
@garritfra 手册页上写着If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously. 所以猜这意味着使用所有cpu。
你是对的，它没有。但同时这意味着它不受内核数量的限制，因此它会不断产生进程，从而冻结您的系统。

【解决方案5】：

ccache 应该能够显着加快您的编译时间。它通过缓存以前的编译并检测何时再次完成相同的编译来加速重新编译。由于需要填充缓存，因此使用 ccache 进行的第一次编译会比较慢，但后续构建应该会快得多。

如果你不想对 ccache 配置大惊小怪，你可以像这样运行它来编译内核：

ccache make

【讨论】：

有趣，我不知道可以像这样使用ccache 而不是更常见的make CC='ccache gcc'：stackoverflow.com/questions/9757436/how-to-use-ccache-with-make/… 我在一个仅打印@987654326 的最小示例上进行了尝试@ 并且它指向 /usr/bin/cc 所以它似乎没有被使用。您能否提供一个显示此作品的最小示例或一些支持它的文档？

【解决方案6】：

也许除了前面的建议之外，使用 ccache 软件 (https://ccache.samba.org/) 和 SSD 驱动器上的编译目录应该会大大减少编译时间。

【讨论】：

【解决方案7】：

如果您有足够的 RAM，并且在构建内核时您不会使用您的机器，您可以生成大量并发作业。但请确保您的 RAM 足够，否则您的系统会挂起并崩溃。

【讨论】：

【解决方案8】：

也许除了前面的建议之外，在使用 ccache 时，您可能希望取消设置 CONFIG_GCC_PLUGINS（如果已设置），否则您可能会遇到很多缓存未命中，如 this 示例所示。

【讨论】：

这应该是评论而不是答案。
@L_J 我希望，但需要 50 个代表发表评论:(

【解决方案9】：

使用这个命令：

sudo make -j 4 && sudo make modules_install -j 4 && sudo make install -j 4

其中 4 是我分配给这个过程的核心数量。

Credits

【讨论】：

【解决方案10】：

简单的技巧。如果您不使用自己的机器或有另一台机器，您可以完全注销并使用 CTRL + ALT + F* 切换到 TTY 终端。一切都快得多。

【讨论】：

除非您的登录环境在后台运行了一些要求不合理的应用程序，或者您的内存量过小，否则这不会让任何事情“快得多”。
@Bracken gnome-shell 是一个“要求很高的应用程序”。这就是它起作用的原因，先检查一下......
Gnome shell 要求不高，它只占用我系统 CPU 时间和内存的一小部分。这就是为什么这对编译时间没有明显影响的原因。如果你的 shell 使用了大量资源，那么要么你有问题，要么你的机器比树莓派弱。
@Bracken 把 gnome shell 放在一边。这是一个示例，实际上是普通桌面上要求苛刻的应用程序。我谈到了一般的注销，它会卸载很多应用程序和系统的东西，并且肯定会加速内核编译。祝你好运。