बूट समय अनुकूलन

यह पृष्ठ युक्तियों का एक सेट प्रदान करता है, जिसे आप बूट समय में सुधार करने के लिए चुन सकते हैं।

मॉड्यूल से डिबग प्रतीकों को हटा दें

जिस प्रकार किसी उत्पादन उपकरण पर कर्नेल से डिबग प्रतीकों को हटा दिया जाता है, उसी प्रकार सुनिश्चित करें कि आप मॉड्यूल से भी डिबग प्रतीकों को हटा दें। मॉड्यूल से डिबग प्रतीकों को अलग करने से निम्नलिखित को कम करके बूट समय में मदद मिलती है:

• फ्लैश से बायनेरिज़ को पढ़ने में लगने वाला समय।
• रैमडिस्क को डीकंप्रेस करने में लगने वाला समय.
• मॉड्यूल लोड करने में लगने वाला समय.

मॉड्यूल से डिबग प्रतीक को अलग करने से बूट के दौरान कई सेकंड की बचत हो सकती है।

एंड्रॉइड प्लेटफ़ॉर्म बिल्ड में सिंबल स्ट्रिपिंग डिफ़ॉल्ट रूप से सक्षम है, लेकिन उन्हें स्पष्ट रूप से सक्षम करने के लिए, डिवाइस/ vendor / device के तहत अपने डिवाइस-विशिष्ट कॉन्फ़िगरेशन में BOARD_DO_NOT_STRIP_VENDOR_RAMDISK_MODULES सेट करें।

कर्नेल और रैमडिस्क के लिए LZ4 संपीड़न का उपयोग करें

Gzip LZ4 की तुलना में छोटा संपीड़ित आउटपुट उत्पन्न करता है, लेकिन LZ4 Gzip की तुलना में तेजी से डीकंप्रेस होता है। कर्नेल और मॉड्यूल के लिए, Gzip का उपयोग करने से पूर्ण भंडारण आकार में कमी LZ4 के डीकंप्रेसन समय लाभ की तुलना में उतनी महत्वपूर्ण नहीं है।

LZ4 रैमडिस्क कम्प्रेशन के लिए समर्थन को BOARD_RAMDISK_USE_LZ4 के माध्यम से एंड्रॉइड प्लेटफ़ॉर्म बिल्ड में जोड़ा गया है। आप इस विकल्प को अपने डिवाइस-विशिष्ट कॉन्फ़िगरेशन में सेट कर सकते हैं। कर्नेल संपीड़न को कर्नेल डिकॉन्फिग के माध्यम से सेट किया जा सकता है।

LZ4 पर स्विच करने से 500ms से 1000ms तेज बूट समय मिलना चाहिए।

अपने ड्राइवरों में अत्यधिक लॉगिंग से बचें

ARM64 और ARM32 में, फ़ंक्शन कॉल जो कॉल साइट से एक विशिष्ट दूरी से अधिक हैं, उन्हें पूर्ण जंप पते को एन्कोड करने में सक्षम होने के लिए एक जंप टेबल (जिसे प्रक्रिया लिंकिंग टेबल या पीएलटी कहा जाता है) की आवश्यकता होती है। चूंकि मॉड्यूल गतिशील रूप से लोड किए जाते हैं, इसलिए मॉड्यूल लोड के दौरान इन जंप टेबलों को ठीक करने की आवश्यकता होती है। जिन कॉलों को स्थानांतरण की आवश्यकता होती है, उन्हें ELF प्रारूप में स्पष्ट परिवर्धन (या संक्षेप में RELA) प्रविष्टियों के साथ स्थानांतरण प्रविष्टियाँ कहा जाता है।

पीएलटी आवंटित करते समय लिनक्स कर्नेल कुछ मेमोरी साइज ऑप्टिमाइज़ेशन (जैसे कैश हिट ऑप्टिमाइज़ेशन) करता है। इस अपस्ट्रीम कमिट के साथ, अनुकूलन योजना में O(N^2) जटिलता है, जहां N R_AARCH64_JUMP26 या R_AARCH64_CALL26 प्रकार के RELAs की संख्या है। इसलिए इस प्रकार के कम RELAs का होना मॉड्यूल लोड समय को कम करने में सहायक है।

