Steven Vaughan-Nichols Seniorbidragsredaktør
Steven J. Vaughan-Nichols, aka sjvn, har skrevet om teknologi og teknologivirksomhet siden CP/M-80 var banebrytende PC-operativsystem; 300bps var en rask Internett-tilkobling; WordStar var toppmoderne tekstbehandler; og vi likte det.
Full bio Publisert i Linux og åpen kildekode 3. januar 2022 | Emne: Enterprise Software
I fjor kom Linuxs kildekode til hele 27,8 millioner linjer med kode. Det har bare blitt større siden den gang. Som ethvert 30 år gammelt programvareprosjekt, har Linux plukket opp sin rimelige andel av cruft gjennom årene. Nå, etter måneder med arbeid, slipper senior Linux-kjerneutvikler Ingo Molnar sitt første stikk for å rydde opp på et grunnleggende nivå med sitt “Fast Kernel Headers”-prosjekt.
Objektet? Ikke mindre enn en omfattende opprydding og omarbeiding av Linux-kjernens overskriftshierarki og overskriftsavhengigheter. Linux inneholder mange header-, .h-filer. For å være nøyaktig er det omtrent 10 000 hoved-.h-hoder i Linux-kjernen med hierarkiene include/og arch/*/include/. Som Molnar forklarte, “I løpet av de siste 30+ årene har de vokst til et komplisert og smertefullt sett med kryssavhengigheter som vi kjærlig kaller 'Dependency Hell'.”
For å bringe rim og grunn til alt dette, foreslår Molnar å gjøre 2200 commit-endringer i koden. Det er mange forpliktelser! Hvorfor så mange? Vel, fortsatte Molnar, det viser seg at det er mye mer rot i all den koden enn han trodde det var da han startet opprydningsprosjektet sitt sent i 2020. For å være nøyaktig:
Når jeg startet dette prosjektet sent i 2020, jeg forventet at det ville være kanskje 50-100 patcher. Jeg gjorde noen grove målinger som antydet at en forbedring på omtrent 20 % byggehastighet kunne oppnås ved å redusere header-avhengighetene, uten å ha en betydelig kjøretidseffekt på kjernen. Virket betydelig nok til å rettferdiggjøre 50-100 forpliktelser.
– Men etter hvert som antallet patcher økte, så jeg bare begrensede ytelsesøkninger. I midten av 2021 kom jeg til over 500 commits i dette treet og måtte kaste bort mitt andre forsøk (!), de to første tilnærmingene ble rett og slett ikke skalert, var ikke vedlikeholdbare og tilbød knapt en byggehastighet på 4 %, ikke verdt churn av 500 patcher og ikke verdt å kunngjøre engang.
– Med det tredje forsøket introduserte jeg per_task()-maskineriet som ga den nødvendige fleksibiliteten for å redusere avhengigheter drastisk, og det var en ren tilnærming som forbedret vedlikeholdsevnen. Men selv ved 1000 forpliktelser fikk jeg knapt en forbedring på 10 % byggehastighet. Igjen var dette ikke noe jeg følte meg komfortabel med å presse oppstrøms eller til og med kunngjøre. :-/
– Men tallene var ganske klare: 20 % ytelsesgevinst var veldig mulig. Så jeg fortsatte å utvikle dette treet, og de fleste speedupene begynte å komme etter over 1500 commits høsten 2021. Jeg ble veldig overrasket da det gikk over 20% speedup og mer enn nådde nåværende 78% med referansekonfigurasjonen min. Det er en tydelig super-lineær forbedringsegenskap for kjernebyggingsoverhead, når antallet avhengigheter er redusert til det absolutte minimum.
Så, i dag, tilbyr hans ryddede “hurtigheader-tre” en +50–80 % forbedring i absolutt kjernebyggingsytelse på støttede arkitekturer, avhengig av konfigurasjonen. Dette er et stort fremskritt når det gjelder effektivitet og ytelse for Linux-kjernebygging.”
En forbedring på 50 til 80 % er vel verdt tiden og bryet. Disse hastighetsbesparelsene kommer fra å redusere størrelsen på standardhodene, som med hurtigoverskriftstreet for det meste vil inkludere typedefinisjoner, med 1-2 størrelsesordener.
Men vent, de 2200 forpliktelsene er bare toppen av isfjellet. Disse endringene vil påvirke nesten alle programmer i Linux-kjernen. Til sammen anslår Molnar at “i tillegg til de nevnte 25 undertrærne og 2200 commits, modifiserer hurtighodetreet over halvparten av alle kjernekildefiler som eksisterer.” Det kommer til å endre 25 288 filer med 178 024 innsettinger og 74 720 slettinger. Med andre ord, “Ja, så dette er sannsynligvis den største enkeltfunksjonskunngjøringen i LKMLs [Linux Kernel Mailing List]-historie. Ikke etter eget valg! :-/”
På toppen av dette vil det å gjøre disse endringene gjennomførbare kreve aggressiv frakobling av overskrifter på høyt nivå; type og API header frakobling; automatisert avhengighetstillegg til .h- og .c-filer; og optimalisering av overskrifter. Dette blir ikke lett. Så før du trykker på avtrekkeren og begynner å gjøre disse endringene, samler Molnar tilbakemeldinger fra sine andre vedlikeholdere, og spesielt ville han gjerne høre fra “Linus [Torvalds] & Andrew [Morton] og de andre vedlikeholderne av de største undersystemer påvirket av disse endringene.”
Greg Kroah-Hartman, Linux-kjernen vedlikeholder for den stabile Linux-grenen, mener “Dette er 'interessant', men hvordan skal du beholde kjernen/sched/per_task_area_struct_defs .h og struct task_struct_per_task definisjon synkronisert?” Kort sagt, hvem får lov til å opprettholde alle disse endringene?
Molnar svarte at han er villig til å takle denne jobben og at han ikke tror det blir så mye trøbbel. Kroah-Hatman ga deretter Molnars innsats velsignelser og bemerket: “Jeg overlater alt dette til planleggerutviklerne, men det ser fortsatt rart ut for meg. Rotet vi skaper når vi prøver å omgå problemer i C :)”
Han tar ikke feil. Dette er en av grunnene til at det pågår anstrengelser for å gjøre Rust Linux sitt andre språk.
Hvis det blir tatt i bruk, vil brukerne ikke se noen reelle endringer. Men Linux-kjerne- og distroutviklere vil kunne kompilere Linux raskere enn noen gang. Resultatet vil være å gjøre det enklere og raskere enn noen gang å gjøre forbedringer, oppdateringer og legge til funksjoner i Linux.
Relaterte historier:
Rust tar et stort skritt frem som Linuxs andre offisielle språkI 2022 vil sikkerhet være prioritet nummer én for Linux- og åpen kildekode-utviklereLinus Torvalds: Sjonglere med motorsager og bygge Linux Linux | Sky | Big Data Analytics | Innovasjon | Teknikk og arbeid | Samarbeid