Ingo Molnar, isang kilalang Linux kernel developer at may-akda ng CFS Task Scheduler iminungkahi para sa Linux kernel development mailing list discussion ng isang bilang ng mga patch, na nakakaapekto sa higit sa kalahati ng lahat ng mga file sa kernel source at nagbibigay ng pangkalahatang kernel rebuild na pagtaas ng bilis ng 50 -80% depende sa configuration.
Ipinatupad ang pag-optimize ay kapansin-pansin na nauugnay ito sa pagdaragdag ng pinakamalaking set ng pagbabago sa kasaysayan ng pag-unlad ng kernel: itinakda nilang isama ang 2297 na mga patch nang sabay-sabay, na nagbabago ng higit sa 25 libong mga file.
Pagkamit ng pagganap ay nakakamit sa pamamagitan ng pagbabago ng paraan ng paghawak ng header file. Dapat pansinin na sa loob ng tatlumpung taon ng pag-unlad ng kernel, ang estado ng mga file ng header ay nakuha sa isang malungkot na hugis dahil sa pagkakaroon ng isang malaking bilang ng mga cross-dependencies sa pagitan ng mga file.
Ang muling pagsasaayos ng mga file ng header ay tumagal ng higit sa isang taon at nangangailangan ng makabuluhang muling pagdidisenyo ng hierarchy at dependencies. Sa panahon ng muling pagsasaayos, ginawa ang trabaho upang paghiwalayin ang mga kahulugan ng uri at mga API para sa iba't ibang mga subsystem ng kernel.
Ikinalulugod kong ipahayag ang unang pampublikong bersyon ng aking bagong proyektong "Fast Kernel Headers" na pinagtatrabahuhan ko simula noong huling bahagi ng 2020, na isang komprehensibong reworking ng Linux kernel header hierarchy at header dependencies, na may dobleng layunin ng :
- pabilisin ang pagbuo ng kernel (parehong ganap at incremental na mga oras ng pagbuo)
- uri ng decoupling ng subsystem at mga kahulugan ng API mula sa isa't isa
Tulad ng alam ng karamihan sa mga developer ng kernel, mayroong humigit-kumulang ~ 10,000 pangunahing .h na mga header sa Linux kernel, sa isama / at arko / * / isama / hierarchies. Sa nakalipas na 30+ taon, naging kumplikado at masakit na hanay ng mga cross-dependencies ang mga ito na magiliw naming tinatawag na 'Dependency Hell'.
Kabilang sa mga pagbabagong ginawa ay: paghihiwalay ng mataas na antas na mga file ng header mula sa isa't isa, pagbubukod ng mga inline na function na nagli-link ng mga file ng header, pagmamapa ng mga file ng header para sa mga uri at API, pagbibigay ng isang hiwalay na hanay ng mga file ng header (mga 80 mga file ay may mga hindi direktang dependency na nakakasagabal sa pagpupulong, nakalantad sa pamamagitan ng iba pang mga file ng header file), awtomatikong pagdaragdag ng mga dependency sa ".h" at ".c" na mga file, sunud-sunod na pag-optimize ng mga file ng header, paggamit ng mode na "CONFIG_KALLSYMS_FAST = y", piling pagsasama-sama ng mga C file sa mga bloke ng pagpupulong para mabawasan ang bilang ng mga object file.
Bilang isang resulta, ang gawaing ginawa ay pinapayagang bawasan ang laki ng mga naprosesong file ng headersa post-preprocessing stage ng 1-2 orders of magnitude.
- Halimbawa, bago ang pag-optimize, ang paggamit ng header file na "linux / gfp.h" ay nagresulta sa pagdaragdag ng 13543 na linya ng code at ang pagsasama ng 303 dependent na mga header na file, at pagkatapos ng pag-optimize ay nabawasan ang laki sa 181 na linya at 26 na mga dependent na file.
- Isa pang halimbawa: ang preprocessing sa unpatched na "kernel / pid.c" na file ay nagkokonekta ng 94 libong linya ng code, karamihan sa mga ito ay hindi ginagamit sa pid.c. Ang paghahati sa mga file ng header ay nagbigay-daan sa amin na bawasan ang dami ng code na naproseso nang tatlong beses, na binabawasan ang bilang ng mga linyang naproseso sa 36.
Kapag ang kernel ay ganap na itinayong muli gamit ang "make -j96 vmlinux" na utos sa test system, ang patching ay nagpakita ng pagbawas sa compile time ng v5.16-rc7 branch mula 231,34 hanggang 129,97, 15,5 segundo (mula 27,7 hanggang XNUMX build bawat oras) at pinataas din ang kahusayan ng paggamit ng core ng CPU sa panahon ng pagbuo.
Sa isang incremental na compilation, ang epekto ng pag-optimize ay mas kapansin-pansin: ang oras upang muling itayo ang kernel pagkatapos gumawa ng mga pagbabago sa mga file ng header ay makabuluhang nabawasan (mula 112% hanggang 173%, depende sa header file na binago).
Kasalukuyang available lang ang mga pag-optimize para sa mga arkitektura ng ARM64, MIPS, Sparc, at x86 (32-bit at 64-bit).
Makinis kung interesado kang malaman ang tungkol dito, maaari mong suriin ang mga detalye sa sumusunod na link.