Fast Kernel Headers, a set of patches that speed up kernel compilation by 50-80%

Ingo Molnar, a well known Linux kernel developer and author of CFS Task Scheduler proposed for the Linux kernel development mailing list discussion a number of patches, affecting more than half of all files in the kernel source and providing an overall kernel rebuild speed increase of 50 -80% depending on the configuration.

The optimization implemented is notable in that it is associated with the addition of the largest changeset in the history of kernel development: they set out to include 2297 patches at once, changing more than 25 thousand files.

Performance gain is achieved by changing the header file handling method. It should be noted that during thirty years of kernel development, the state of the header files has taken on a dismal shape due to the presence of a large number of cross-dependencies between files.

The restructuring of the header files took over a year and required a significant redesign of the hierarchy and dependencies. During the restructuring, work was done to separate the type definitions and APIs for the different kernel subsystems.

I am pleased to announce the first public version of my new "Fast Kernel Headers" project that I have been working on since late 2020, which is a comprehensive reworking of the Linux kernel header hierarchy and header dependencies, with double aim of :

- speed up kernel build (both absolute and incremental build times)

- type decoupling of subsystem and definitions API from each other

As most kernel developers know, there are around ~ 10,000 main .h headers in the Linux kernel, in the include / and arch / * / include / hierarchies. Over the last 30+ years, they have evolved into a complicated and painful set of cross-dependencies that we affectionately call 'Dependency Hell'.

Among the changes made are: separation of high-level header files from each other, exclusion of inline functions linking header files, mapping of header files for types and APIs, provision of a separate set of header files (about 80 files had indirect dependencies that interfere with assembly, exposed through other files header files), automatic addition of dependencies to ".h" and ".c" files, step-by-step optimization of header files, use of the "CONFIG_KALLSYMS_FAST = y" mode, selective consolidation of C files into assembly blocks for reduce the number of object files.

As a result, the work done allowed to reduce the size of the processed header filesin the post-preprocessing stage by 1-2 orders of magnitude.

  • For example, before optimization, using the header file "linux / gfp.h" resulted in the addition of 13543 lines of code and the inclusion of 303 dependent header files, and after optimization the size was reduced to 181 lines and 26 dependent files.
  • Another example: preprocessing the unpatched "kernel / pid.c" file connects 94 thousand lines of code, most of which are not used in pid.c. Splitting the header files allowed us to reduce the amount of code processed three times, reducing the number of lines processed to 36.

When the kernel was completely rebuilt with the "make -j96 vmlinux" command on the test system, the patching showed a reduction in compile time of the v5.16-rc7 branch from 231,34 to 129,97, 15,5 seconds (from 27,7 to XNUMX builds per hour) and also increased the efficiency of CPU core usage during build.

With an incremental compilation, the optimization effect is even more noticeable: the time to rebuild the kernel after making changes to the header files has been significantly reduced (from 112% to 173%, depending on the header file that is changed) .

Optimizations are currently only available for ARM64, MIPS, Sparc, and x86 (32-bit and 64-bit) architectures.

Finely if you are interested in knowing more about it, you can check the details in the following link


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.