इंगो मोलनार, लिनक्स कर्नलचे सुप्रसिद्ध विकसक आणि CFS टास्क शेड्युलरचे लेखक लिनक्स कर्नल डेव्हलपमेंट मेलिंग लिस्टसाठी अनेक पॅचेस चर्चेसाठी प्रस्तावित केले आहे, जे कर्नल स्त्रोतातील अर्ध्याहून अधिक फायलींना प्रभावित करते आणि कॉन्फिगरेशनवर अवलंबून 50 -80% ची एकूण कर्नल रीबिल्ड गती वाढ प्रदान करते.
ऑप्टिमायझेशन लागू केले हे लक्षणीय आहे की ते सर्वात मोठ्या बदलाच्या जोडणीशी संबंधित आहे कर्नल डेव्हलपमेंटच्या इतिहासात: त्यांनी 2297 हजार पेक्षा जास्त फाईल्स बदलून एकाच वेळी 25 पॅचेस समाविष्ट करण्याचे ठरवले.
कामगिरी वाढ हेडर फाइल हाताळणी पद्धत बदलून साध्य केले जाते. हे लक्षात घेतले पाहिजे की कर्नलच्या विकासाच्या तीस वर्षांपेक्षा जास्त, फायलींमध्ये मोठ्या संख्येने क्रॉस-डिपेंडेन्सी असल्यामुळे हेडर फाइल्सची स्थिती निराशाजनक झाली आहे.
शीर्षलेख फायलींच्या पुनर्रचनाला एक वर्षापेक्षा जास्त वेळ लागला आणि पदानुक्रम आणि अवलंबनांची महत्त्वपूर्ण पुनर्रचना आवश्यक आहे. पुनर्रचना दरम्यान, भिन्न कर्नल उपप्रणालींसाठी प्रकार व्याख्या आणि API वेगळे करण्याचे काम केले गेले.
माझ्या नवीन "फास्ट कर्नल हेडर्स" प्रकल्पाचे पहिले सार्वजनिक प्रकाशन घोषित करताना मला आनंद होत आहे ज्यावर मी 2020 च्या उत्तरार्धापासून काम करत आहे, जे लिनक्स कर्नलच्या शीर्षलेख पदानुक्रम आणि शीर्षलेख अवलंबनांचे दुप्पट उद्दिष्ट असलेले सर्वसमावेशक पुनर्रचना आहे. :
- कर्नल बिल्डची गती वाढवा (संपूर्ण आणि वाढीव बिल्ड वेळा दोन्ही)
- उपप्रणाली प्रकार आणि API व्याख्या एकमेकांपासून डीकपलिंग
बर्‍याच कर्नल डेव्हलपरना माहीत आहे की, लिनक्स कर्नलमध्ये सुमारे ~ 10,000 मुख्य हेडर आहेत, समाविष्ट / आणि arch / * / समाविष्ट / पदानुक्रमात आहेत. गेल्या 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) आर्किटेक्चरसाठी उपलब्ध आहेत.
बारीक आपल्याला त्याबद्दल अधिक जाणून घेण्यात स्वारस्य असल्यास, आपण मधील तपशील तपासू शकता खालील दुवा.