Patches kbuild do Linux 7.4 encurtam a compilação do kernel

Uma série de patches que acelera a compilação do kernel Linux chegou à terceira revisão em 18 de setembro de 2026 e agora mira o Linux 7.4. O engenheiro da Arm Lorenzo Stoakes a escreveu depois de usar um modelo de linguagem grande para achar onde a compilação perde tempo. O resultado medido é uma compilação que passa bem menos tempo esperando um único núcleo enquanto os demais ficam parados.

O problema que a série ataca está dito com clareza na carta de apresentação dos patches: uma compilação típica do kernel passa um tempo frustrante presa em gargalos de uma única thread. As máquinas de hoje têm muitos núcleos. Ainda assim, a compilação do kernel continuava entregando várias de suas etapas a apenas um deles.

Para onde ia o tempo

O trabalho toca as partes da compilação que a maioria dos desenvolvedores nunca olha. O kbuild é o sistema baseado em make que conduz tudo. O kallsyms monta a tabela que liga endereços do kernel a nomes de símbolos. O modpost confere os metadados dos módulos, o objtool valida o código gerado e o mksysmap escreve o mapa de símbolos. O caminho de compilação do Rust também mudou.

Parte do desperdício era simples volume. A carta observa que um kernel x86-64 atual guarda cerca de 158.000 símbolos, então uma passagem executa milhões de iterações. Ela também aponta 5.810 entradas desnecessárias de informação de módulo numa compilação x86 defconfig, e 15.200 no arm64. Um arquivo de assembly gerado chegou a 37 MiB e levava 0,57 segundo para ser montado, duas a três vezes por compilação.

Os números e suas diferenças

Medição	Antes	Depois
Compilação sem mudanças x86 allmodconfig	11,6s	2,4s
Compilação sem mudanças x86 allmodconfig, outra configuração	11,0s	1,9s
Compilação limpa x86 allmodconfig	342,1s	304,5s
Compressão do kallsyms com CONFIG_KALLSYMS_ALL	0,59s	0,33s

Esses números vêm da série publicada, que tinha 23 patches quando Stoakes a enviou em 8 de setembro de 2026. A terceira revisão relatada pela Phoronix em 18 de setembro tem 20 patches, reaplicados sobre o código upstream atual, com resultados colhidos em máquinas AMD EPYC, Threadripper e Apple M2. A Phoronix colocou o ganho sem mudanças no Apple M2 entre 74 e 76 por cento e chamou o resultado de "na mesma faixa dos números da AMD x86_64".

Os percentuais de destaque diferem entre os dois relatos. A cobertura da Phoronix de 8 de setembro descrevia compilações completas com todos os módulos como cerca de 36% mais rápidas, compilações incrementais até 70% mais rápidas e compilações sem mudanças cerca de 90% mais rápidas. A própria série relata 79 a 82 por cento para compilações sem mudanças e 11% para uma compilação allmodconfig limpa. A diferença reflete máquinas, configurações e revisões distintas, então trate a faixa como a resposta honesta, em vez de um número único. Nossa cobertura do lote de kernels estáveis com 9.000 patches mostrou o outro lado da mesma árvore: muito código se movendo, e com frequência.

Um LLM achou, uma pessoa entregou

Stoakes foi direto sobre como o trabalho foi produzido. "Um LLM foi usado primeiro para determinar onde estavam os gargalos e depois para descobrir como melhorá-los", escreveu. Sua avaliação do resultado é menos elogiosa: "Ele gerou muito código, boa parte dele horrendo." Ele diz ter auditado e reescrito boa parte, além de editar bastante as mensagens de commit. Cada commit leva uma nota "Assisted-by" que nomeia essa assistência.

A série também afirma que a saída gerada foi verificada como idêntica byte a byte à do código antigo. Essa é a checagem que importa em um sistema de compilação, porque uma compilação mais rápida que produz um kernel diferente não é uma compilação mais rápida.

O que isso significa para desenvolvedores

Se você compila kernels com frequência, o caso sem mudanças é o que importa. É a compilação que você roda depois de alterar um arquivo, ou sem alterar nada, e é onde a série reivindica os maiores ganhos. Esses minutos aparecem a cada volta de um ciclo de depuração.

Espere a série ser integrada em vez de aplicá-la agora. Ela mira o Linux 7.4, e reaplicá-la na sua árvore será um uso melhor do tempo depois do merge. Se você mantém uma CI que compila kernels, note que o ganho na compilação limpa allmodconfig é o menor, em torno de 11%.

A história do processo merece atenção própria. Aqui uma otimização sugerida por máquina passou por revisão humana, verificação byte a byte e uma nota explícita. É essa combinação que torna um patch assim revisável.