एक सामान्य कोडिंग पैटर्न जो R_AARCH64_CALL26 या R_AARCH64_JUMP26 RELAs की संख्या बढ़ाता है, वह है ड्राइवर में अत्यधिक लॉगिंग। printk() या किसी अन्य लॉगिंग स्कीम के लिए प्रत्येक कॉल आम तौर पर एक CALL26 / JUMP26 RELA प्रविष्टि जोड़ती है। अपस्ट्रीम कमिट में कमिट टेक्स्ट में, ध्यान दें कि अनुकूलन के साथ भी, छह मॉड्यूल को लोड होने में लगभग 250ms लगते हैं - ऐसा इसलिए है क्योंकि वे छह मॉड्यूल सबसे अधिक लॉगिंग के साथ शीर्ष छह मॉड्यूल थे।

लॉगिंग को कम करने से बूट समय पर लगभग 100 - 300 एमएस की बचत हो सकती है, यह इस बात पर निर्भर करता है कि मौजूदा लॉगिंग कितनी अधिक है।

चयनात्मक रूप से अतुल्यकालिक जांच सक्षम करें

जब एक मॉड्यूल लोड किया जाता है, यदि वह डिवाइस जो इसे सपोर्ट करता है, पहले से ही डीटी (डिवाइसट्री) से पॉप्युलेट हो चुका है और ड्राइवर कोर में जोड़ा गया है, तो डिवाइस की जांच module_init() कॉल के संदर्भ में की जाती है। जब किसी डिवाइस की जांच module_init() के संदर्भ में की जाती है, तो जांच पूरी होने तक मॉड्यूल लोडिंग समाप्त नहीं कर सकता है। चूँकि मॉड्यूल लोडिंग अधिकतर क्रमबद्ध होती है, एक उपकरण जो जांच करने में अपेक्षाकृत लंबा समय लेता है वह बूट समय को धीमा कर देता है।

धीमे बूट समय से बचने के लिए, उन मॉड्यूल के लिए एसिंक्रोनस जांच सक्षम करें जिन्हें अपने डिवाइस की जांच करने में कुछ समय लगता है। सभी मॉड्यूल के लिए एसिंक्रोनस जांच को सक्षम करना फायदेमंद नहीं हो सकता है क्योंकि थ्रेड को फोर्क करने और जांच को शुरू करने में लगने वाला समय डिवाइस की जांच करने में लगने वाले समय जितना अधिक हो सकता है।

वे डिवाइस जो धीमी बस के माध्यम से जुड़े हुए हैं जैसे कि I2C, वे डिवाइस जो अपने जांच फ़ंक्शन में फ़र्मवेयर लोडिंग करते हैं, और वे डिवाइस जो बहुत अधिक हार्डवेयर आरंभीकरण करते हैं, समय संबंधी समस्या का कारण बन सकते हैं। ऐसा कब होता है इसकी पहचान करने का सबसे अच्छा तरीका प्रत्येक ड्राइवर के लिए जांच का समय एकत्र करना और उसे क्रमबद्ध करना है।

किसी मॉड्यूल के लिए अतुल्यकालिक जांच को सक्षम करने के लिए, केवल ड्राइवर कोड में PROBE_PREFER_ASYNCHRONOUS ध्वज सेट करना पर्याप्त नहीं है । मॉड्यूल के लिए, आपको कर्नेल कमांड लाइन में module_name .async_probe=1 जोड़ना होगा या modprobe या insmod का उपयोग करके मॉड्यूल लोड करते समय मॉड्यूल पैरामीटर के रूप में async_probe=1 पास करना होगा।

एसिंक्रोनस प्रोबिंग को सक्षम करने से आपके हार्डवेयर/ड्राइवरों के आधार पर बूट समय पर लगभग 100 - 500 एमएस की बचत हो सकती है।

यथाशीघ्र अपने CPUfreq ड्राइवर की जांच करें

