ઇંગો મોલનાર, જાણીતા Linux કર્નલ ડેવલપર અને CFS ટાસ્ક શેડ્યૂલરના લેખક લિનક્સ કર્નલ ડેવલપમેન્ટ મેઇલિંગ લિસ્ટની ચર્ચા માટે ઘણા બધા પેચોની દરખાસ્ત કરી છે, જે કર્નલ સ્ત્રોતની અડધાથી વધુ ફાઇલોને અસર કરે છે અને રૂપરેખાંકનના આધારે 50 -80% નો એકંદર કર્નલ રિબિલ્ડ સ્પીડ વધારો પ્રદાન કરે છે.
ઑપ્ટિમાઇઝેશન અમલમાં મૂક્યું નોંધપાત્ર છે કે તે સૌથી મોટા ફેરફારના ઉમેરા સાથે સંકળાયેલ છે કર્નલ ડેવલપમેન્ટના ઈતિહાસમાં: તેઓએ 2297 હજારથી વધુ ફાઈલો બદલીને એકસાથે 25 પેચોનો સમાવેશ કરવાનું નક્કી કર્યું.
પ્રદર્શન લાભ હેડર ફાઇલ હેન્ડલિંગ પદ્ધતિને બદલીને પ્રાપ્ત થાય છે. એ નોંધવું જોઇએ કે કર્નલ ડેવલપમેન્ટના ત્રીસ વર્ષ દરમિયાન, ફાઇલો વચ્ચે મોટી સંખ્યામાં ક્રોસ-ડિપેન્ડન્સીની હાજરીને કારણે હેડર ફાઇલોની સ્થિતિ નિરાશાજનક બની છે.
હેડર ફાઈલોની પુનઃરચના કરવામાં એક વર્ષ જેટલો સમય લાગ્યો અને વંશવેલો અને નિર્ભરતાના નોંધપાત્ર પુનઃડિઝાઇનની જરૂર છે. પુનઃરચના દરમિયાન, વિવિધ કર્નલ સબસિસ્ટમ માટે પ્રકાર વ્યાખ્યાઓ અને API ને અલગ કરવા માટે કાર્ય કરવામાં આવ્યું હતું.
મને મારા નવા "ફાસ્ટ કર્નલ હેડર્સ" પ્રોજેક્ટના પ્રથમ સાર્વજનિક સંસ્કરણની જાહેરાત કરતા આનંદ થાય છે કે જેના પર હું 2020 ના અંતથી કામ કરી રહ્યો છું, જે લિનક્સ કર્નલ હેડર હાયરાર્કી અને હેડર ડિપેન્ડન્સીના બેવડા ઉદ્દેશ્ય સાથે વ્યાપક પુનઃકાર્ય છે:
- કર્નલ બિલ્ડને વેગ આપો (સંપૂર્ણ અને વધતા જતા સમય બંને)
- એકબીજાથી સબસિસ્ટમ અને વ્યાખ્યાઓ APIનું ડીકપલિંગ ટાઇપ કરો
મોટાભાગના કર્નલ વિકાસકર્તાઓ જાણે છે તેમ, Linux કર્નલમાં લગભગ ~ 10,000 મુખ્ય .h હેડરો છે, જેમાં સમાવેશ થાય છે / અને arch / * / include / hierarchies. છેલ્લા 30+ વર્ષોમાં, તેઓ ક્રોસ-ડિપેન્ડન્સીના એક જટિલ અને પીડાદાયક સમૂહમાં વિકસિત થયા છે જેને આપણે પ્રેમથી 'ડિપેન્ડન્સી હેલ' કહીએ છીએ.
કરવામાં આવેલા ફેરફારોમાં આ છે: ઉચ્ચ-સ્તરની હેડર ફાઇલોને એકબીજાથી અલગ કરવી, હેડર ફાઇલોને લિંક કરતા ઇનલાઇન ફંક્શન્સનો બાકાત, પ્રકારો અને API માટે હેડર ફાઇલોનું મેપિંગ, હેડર ફાઇલોના અલગ સેટની જોગવાઈ (લગભગ 80 ફાઇલોમાં પરોક્ષ અવલંબન છે જે એસેમ્બલીમાં દખલ કરે છે, અન્ય ફાઇલો હેડર ફાઇલો દ્વારા ખુલ્લી થાય છે), પર નિર્ભરતાઓનો સ્વચાલિત ઉમેરો ".h" અને ".c" ફાઇલો, હેડર ફાઇલોનું સ્ટેપ-બાય-સ્ટેપ ઑપ્ટિમાઇઝેશન, "CONFIG_KALLSYMS_FAST = y" મોડનો ઉપયોગ, ઑબ્જેક્ટ ફાઇલોની સંખ્યા ઘટાડવા માટે એસેમ્બલી બ્લોક્સમાં C ફાઇલોનું પસંદગીયુક્ત એકીકરણ.
પરિણામે, પ્રક્રિયા કરેલ હેડર ફાઇલોના કદને ઘટાડવાની મંજૂરી આપેલ કાર્યપ્રી-પ્રોસેસિંગ તબક્કામાં 1-2 ક્રમની તીવ્રતા દ્વારા.
- ઉદાહરણ તરીકે, ઑપ્ટિમાઇઝેશન પહેલાં, હેડર ફાઇલ "linux/gfp.h" નો ઉપયોગ કરવાથી કોડની 13543 લાઇન ઉમેરવામાં આવી હતી અને 303 આશ્રિત હેડર ફાઇલોનો સમાવેશ થયો હતો, અને ઑપ્ટિમાઇઝેશન પછી કદ 181 રેખાઓ અને 26 આશ્રિત ફાઇલો સુધી ઘટાડી દેવામાં આવ્યું હતું.
- બીજું ઉદાહરણ: પેચ વગરની "kernel/pid.c" ફાઇલને પ્રીપ્રોસેસ કરવાથી કોડની 94 હજાર રેખાઓ જોડાય છે, જેમાંથી મોટાભાગની pid.c માં ઉપયોગમાં લેવાતી નથી. હેડર ફાઇલોને વિભાજિત કરવાથી અમને ત્રણ વખત પ્રોસેસ્ડ કોડની માત્રા ઘટાડવાની મંજૂરી મળી, પ્રોસેસ્ડ લાઇનની સંખ્યા ઘટાડીને 36 થઈ.
જ્યારે ટેસ્ટ સિસ્ટમ પર "make -j96 vmlinux" આદેશ સાથે કર્નલ સંપૂર્ણપણે પુનઃબીલ્ડ કરવામાં આવ્યું હતું, ત્યારે પેચિંગે v5.16-rc7 શાખાના કમ્પાઈલ સમયમાં 231,34 થી 129,97, 15,5 સેકન્ડનો ઘટાડો દર્શાવ્યો હતો (27,7 થી XNUMX બિલ્ડ પ્રતિ કલાક) અને બિલ્ડ દરમિયાન CPU કોર વપરાશની કાર્યક્ષમતા પણ વધારી છે.
વધારાના સંકલન સાથે, ઑપ્ટિમાઇઝેશન અસર વધુ ધ્યાનપાત્ર છે: હેડર ફાઇલોમાં ફેરફારો કર્યા પછી કર્નલને ફરીથી બનાવવાનો સમય નોંધપાત્ર રીતે ઘટાડી દેવામાં આવ્યો છે (હેડર ફાઇલના આધારે 112% થી 173% જે બદલાઈ છે).
ઑપ્ટિમાઇઝેશન હાલમાં માત્ર ARM64, MIPS, Sparc અને x86 (32-bit અને 64-bit) આર્કિટેક્ચર માટે ઉપલબ્ધ છે.
સરસ રીતે જો તમને તેના વિશે વધુ જાણવામાં રસ છે, તમે માં વિગતો ચકાસી શકો છો નીચેની કડી