Kbuild-Patches für Linux 7.4 verkürzen Kernel-Builds

Eine Patch-Serie, die den Linux-Kernel-Build beschleunigt, erreichte am 18. September 2026 ihre dritte Fassung und zielt nun auf Linux 7.4. Der Arm-Ingenieur Lorenzo Stoakes schrieb sie, nachdem er ein großes Sprachmodell eingesetzt hatte, um Zeitfresser im Build zu finden. Das gemessene Ergebnis ist ein Build, der deutlich weniger Zeit auf einem einzelnen CPU-Kern wartet, während die übrigen stillstehen.

Das Problem benennt das Anschreiben der Patch-Serie direkt: Ein typischer Kernel-Build verbringt frustrierend viel Zeit in Engpässen, die nur einen Thread nutzen. Moderne Maschinen haben viele Kerne. Der Kernel-Build übergab mehrere seiner Schritte weiterhin nur einem davon.

Wohin die Zeit ging

Die Arbeit berührt die Teile des Builds, die die meisten Entwickler nie ansehen. Kbuild ist das make-basierte System, das alles steuert. Kallsyms baut die Tabelle, die Kernel-Adressen auf Symbolnamen abbildet. Modpost prüft Modul-Metadaten, objtool validiert den erzeugten Code, und mksysmap schreibt die Symbolkarte. Auch der Rust-Build-Pfad wurde geändert.

Ein Teil der Verschwendung war schlicht Masse. Das Anschreiben hält fest, dass ein moderner x86-64-Kernel rund 158.000 Symbole hat, sodass ein Durchlauf Millionen Iterationen ausführt. Es verweist außerdem auf 5.810 unnötige Modul-Info-Einträge bei einem x86-defconfig-Build und 15.200 bei arm64. Eine erzeugte Assembler-Datei erreichte 37 MiB und brauchte 0,57 Sekunden zum Assemblieren, zwei- bis dreimal pro Build.

Die Zahlen, und wie sie sich unterscheiden

Messung	Vorher	Nachher
No-op-Build x86 allmodconfig	11,6s	2,4s
No-op-Build x86 allmodconfig, zweite Konfiguration	11,0s	1,9s
Sauberer Build x86 allmodconfig	342,1s	304,5s
Kallsyms-Kompression mit CONFIG_KALLSYMS_ALL	0,59s	0,33s

Diese Werte stammen aus der veröffentlichten Serie, die 23 Patches umfasste, als Stoakes sie am 8. September 2026 verschickte. Die dritte Fassung, über die Phoronix am 18. September berichtete, umfasst 20 Patches, neu aufgesetzt auf aktuellem Upstream-Code, mit Messungen auf AMD EPYC, Threadripper und Apple M2. Phoronix gab den No-op-Gewinn auf dem Apple M2 mit 74 bis 76 Prozent an und nannte das Ergebnis "in einer ähnlichen Größenordnung wie die AMD-x86_64-Zahlen".

Die Schlagzeilen-Prozente unterscheiden sich zwischen beiden Berichten. Phoronix beschrieb am 8. September vollständige Builds mit allen Modulen als etwa 36 Prozent schneller, inkrementelle Builds als bis zu 70 Prozent schneller und No-op-Builds als rund 90 Prozent schneller. Die Serie selbst nennt 79 bis 82 Prozent für No-op-Builds und 11 Prozent für einen sauberen allmodconfig-Build. Die Differenz erklärt sich durch verschiedene Maschinen, Konfigurationen und Fassungen. Nehmen Sie daher die Spanne als ehrliche Antwort, nicht eine einzelne Zahl. Unsere Berichterstattung über den Stable-Kernel-Schwung mit 9.000 Patches zeigte die andere Seite desselben Baums: viel Code, der sich oft bewegt.

Ein LLM fand es, ein Mensch lieferte es aus

Stoakes war deutlich, wie die Arbeit entstand. "Ein LLM wurde eingesetzt, um zuerst die Engpässe zu bestimmen und dann herauszufinden, wie man sie verbessert", schrieb er. Sein Urteil über das Ergebnis fällt weniger freundlich aus: "Es hat viel Code erzeugt, vieles davon scheußlich." Er sagt, er habe vieles geprüft und neu geschrieben und die Commit-Nachrichten stark überarbeitet. Jeder Commit trägt einen "Assisted-by"-Vermerk, der die Unterstützung benennt.

Die Serie hält außerdem fest, dass die erzeugte Ausgabe Byte für Byte identisch mit der des alten Codes geprüft wurde. Das ist die entscheidende Kontrolle für ein Build-System, denn ein schnellerer Build, der einen anderen Kernel erzeugt, ist kein schnellerer Build.

Was das für Entwickler bedeutet

Wer regelmäßig Kernel kompiliert, achtet auf den No-op-Fall. Das ist der Build nach der Änderung einer Datei oder nach gar keiner Änderung, und dort liegen laut Serie die größten Gewinne. Diese Minuten fallen bei jedem Durchlauf einer Debug-Schleife an.

Warten Sie das Einpflegen ab, statt die Patches jetzt anzuwenden. Sie zielen auf Linux 7.4, und ein Rebase auf Ihren Baum ist nach dem Merge die bessere Zeitinvestition. Wer CI betreibt, die Kernel baut, beachtet: Der Gewinn beim sauberen allmodconfig-Build ist mit rund 11 Prozent der kleinere.

Die Prozessgeschichte verdient eigene Aufmerksamkeit. Hier ging maschinell vorgeschlagene Optimierung durch menschliche Prüfung, Byte-für-Byte-Verifikation und einen ausdrücklichen Vermerk. Diese Kombination macht einen solchen Patch überhaupt prüfbar.