जितनी जल्दी आपका CPUfreq ड्राइवर जांच करेगा, उतनी ही जल्दी आप बूट के दौरान CPU आवृत्ति को अधिकतम (या कुछ थर्मली सीमित अधिकतम) तक स्केल कर सकते हैं। CPU जितना तेज़ होगा, बूट उतना ही तेज़ होगा। यह दिशानिर्देश devfreq ड्राइवरों पर भी लागू होता है जो DRAM, मेमोरी और इंटरकनेक्ट फ़्रीक्वेंसी को नियंत्रित करते हैं।

मॉड्यूल के साथ, लोड ऑर्डर initcall स्तर और ड्राइवरों के संकलन या लिंक ऑर्डर पर निर्भर हो सकता है। यह सुनिश्चित करने के लिए उपनाम MODULE_SOFTDEP() का उपयोग करें कि cpufreq ड्राइवर लोड होने वाले पहले कुछ मॉड्यूल में से एक है।

मॉड्यूल को जल्दी लोड करने के अलावा, आपको यह भी सुनिश्चित करना होगा कि CPUfreq ड्राइवर की जांच के लिए सभी निर्भरताओं की भी जांच की गई है। उदाहरण के लिए, यदि आपको अपने सीपीयू की आवृत्ति को नियंत्रित करने के लिए घड़ी या नियामक हैंडल की आवश्यकता है, तो सुनिश्चित करें कि पहले उनकी जांच की गई है। या यदि बूट अप के दौरान आपके सीपीयू का बहुत अधिक गर्म होना संभव है, तो आपको सीपीयूफ़्रेक ड्राइवर से पहले थर्मल ड्राइवरों को लोड करने की आवश्यकता हो सकती है। इसलिए, यह सुनिश्चित करने के लिए हर संभव प्रयास करें कि CPUfreq और प्रासंगिक devfreq ड्राइवर यथाशीघ्र जांच करें।

आपके CPUfreq ड्राइवर की जल्दी जांच करने से होने वाली बचत बहुत छोटी से लेकर बहुत बड़ी हो सकती है, यह इस बात पर निर्भर करता है कि आप कितनी जल्दी जांच करवा सकते हैं और बूटलोडर किस आवृत्ति पर सीपीयू छोड़ता है।

मॉड्यूल को दूसरे चरण के init, विक्रेता या विक्रेता_dlkm विभाजन में ले जाएँ

चूँकि प्रथम चरण की init प्रक्रिया क्रमबद्ध है, इसलिए बूट प्रक्रिया को समानांतर करने के अधिक अवसर नहीं हैं। यदि पहले चरण के इनिट को समाप्त करने के लिए मॉड्यूल की आवश्यकता नहीं है, तो मॉड्यूल को विक्रेता या vendor_dlkm विभाजन में रखकर दूसरे चरण के इनिट में ले जाएं।

पहले चरण के init को दूसरे चरण के init तक पहुंचने के लिए कई उपकरणों की जांच की आवश्यकता नहीं होती है। सामान्य बूट प्रवाह के लिए केवल कंसोल और फ़्लैश स्टोरेज कार्यक्षमता की आवश्यकता होती है।

निम्नलिखित आवश्यक ड्राइवर लोड करें:

• निगरानी
• रीसेट
• cpufreq

पुनर्प्राप्ति और उपयोगकर्ता स्थान fastbootd मोड के लिए, पहले चरण के इनिट में जांच करने और प्रदर्शित करने के लिए अधिक उपकरणों की आवश्यकता होती है (जैसे यूएसबी)। इन मॉड्यूल की एक प्रति पहले चरण रैमडिस्क और विक्रेता या vendor_dlkm विभाजन में रखें। यह उन्हें पुनर्प्राप्ति या fastbootd बूट प्रवाह के लिए पहले चरण के इनिट में लोड करने की अनुमति देता है। हालाँकि, सामान्य बूट प्रवाह के दौरान पुनर्प्राप्ति मोड मॉड्यूल को पहले चरण init में लोड न करें। बूट समय को कम करने के लिए पुनर्प्राप्ति मोड मॉड्यूल को दूसरे चरण init में स्थगित किया जा सकता है। अन्य सभी मॉड्यूल जिनकी पहले चरण init में आवश्यकता नहीं है, उन्हें विक्रेता या vendor_dlkm विभाजन में ले जाया जाना चाहिए।

