Los parches kbuild de Linux 7.4 acortan las compilaciones

Una serie de parches que acelera la compilación del kernel de Linux llegó a su tercera revisión el 18 de septiembre de 2026 y ahora apunta a Linux 7.4. El ingeniero de Arm Lorenzo Stoakes la escribió tras usar un modelo de lenguaje grande para encontrar dónde pierde tiempo la compilación. El resultado medido es una compilación que pasa mucho menos tiempo esperando a un solo núcleo mientras el resto está ocioso.

El problema que ataca la serie está dicho con claridad en la carta de presentación de los parches: una compilación típica del kernel pasa una cantidad frustrante de tiempo atascada en cuellos de botella de un solo hilo. Las máquinas actuales tienen muchos núcleos. La compilación del kernel seguía entregando varios de sus pasos a uno solo.

Dónde se iba el tiempo

El trabajo toca las partes de la compilación que casi nadie mira. Kbuild es el sistema basado en make que dirige todo. Kallsyms construye la tabla que asocia direcciones del kernel con nombres de símbolos. Modpost revisa los metadatos de los módulos, objtool valida el código generado y mksysmap escribe el mapa de símbolos. La ruta de compilación de Rust también cambió.

Parte del desperdicio era simple volumen. La carta señala que un kernel x86-64 actual tiene cerca de 158.000 símbolos, así que un recorrido ejecuta millones de iteraciones. También apunta a 5.810 entradas innecesarias de información de módulo en una compilación x86 defconfig, y 15.200 en arm64. Un archivo de ensamblador generado llegó a 37 MiB y tardaba 0,57 segundos en ensamblarse, dos o tres veces por compilación.

Los números y sus diferencias

Medición	Antes	Después
Compilación sin cambios x86 allmodconfig	11,6s	2,4s
Compilación sin cambios x86 allmodconfig, otra configuración	11,0s	1,9s
Compilación limpia x86 allmodconfig	342,1s	304,5s
Compresión de kallsyms con CONFIG_KALLSYMS_ALL	0,59s	0,33s

Esas cifras vienen de la serie publicada, que tenía 23 parches cuando Stoakes la envió el 8 de septiembre de 2026. La tercera revisión que reportó Phoronix el 18 de septiembre tiene 20 parches, reajustados sobre el código upstream actual, con resultados tomados en máquinas AMD EPYC, Threadripper y Apple M2. Phoronix situó la mejora sin cambios en Apple M2 entre 74 y 76 por ciento y llamó al resultado "de un orden similar al de las cifras de AMD x86_64".

Los porcentajes de titular difieren entre ambos reportes. La cobertura de Phoronix del 8 de septiembre describía las compilaciones completas con todos los módulos como un 36 % más rápidas, las incrementales hasta un 70 % más rápidas y las compilaciones sin cambios cerca de un 90 % más rápidas. La propia serie informa de 79 a 82 por ciento en compilaciones sin cambios y de 11 % en una compilación allmodconfig limpia. La diferencia refleja máquinas, configuraciones y revisiones distintas, así que tome el rango como la respuesta honesta en lugar de una sola cifra. Nuestra cobertura del lote de kernels estables con 9.000 parches mostró la otra cara del mismo árbol: mucho código moviéndose, y a menudo.

Lo encontró un LLM, lo entregó una persona

Stoakes ha sido directo sobre cómo se produjo el trabajo. "Se usó un LLM primero para determinar dónde estaban los cuellos de botella y luego para averiguar cómo mejorarlos", escribió. Su valoración del resultado es menos halagadora: "Generó mucho código, buena parte de él horrendo." Dice que auditó y reescribió buena parte, y que editó mucho los mensajes de commit. Cada commit lleva una nota "Assisted-by" que nombra esa asistencia.

La serie también indica que la salida generada se verificó idéntica byte a byte a la que producía el código anterior. Esa es la comprobación que importa en un sistema de compilación, porque una compilación más rápida que produce un kernel distinto no es una compilación más rápida.

Qué significa esto para los desarrolladores

Si compila kernels con frecuencia, el caso sin cambios es el que importa. Es la compilación que ejecuta tras cambiar un archivo, o sin cambiar nada, y es donde la serie reclama sus mayores mejoras. Esos minutos caen en cada vuelta de un ciclo de depuración.

Espere a que la serie entre en lugar de aplicarla ahora. Apunta a Linux 7.4, y reajustarla sobre su árbol será mejor uso del tiempo una vez integrada. Si mantiene una CI que compila kernels, note que la mejora en la compilación limpia allmodconfig es la menor, cerca del 11 %.

La historia del proceso merece atención propia. Aquí una optimización sugerida por una máquina pasó por revisión humana, verificación byte a byte y una nota explícita. Esa combinación es lo que hace revisable un parche así.