Ingo Molnar, een bekende Linux-kernelontwikkelaar en auteur van CFS Taakplanner stelde voor de mailinglijst voor de ontwikkeling van de Linux-kernel een aantal patches voor, die van invloed zijn op meer dan de helft van alle bestanden in de kernelbron en die een algehele snelheidstoename van de kernel-reconstructie van 50-80% opleveren, afhankelijk van de configuratie.
De geïmplementeerde optimalisatie is opmerkelijk omdat het wordt geassocieerd met de toevoeging van de grootste wijzigingenset in de geschiedenis van kernelontwikkeling: ze wilden 2297 patches tegelijk opnemen, waardoor meer dan 25 duizend bestanden werden gewijzigd.
Prestatiewinst wordt bereikt door de verwerkingsmethode van het headerbestand te wijzigen. Opgemerkt moet worden dat gedurende dertig jaar van kernelontwikkeling, de staat van de headerbestanden een sombere vorm heeft aangenomen vanwege de aanwezigheid van een groot aantal onderlinge afhankelijkheden tussen bestanden.
De herstructurering van de header-bestanden duurde meer dan een jaar en vereiste een aanzienlijk herontwerp van de hiërarchie en afhankelijkheden. Tijdens de herstructurering is gewerkt aan het scheiden van de typedefinities en API's voor de verschillende kernelsubsystemen.
Ik ben verheugd de eerste openbare versie aan te kondigen van mijn nieuwe "Fast Kernel Headers"-project waar ik sinds eind 2020 aan heb gewerkt, wat een uitgebreide herwerking is van de Linux-kernelheaderhiërarchie en headerafhankelijkheden, met een dubbel doel van:
- versnel het bouwen van de kernel (zowel absolute als incrementele bouwtijden)
- type ontkoppeling van subsysteem en definities API van elkaar
Zoals de meeste kernelontwikkelaars weten, zijn er ongeveer 10,000 hoofd .h-headers in de Linux-kernel, in de hiërarchieën include / en arch / * / include /. In de afgelopen 30+ jaar zijn ze geëvolueerd tot een gecompliceerde en pijnlijke reeks van onderlinge afhankelijkheden die we liefkozend 'Dependency Hell' noemen.
Onder de aangebrachte wijzigingen zijn: scheiding van koptekstbestanden op hoog niveau van elkaar, uitsluiting van inline-functies die header-bestanden koppelen, mapping van header-bestanden voor typen en API's, levering van een aparte set header-bestanden (ongeveer 80 bestanden hadden indirecte afhankelijkheden die de montage verstoren, zichtbaar via andere bestanden header-bestanden), automatische toevoeging van afhankelijkheden aan ".h"- en ".c"-bestanden, stapsgewijze optimalisatie van headerbestanden, gebruik van de modus "CONFIG_KALLSYMS_FAST = y", selectieve consolidatie van C-bestanden in assembly-blokken om het aantal objectbestanden te verminderen.
Als gevolg hiervan het verrichte werk maakte het mogelijk om de grootte van de verwerkte header-bestanden te verkleinenin de post-preprocessing fase met 1-2 ordes van grootte.
- Voor optimalisatie resulteerde het gebruik van het headerbestand "linux / gfp.h" bijvoorbeeld in de toevoeging van 13543 regels code en de opname van 303 afhankelijke headerbestanden, en na optimalisatie werd de grootte teruggebracht tot 181 regels en 26 afhankelijke bestanden.
- Nog een voorbeeld: het voorbewerken van het niet-gepatchte "kernel / pid.c"-bestand verbindt 94 duizend regels code, waarvan de meeste niet worden gebruikt in pid.c. Door de header-bestanden te splitsen, konden we de hoeveelheid verwerkte code drie keer verminderen, waardoor het aantal verwerkte regels werd teruggebracht tot 36.
Toen de kernel volledig opnieuw werd opgebouwd met het "make -j96 vmlinux"-commando op het testsysteem, vertoonde de patching een vermindering van de compileertijd van de v5.16-rc7-tak van 231,34 naar 129,97, 15,5 seconden (van 27,7 naar XNUMX builds per uur) en verhoogde ook de efficiëntie van het CPU-kerngebruik tijdens het bouwen.
Met een incrementele compilatie is het optimalisatie-effect nog meer merkbaar: de tijd om de kernel opnieuw op te bouwen na het aanbrengen van wijzigingen in de header-bestanden is aanzienlijk verminderd (van 112% naar 173%, afhankelijk van het header-bestand dat wordt gewijzigd).
Optimalisaties zijn momenteel alleen beschikbaar voor ARM64-, MIPS-, Sparc- en x86-architecturen (32-bits en 64-bits).
Fijn als u er meer over wilt wetenkunt u de details in het volgende link.