लीफ डिवाइसों (उदाहरण के लिए, यूएफएस या सीरियल) की एक सूची को देखते हुए, dev needs.sh स्क्रिप्ट जांच के लिए निर्भरता या आपूर्तिकर्ताओं (उदाहरण के लिए, घड़ियां, नियामक, या gpio ) के लिए आवश्यक सभी ड्राइवरों, उपकरणों और मॉड्यूल को ढूंढती है।

मॉड्यूल को दूसरे चरण init में ले जाने से निम्नलिखित तरीकों से बूट समय कम हो जाता है:

• रैमडिस्क आकार में कमी.
  • जब बूटलोडर रैमडिस्क (क्रमबद्ध बूट चरण) को लोड करता है तो यह तेजी से फ्लैश पढ़ता है।
  • जब कर्नेल रैमडिस्क (क्रमबद्ध बूट चरण) को डीकंप्रेस करता है तो इससे तेज डीकंप्रेसन गति प्राप्त होती है।
• दूसरा चरण init समानांतर में काम करता है, जो दूसरे चरण init में किए जा रहे काम के साथ मॉड्यूल के लोडिंग समय को छुपाता है।

मॉड्यूल को दूसरे चरण में ले जाने से बूट समय पर 500 - 1000 एमएस की बचत हो सकती है, यह इस बात पर निर्भर करता है कि आप कितने मॉड्यूल को दूसरे चरण में ले जाने में सक्षम हैं।

मॉड्यूल लोडिंग लॉजिस्टिक्स

नवीनतम एंड्रॉइड बिल्ड में बोर्ड कॉन्फ़िगरेशन की सुविधा है जो नियंत्रित करती है कि कौन से मॉड्यूल प्रत्येक चरण में कॉपी होते हैं, और कौन से मॉड्यूल लोड होते हैं। यह अनुभाग निम्नलिखित उपसमुच्चय पर केंद्रित है:

• BOARD_VENDOR_RAMDISK_KERNEL_MODULES . मॉड्यूल की इस सूची को रैमडिस्क में कॉपी किया जाना है।
• BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD । प्रथम चरण init में लोड किए जाने वाले मॉड्यूल की यह सूची।
• BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD । रैमडिस्क से रिकवरी या fastbootd चयन होने पर लोड किए जाने वाले मॉड्यूल की यह सूची।
• BOARD_VENDOR_KERNEL_MODULES . मॉड्यूल की इस सूची को विक्रेता या vendor_dlkm विभाजन में /vendor/lib/modules/ निर्देशिका में कॉपी किया जाना है।
• BOARD_VENDOR_KERNEL_MODULES_LOAD . दूसरे चरण init में लोड किए जाने वाले मॉड्यूल की यह सूची।

रैमडिस्क में बूट और रिकवरी मॉड्यूल को विक्रेता या vendor_dlkm विभाजन में /vendor/lib/modules पर भी कॉपी किया जाना चाहिए। इन मॉड्यूल को विक्रेता विभाजन में कॉपी करने से यह सुनिश्चित होता है कि मॉड्यूल दूसरे चरण के इनिट के दौरान अदृश्य नहीं हैं, जो बगरेपोर्ट के लिए डिबगिंग और modinfo एकत्र करने के लिए उपयोगी है।

जब तक बूट मॉड्यूल सेट कम से कम किया जाता है, तब तक डुप्लिकेशन में विक्रेता या vendor_dlkm विभाजन पर न्यूनतम स्थान खर्च होना चाहिए। सुनिश्चित करें कि विक्रेता की modules.list फ़ाइल में /vendor/lib/modules में मॉड्यूल की फ़िल्टर की गई सूची है। फ़िल्टर की गई सूची यह सुनिश्चित करती है कि मॉड्यूल के दोबारा लोड होने से बूट समय प्रभावित न हो (जो एक महंगी प्रक्रिया है)।

