Steven Vaughan-Nichols Senior bidragande redaktör
Steven J. Vaughan-Nichols, alias sjvn, har skrivit om teknologi och teknikens verksamhet sedan CP/M-80 var det banbrytande PC-operativsystemet; 300 bps var en snabb Internetanslutning; WordStar var den senaste ordbehandlaren; och vi gillade det.
Fullständig biografi Publicerad i Linux och öppen källkod den 3 januari 2022 | Ämne: Företagsprogramvara
Förra året kom Linuxs källkod till hela 27,8 miljoner rader kod. Det har bara blivit större sedan dess. Liksom alla 30-åriga mjukvaruprojekt har Linux tagit sin beskärda del av cruft under åren. Nu, efter månader av arbete, släpper den senior Linux-kärnutvecklaren Ingo Molnar sin första kniv för att rensa upp den på en grundläggande nivå med sitt “Fast Kernel Headers”-projekt.
Objektet? Inte mindre än en omfattande rensning och omarbetning av Linux-kärnans rubrikhierarki och rubrikberoenden. Linux innehåller många header-, .h-filer. För att vara exakt så finns det cirka 10 000 .h-huvudrubriker i Linux-kärnan med hierarkierna include/och arch/*/include/. Som Molnar förklarade, “Under de senaste 30+ åren har de vuxit till en komplicerad och smärtsam uppsättning korsberoende som vi kärleksfullt kallar 'Beroendehelvete'.”
För att få rim och förnuft till allt detta, föreslår Molnar att göra 2 200 ändringar i koden. Det är många åtaganden! Varför så många? Nåväl, fortsatte Molnar, det visar sig att det finns mycket mer röra i all den koden än han trodde att det var när han började sitt saneringsprojekt i slutet av 2020. För att vara exakt:
När jag startade det här projektet, sent 2020, jag förväntade mig att det skulle finnas kanske 50-100 patchar. Jag gjorde några grova mätningar som antydde att cirka 20 % förbättring av bygghastigheten kunde uppnås genom att minska header-beroendena, utan att ha en betydande körtidseffekt på kärnan. Verkade tillräckligt betydande för att motivera 50-100 commits.
– Men i takt med att antalet patchar ökade såg jag bara begränsade prestandaökningar. I mitten av 2021 fick jag över 500 commits i det här trädet och var tvungen att kasta bort mitt andra försök (!), de två första tillvägagångssätten skalade helt enkelt inte, gick inte att underhålla och erbjöd knappt en 4% uppbyggnadshastighet, inte värt churn av 500 patchar och inte ens värt att tillkännage.
– Med det tredje försöket introducerade jag maskineriet per_task() som gav den nödvändiga flexibiliteten för att drastiskt minska beroenden, och det var ett rent tillvägagångssätt som förbättrade underhållbarheten. Men även vid 1 000 commits fick jag knappt en 10% förbättring av bygghastigheten. Återigen var detta inte något jag kände mig bekväm med att trycka uppströms eller ens meddela. :-/
– Men siffrorna var ganska tydliga: 20 % prestationsvinster var mycket möjliga. Så jag fortsatte att utveckla det här trädet, och de flesta av speedupsna började komma efter över 1 500 commits, hösten 2021. Jag blev mycket förvånad när det gick över 20% speedup och mer än nådde de nuvarande 78% med min referenskonfiguration. Det finns en tydlig superlinjär förbättringsegenskap för kärnbyggnadsoverhead, när antalet beroenden har reducerats till ett minimum.
Så idag erbjuder hans rensade “snabbhuvudsträd” en +50-80 % förbättring av absolut kärnbyggeprestanda på arkitekturer som stöds, beroende på konfigurationen. Detta är ett stort steg framåt när det gäller effektivitet och prestanda för Linuxkärnbyggen.”
En förbättring på 50 till 80 % är väl värt tiden och besväret. Dessa hastighetsbesparingar kommer från att minska storleken på standardhuvudena, som med snabbhuvudsträdet för det mesta kommer att innehålla typdefinitioner, med 1-2 storleksordningar.
Men vänta, dessa 2 200 åtaganden är bara toppen av isberget. Dessa ändringar kommer att påverka nästan alla program i Linux-kärnan. Sammantaget uppskattar Molnar att “utöver de tidigare nämnda 25 underträden och 2 200 commits, modifierar snabbhuvudsträdet över hälften av alla kärnkällfiler som finns.” Det kommer att ändra 25 288 filer med 178 024 infogningar och 74 720 raderingar. Med andra ord, “Ja, så det här är förmodligen det största enskilda funktionsmeddelandet i LKML:s [Linux Kernel Mailing List] historia. Inte av val! :-/”
Utöver detta kommer att göra dessa förändringar möjliga att kräva aggressiv frånkoppling av högnivåhuvuden; frikoppling av typ och API-huvud; automatiskt beroendetillägg till .h- och .c-filer; och optimera rubriker. Det här kommer inte att bli lätt. Så innan han trycker på avtryckaren och börjar göra de här förändringarna samlar Molnar in feedback från sina andra underhållare och i synnerhet skulle han gärna höra från “Linus [Torvalds] & Andrew [Morton] och de andra underhållarna av de största delsystem som påverkas av dessa förändringar.”
Greg Kroah-Hartman, Linux-kärnunderhållaren för den stabila Linux-grenen, tycker “Det här är 'intressant', men hur ska du behålla kärnan/sched/per_task_area_struct_defs .h och struct task_struct_per_task definition i synk?” Kort sagt, vem får ringa katten att behålla alla dessa förändringar?
Molnar svarade att han är villig att ta sig an det här jobbet och att han inte tror att det kommer att bli så mycket besvär. Kroah-Hatman gav sedan Molnars ansträngningar sina välsignelser och anmärkte: “Jag överlåter allt detta till schemaläggarutvecklarna, men det ser fortfarande konstigt ut för mig. Den röra vi skapar när vi försöker lösa problem i C :)”
Han har inte fel. Detta är en anledning till att det pågår ansträngningar för att göra Rust Linuxs andra språk.
Om det antas kommer användarna inte att se några verkliga förändringar. Men Linux-kärna- och distroutvecklare kommer att kunna kompilera Linux snabbare än någonsin. Resultatet blir att göra det enklare och snabbare än någonsin att göra förbättringar, patchar och lägga till funktioner till Linux.
Relaterade berättelser:
Rost tar ett stort steg framåt som Linuxs andra officiella språk År 2022 kommer säkerheten att vara prioritet nummer ett för Linux- och öppen källkodsutvecklare Linus Torvalds: Jonglerar med motorsågar och bygger Linux Linux | Moln | Big Data Analytics | Innovation | Teknik och arbete | Samarbete