Sérii patchů, která zrychluje sestavení jádra Linuxu, psal vývojář s jazykovým modelem

Kdo někdy překládal jádro Linuxu, zná to čekání. Desítky jader se na chvíli rozběhnou naplno, pak se všechno zastaví a jediný proces v jediném vlákně přerovnává seznam symbolů. Lorenzo Stoakes, vývojář ARM a dlouholetý přispěvatel jádra, poslal 8. září do konference linux-kbuild sérii dvaceti tří patchů, které tahle místa rozpouštějí. Druhá verze, o dva patche kratší, přišla 14. září.

Šest míst, kde se čekalo

Série sahá na kbuild, kallsyms, modpost, objtool, mksysmap a na sestavení rustové části stromu. Recept je pokaždé jeden ze dvou: rozdělit práci mezi vlákna, nebo jí udělat míň.

Nástroj kallsyms, který do jádra zapisuje tabulku jmen funkcí, si dosud nechával symboly vypsat programem nm a výstup pak třídil; nově čte tabulku symbolů z ELF souboru přímo. Modpost psal pro každý modul soubor <modul>.mod.c a ten se překládal jako kterýkoli jiný céčkový zdroj. Teď z modpostu vypadne rovnou assembler .mod.S a podle popisu patche na to padne desetkrát míň procesorového času. Kbuild dostal vlastní nástroj depcheck na porovnávání časových značek závislostí, protože právě v tom make u rozsáhlejších adresářových stromů trávil přes sekundu v jednom vlákně.

Nejjednodušší je poslední patch série. Když je v systému pigz, tedy paralelní implementace gzipu, použije se místo programu gzip. Zabalit 36 MiB velký vmlinux.bin trvalo na Threadripperu se 128 vlákny příkazem gzip -9 1,6 sekundy, s pigz 0,09 sekundy. U modulů se pigz drží na jednom vlákně, protože ty už make komprimuje po jednom na úlohu.

Naměřené časy

Stoakes měřil na třech strojích: na AMD Threadripperu 9980X se 64 jádry, na dvouprocesorovém serveru s EPYC 9754 s 256 jádry a na MacBooku Pro s čipem M2 z roku 2022. Tohle jsou čísla z druhé verze pro konfiguraci allmodconfig a překladač GCC, vždy nejlepší z několika běhů:

sestavení	stroj	před	po
úplné	EPYC 9754	188,0 s	121,1 s
úplné	Threadripper 9980X	344,2 s	278,6 s
přírůstkové	EPYC 9754	70,9 s	24,3 s
prázdné	EPYC 9754	30,6 s	1,5 s
prázdné	Threadripper 9980X	15,3 s	1,4 s

Prázdné sestavení je to, při kterém se od minula nic nezměnilo a make jen zjišťuje, že není co dělat. Tam je úspora největší a zároveň je to běh, který vývojář za den spustí nejčastěji. Čísla ale platí jen za podmínek, které autor v druhé verzi vypsal: musí být nasazené dvě cizí série, sestavuje se s KBUILD_RUST_THREADS=8 a pigz musí být nainstalovaný. Na MacBooku s M2 vyšlo úplné sestavení defconfigu s GCC rychleji o jediné procento, s clangem o deset.

Kód psal model, přepisoval ho člověk

Průvodní dopis má vlastní oddíl nazvaný „LLM usage“ a Stoakes v něm popisuje, jak série vznikla. Model podle něj nejdřív zjistil, kde jsou úzká místa, a pak vymyslel, jak je odstranit. Vygeneroval prý hodně kódu a velká část z něj byla ošklivá; Stoakes píše, že ho důkladně prošel a hodně toho přepsal, a že popisy commitů, průvodní dopis i komentáře upravoval sám. Model také řídil sestavení, testování, ladění a rozbory. Správnost přeložených i spuštěných jader a naměřené zrychlení ověřoval podle svých slov ručně.

Každý commit série proto nese značku Assisted-by: LLM. Není to vlastní nápad: dokumentace jádra ji v kapitole AI Coding Assistants předepisuje přesně v tomhle tvaru, přičemž jména nástrojů za slovem LLM jsou nepovinná a patří tam jen specializované analyzátory, ne git nebo gcc. Táž stránka zakazuje, aby značku Signed-off-by přidával nástroj; ta zůstává člověku, který za příspěvek ručí. Pravidla pro strojově vytvořený obsah k tomu dodávají, že správce smí takový příspěvek vzít jako každý jiný, prohlédnout ho přísněji, odsunout na později, nebo odmítnout rovnou.

Každý projekt s tím nakládá jinak. GCC odmítá příspěvky od jazykových modelů zhruba od patnácti řádků, v jádře se zvolilo označení a zvýšená pozornost. Stoakes taky není první, kdo si o pomoc řekl nahlas: Con Kolivas jim připisuje, že vůbec mohl obnovit svou sadu záplat -ck.

Posudek psal jiný model a část si vymyslel

Zajímavější než psaní je to, co sérii potkalo v recenzi. Vedle lidí ji prošla Sashiko, agentní systém pro posuzování patchů jádra. Patří Linux Foundation, je pod licencí Apache 2.0, stojí na sadě promptů, jejichž první verzi napsal Chris Mason, a výpočetní čas i tokeny k němu platí Google. Sashiko sleduje veřejné konference a ke každé zprávě vydává posudek na vlastní adrese.

V seznamu změn druhé verze na to Stoakes reaguje suše: prošel prý všechny halucinované posudky od Sashiko a odpovídal na ně přímo v konferenci, aby po nich zůstala stopa. U jednoho patche ale dodává, že ta část posudku, která halucinace nebyla, seděla, a doplnil kontrolu ferror(), aby se depcheck choval stejně jako fixdep a kallsyms. Jinde Sashiko upozornila na pořadí polí struktury __this_module při zapnutém CONFIG_RANDSTRUCT. U patche, který v objtoolu dekóduje velké objekty ve víc vláknech, si podle Stoakese velkou část posudku vymyslela a naopak minula souběhy, které našel thread sanitizer.

Co už je v jádře

Linus Torvalds si sérii přečetl den po odeslání a k několika patchům se ozval zvlášť. K průvodnímu dopisu napsal, že ho o smyslu té práce nikdo přesvědčovat nemusí a že by celou sérii rád viděl v jádře; doba sestavení je podle něj jeho letitá bolest. U kallsyms nadhodil, že by se ten krok mohl přepsat na knihovnu libelf a rovnou psát objektový soubor, a u souborů .mod.c podotkl, že by je rád viděl zmizet.

Dva patche ze série jsou v hlavní větvi od 12. září, obě opravy skriptu mksysmap (commity 281b61d4 a 59351365). Zbytek čeká na posouzení a Torvalds sám upozornil, že zásah do objtoolu je dost velký na to, aby ho museli schválit jeho správci. O sérii psal 8. září i Phoronix.

Zdroje: průvodní dopis první verze série a vlákno druhé verze v konferenci linux-kbuild, kapitoly AI Coding Assistants a Kernel Guidelines for Tool-Generated Content v dokumentaci jádra, popis projektu na sashiko.dev a zpráva Phoronixu z 8. září 2026.