सुनिश्चित करें कि पुनर्प्राप्ति मोड मॉड्यूल एक समूह के रूप में लोड हो। पुनर्प्राप्ति मोड मॉड्यूल को लोड करना या तो पुनर्प्राप्ति मोड में किया जा सकता है, या प्रत्येक बूट प्रवाह में दूसरे चरण की शुरुआत में किया जा सकता है।

आप इन क्रियाओं को करने के लिए डिवाइस Board.Config.mk फ़ाइलों का उपयोग कर सकते हैं जैसा कि निम्नलिखित उदाहरण में देखा गया है:

# All kernel modules
KERNEL_MODULES := $(wildcard $(KERNEL_MODULE_DIR)/*.ko)
KERNEL_MODULES_LOAD := $(strip $(shell cat $(KERNEL_MODULE_DIR)/modules.load)

# First stage ramdisk modules
BOOT_KERNEL_MODULES_FILTER := $(foreach m,$(BOOT_KERNEL_MODULES),%/$(m))

# Recovery ramdisk modules
RECOVERY_KERNEL_MODULES_FILTER := $(foreach m,$(RECOVERY_KERNEL_MODULES),%/$(m))
BOARD_VENDOR_RAMDISK_KERNEL_MODULES += \
     $(filter $(BOOT_KERNEL_MODULES_FILTER) \
                $(RECOVERY_KERNEL_MODULES_FILTER),$(KERNEL_MODULES))

# ALL modules land in /vendor/lib/modules so they could be rmmod/insmod'd,
# and modules.list actually limits us to the ones we intend to load.
BOARD_VENDOR_KERNEL_MODULES := $(KERNEL_MODULES)
# To limit /vendor/lib/modules to just the ones loaded, use:
# BOARD_VENDOR_KERNEL_MODULES := $(filter-out \
#     $(BOOT_KERNEL_MODULES_FILTER),$(KERNEL_MODULES))

# Group set of /vendor/lib/modules loading order to recovery modules first,
# then remainder, subtracting both recovery and boot modules which are loaded
# already.
BOARD_VENDOR_KERNEL_MODULES_LOAD := \
        $(filter-out $(BOOT_KERNEL_MODULES_FILTER), \
        $(filter $(RECOVERY_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD)))
BOARD_VENDOR_KERNEL_MODULES_LOAD += \
        $(filter-out $(BOOT_KERNEL_MODULES_FILTER) \
            $(RECOVERY_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD))

# NB: Load order governed by modules.load and not by $(BOOT_KERNEL_MODULES)
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \
        $(filter $(BOOT_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD))

# Group set of /vendor/lib/modules loading order to boot modules first,
# then the remainder of recovery modules.
BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD := \
    $(filter $(BOOT_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD))
BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD += \
    $(filter-out $(BOOT_KERNEL_MODULES_FILTER), \
    $(filter $(RECOVERY_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD)))

यह उदाहरण बोर्ड कॉन्फ़िगरेशन फ़ाइलों में स्थानीय रूप से निर्दिष्ट किए जाने वाले BOOT_KERNEL_MODULES और RECOVERY_KERNEL_MODULES के प्रबंधन में आसान उपसमूह को दिखाता है। पूर्ववर्ती स्क्रिप्ट चयनित उपलब्ध कर्नेल मॉड्यूल में से प्रत्येक सबसेट मॉड्यूल को ढूंढती है और भरती है, दूसरे चरण के इनिट के लिए रीमिनिंग मॉड्यूल को छोड़ देती है।

दूसरे चरण के इनिट के लिए, हम मॉड्यूल लोडिंग को एक सेवा के रूप में चलाने की सलाह देते हैं ताकि यह बूट प्रवाह को अवरुद्ध न करे। मॉड्यूल लोडिंग को प्रबंधित करने के लिए एक शेल स्क्रिप्ट का उपयोग करें ताकि यदि आवश्यक हो तो अन्य लॉजिस्टिक्स, जैसे त्रुटि प्रबंधन और शमन, या मॉड्यूल लोड पूर्णता को वापस रिपोर्ट किया जा सके (या अनदेखा किया जा सके)।

आप डिबग मॉड्यूल लोड विफलता को अनदेखा कर सकते हैं जो उपयोगकर्ता बिल्ड पर मौजूद नहीं है। इस विफलता को नजरअंदाज करने के लिए, लॉन्च स्क्रीन पर जारी रखने के लिए init rc स्क्रिप्टिंग बूटफ्लो के बाद के चरणों को ट्रिगर करने के लिए vendor.device.modules.ready प्रॉपर्टी सेट करें। यदि आपके पास /vendor/etc/init.insmod.sh में निम्नलिखित कोड है , तो निम्नलिखित उदाहरण स्क्रिप्ट का संदर्भ लें:

#!/vendor/bin/sh
. . .
if [ $# -eq 1 ]; then
  cfg_file=$1
else
  # Set property even if there is no insmod config
  # to unblock early-boot trigger
  setprop vendor.common.modules.ready
  setprop vendor.device.modules.ready
  exit 1
fi

if [ -f $cfg_file ]; then
  while IFS="|" read -r action arg
  do
    case $action in
      "insmod") insmod $arg ;;
      "setprop") setprop $arg 1 ;;
      "enable") echo 1 > $arg ;;
      "modprobe") modprobe -a -d /vendor/lib/modules $arg ;;
     . . .
    esac
  done < $cfg_file
fi

हार्डवेयर आरसी फ़ाइल में, one shot सेवा को इसके साथ निर्दिष्ट किया जा सकता है:

service insmod-sh /vendor/etc/init.insmod.sh /vendor/etc/init.insmod.<hw>.cfg
    class main
    user root
    group root system
    Disabled
    oneshot

मॉड्यूल के पहले से दूसरे चरण में जाने के बाद अतिरिक्त अनुकूलन किए जा सकते हैं। आप गैर-आवश्यक मॉड्यूल की विलंबित मॉड्यूल लोडिंग को शामिल करने के लिए दूसरे चरण के बूट प्रवाह को विभाजित करने के लिए मॉडप्रोब ब्लॉकलिस्ट सुविधा का उपयोग कर सकते हैं। किसी विशिष्ट एचएएल द्वारा विशेष रूप से उपयोग किए जाने वाले मॉड्यूल की लोडिंग को केवल एचएएल शुरू होने पर ही मॉड्यूल को लोड करने के लिए स्थगित किया जा सकता है।

स्पष्ट बूट समय में सुधार करने के लिए, आप विशेष रूप से मॉड्यूल लोडिंग सेवा में मॉड्यूल चुन सकते हैं जो लॉन्च स्क्रीन के बाद लोड करने के लिए अधिक अनुकूल हैं। उदाहरण के लिए, इनिट बूट प्रवाह साफ़ होने के बाद आप वीडियो डिकोडर या वाईफाई के लिए मॉड्यूल को स्पष्ट रूप से देर से लोड कर सकते हैं (उदाहरण के लिए sys.boot_complete Android प्रॉपर्टी सिग्नल)। सुनिश्चित करें कि कर्नेल ड्राइवर मौजूद न होने पर देर से लोड होने वाले मॉड्यूल के लिए HAL काफी देर तक ब्लॉक रहें।

वैकल्पिक रूप से, आप चुनिंदा sysfs प्रविष्टियों की प्रतीक्षा करने के लिए बूट फ्लो आरसी स्क्रिप्टिंग में init के wait<file>[<timeout>] कमांड का उपयोग कर सकते हैं ताकि यह दिखाया जा सके कि ड्राइवर मॉड्यूल ने जांच संचालन पूरा कर लिया है। इसका एक उदाहरण मेनू ग्राफिक्स प्रस्तुत करने से पहले रिकवरी या fastbootd की पृष्ठभूमि में डिस्प्ले ड्राइवर के लोड होने की प्रतीक्षा करना है।

बूटलोडर में सीपीयू आवृत्ति को उचित मूल्य पर प्रारंभ करें

बूट लूप परीक्षणों के दौरान थर्मल या पावर संबंधी चिंताओं के कारण सभी एसओसी/उत्पाद सीपीयू को उच्चतम आवृत्ति पर बूट करने में सक्षम नहीं हो सकते हैं। हालाँकि, सुनिश्चित करें कि बूटलोडर SoC/उत्पाद के लिए सभी ऑनलाइन सीपीयू की आवृत्ति को यथासंभव सुरक्षित रूप से उच्च पर सेट करता है। यह बहुत महत्वपूर्ण है क्योंकि, पूरी तरह से मॉड्यूलर कर्नेल के साथ, CPUfreq ड्राइवर को लोड करने से पहले init रैमडिस्क डीकंप्रेसन होता है। इसलिए, यदि बूटलोडर द्वारा सीपीयू को उसकी आवृत्ति के निचले सिरे पर छोड़ दिया जाता है, तो रैमडिस्क डीकंप्रेसन का समय स्थिर रूप से संकलित कर्नेल (रैमडिस्क आकार अंतर के लिए समायोजन के बाद) से अधिक समय ले सकता है क्योंकि सीपीयू गहन करते समय सीपीयू आवृत्ति बहुत कम होगी कार्य (डीकंप्रेसन)। यही बात मेमोरी/इंटरकनेक्ट फ़्रीक्वेंसी पर भी लागू होती है।

बूटलोडर में बड़े सीपीयू की सीपीयू आवृत्ति प्रारंभ करें

CPUfreq ड्राइवर लोड होने से पहले, कर्नेल छोटी और बड़ी सीपीयू आवृत्तियों से अनजान होता है और सीपीयू की निर्धारित क्षमता को उनकी वर्तमान आवृत्ति के लिए स्केल नहीं करता है। यदि छोटे सीपीयू पर लोड पर्याप्त रूप से अधिक है तो कर्नेल थ्रेड्स को बड़े सीपीयू में स्थानांतरित कर सकता है।

सुनिश्चित करें कि जिस आवृत्ति पर बूटलोडर उन्हें छोड़ता है, उस आवृत्ति के लिए बड़े सीपीयू कम से कम छोटे सीपीयू के समान प्रदर्शन करने वाले होते हैं। उदाहरण के लिए, यदि बड़ा सीपीयू समान आवृत्ति के लिए छोटे सीपीयू की तुलना में 2 गुना अधिक प्रदर्शन करता है, लेकिन बूटलोडर सेट करता है छोटे सीपीयू की आवृत्ति 1.5 गीगाहर्ट्ज तक और बड़े सीपीयू की आवृत्ति 300 मेगाहर्ट्ज तक, यदि कर्नेल एक थ्रेड को बड़े सीपीयू में ले जाता है तो बूट प्रदर्शन गिर जाएगा। इस उदाहरण में, यदि बड़े सीपीयू को 750 मेगाहर्ट्ज पर बूट करना सुरक्षित है, तो आपको ऐसा करना चाहिए, भले ही आप इसे स्पष्ट रूप से उपयोग करने की योजना नहीं बनाते हों।

ड्राइवरों को फ़र्मवेयर को प्रथम चरण init में लोड नहीं करना चाहिए

ऐसे कुछ अपरिहार्य मामले हो सकते हैं जहां फ़र्मवेयर को पहले चरण init में लोड करने की आवश्यकता होती है। लेकिन सामान्य तौर पर, ड्राइवरों को पहले चरण के इनिट में कोई भी फर्मवेयर लोड नहीं करना चाहिए, खासकर डिवाइस जांच के संदर्भ में। फ़र्म चरण init में फ़र्मवेयर लोड करने से संपूर्ण बूट प्रक्रिया रुक जाती है यदि फ़र्मवेयर प्रथम चरण रैमडिस्क में उपलब्ध नहीं है। और भले ही फर्मवेयर पहले चरण के रैमडिस्क में मौजूद हो, फिर भी यह अनावश्यक देरी का कारण बनता है।