Steven Vaughan-Nichols Senior bidragende redaktør
Steven J. Vaughan-Nichols, aka sjvn, har skrevet om teknologi og teknologiens forretning, siden CP/M-80 var det banebrydende pc-operativsystem; 300bps var en hurtig internetforbindelse; WordStar var den nyeste tekstbehandler; og vi kunne lide det.
Fuld biografi Udgivet i Linux og Open Source den 3. januar 2022 | Emne: Enterprise Software
Sidste år nåede Linuxs kildekode op på hele 27,8 millioner linjer kode. Det er kun blevet større siden da. Som ethvert 30 år gammelt softwareprojekt har Linux hentet sin rimelige andel af cruft gennem årene. Nu, efter måneders arbejde, frigiver senior Linux-kerneudvikler Ingo Molnar sit første stik til at rydde op på et grundlæggende niveau med sit “Fast Kernel Headers”-projekt.
Objektet? Intet mindre end en omfattende oprydning og omarbejdelse af Linux-kernens headerhierarki og headerafhængigheder. Linux indeholder mange header-, .h-filer. For at være præcis er der omkring 10.000 hoved-.h-headere i Linux-kernen med hierarkierne include/og arch/*/include/. Som Molnar forklarede: “I løbet af de sidste 30+ år er de vokset til et kompliceret og smertefuldt sæt krydsafhængigheder, som vi kærligt kalder 'Afhængighedshelvede'.”
For at bringe rim og fornuft til alt dette, foreslår Molnar at foretage 2.200 commit-ændringer til koden. Det er en masse commits! Hvorfor så mange? Nå, fortsatte Molnar, det viser sig, at der er meget mere rod i al den kode, end han troede, der var, da han startede sit oprydningsprojekt i slutningen af 2020. For at være præcis:
Når jeg startede dette projekt i slutningen af 2020, jeg forventede, at der var måske 50-100 patches. Jeg foretog et par grove målinger, der foreslog, at omkring 20% forbedring af byggehastigheden kunne opnås ved at reducere header-afhængigheder uden at have en væsentlig runtime-effekt på kernen. Virkede betydelig nok til at retfærdiggøre 50-100 commits.
– Men efterhånden som antallet af patches steg, så jeg kun begrænsede præstationsstigninger. I midten af 2021 nåede jeg over 500 commits i dette træ og måtte smide mit andet forsøg (!), de første to tilgange blev simpelthen ikke skaleret, var ikke vedligeholdelige og tilbød næppe en opbygningshastighed på 4 %, ikke værd churn af 500 patches og ikke engang værd at annoncere.
– Med det tredje forsøg introducerede jeg per_task() maskineriet, som bragte den nødvendige fleksibilitet til at reducere afhængigheder drastisk, og det var en type-clean tilgang, der forbedrede vedligeholdelsen. Men selv ved 1.000 commits nåede jeg knap til en forbedring på 10% byggehastighed. Igen var dette ikke noget, jeg følte mig tryg ved at skubbe opstrøms eller endda annoncere. :-/
– Men tallene var ret klare: 20 % præstationsgevinster var meget muligt. Så jeg blev ved med at udvikle dette træ, og de fleste speedups begyndte at komme efter over 1.500 commits i efteråret 2021. Jeg blev meget overrasket, da det gik ud over 20% speedup og mere end nåede frem til de nuværende 78% med min referencekonfiguration. Der er en klar super-lineær forbedringsegenskab for kerneopbygningsoverhead, når først antallet af afhængigheder er reduceret til det absolutte minimum.
Så i dag tilbyder hans opryddede “fast-headers træ en forbedring på +50-80 % i absolut kernebyggerydeevne på understøttede arkitekturer, afhængigt af konfigurationen. Dette er et stort skridt fremad med hensyn til effektivitet og ydeevne for Linux-kernebyggeri.”
En forbedring på 50 til 80 % er tiden og besværet værd. Disse hastighedsbesparelser kommer fra at reducere størrelsen af standardoverskrifterne, som med hurtig-header-træet for det meste vil omfatte typedefinitioner, med 1-2 størrelsesordener.
Men vent, de 2.200 commits er kun toppen af isbjerget. Disse ændringer vil påvirke næsten alle programmer i Linux-kernen. Alt i alt vurderer Molnar, at “ud over de førnævnte 25 undertræer og 2.200 commits, ændrer træet med hurtige overskrifter over halvdelen af alle eksisterende kerne-kildefiler.” Det kommer til at ændre 25.288 filer med 178.024 indsættelser og 74.720 sletninger. Med andre ord, “Ja, så dette er sandsynligvis den største enkeltfunktionsannoncering i LKML's [Linux Kernel Mailing List] historie. Ikke efter eget valg! :-/”
Oven i dette vil det at gøre disse ændringer gennemførlige kræve aggressiv afkobling af overskrifter på højt niveau; type og API header afkobling; automatisk tilføjelse af afhængighed til .h- og .c-filer; og optimering af overskrifter. Det bliver ikke nemt. Så før han trykker på aftrækkeren og begynder at foretage disse ændringer, samler Molnar feedback fra sine medvedligeholdere, og han ville især elske at høre fra “Linus [Torvalds] & Andrew [Morton] og de andre vedligeholdere af de største undersystemer påvirket af disse ændringer.”
Greg Kroah-Hartman, Linux-kernevedligeholderen for den stabile Linux-gren, synes “Dette er 'interessant', men hvordan vil du beholde kernen/sched/per_task_area_struct_defs .h og struct task_struct_per_task definition i sync?” Kort sagt, hvem får lov til at bibeholde alle disse ændringer?
Molnar svarede, at han er villig til at tackle dette job, og at han ikke tror, det vil være så meget besvær. Kroah-Hatman gav derefter Molnars indsats sine velsignelser og bemærkede: “Jeg vil overlade alt dette til planlæggerudviklerne, men det ser stadig mærkeligt ud for mig. Det rod, vi skaber, når vi prøver at løse problemer i C :)”
Han tager ikke fejl. Dette er en af grundene til, at der er bestræbelser på at gøre Rust Linux' andet sprog.
Hvis det bliver vedtaget, vil brugerne ikke se nogen reelle ændringer. Men Linux-kerne- og distroudviklere vil være i stand til at kompilere Linux hurtigere end nogensinde. Resultatet bliver at gøre det nemmere og hurtigere end nogensinde før at lave forbedringer, patches og tilføje funktioner til Linux.
Relaterede historier:
Rust tager et stort skridt frem som Linuxs andet officielle sprogI 2022 vil sikkerhed være prioritet nummer et for Linux- og open source-udviklereLinus Torvalds: Jonglerer med motorsave og bygger Linux Linux | Sky | Big Data Analytics | Innovation | Teknik og arbejde | Samarbejde