डिवाइस चालू होने में लगने वाले समय को ऑप्टिमाइज़ करना

इस पेज पर, डिवाइस बूट होने में लगने वाले समय को कम करने के बारे में सलाह दी गई है.

मॉड्यूल से डीबग सिंबल को निकालें

प्रोडक्शन पर कर्नेल से डीबग सिंबल को कैसे हटाया जाता है डिवाइस का इस्तेमाल कर रहे हैं, तो यह पक्का करें कि आपने मॉड्यूल से डीबग सिंबल को भी निकाल दिया हो. स्ट्रिपिंग डीबग मॉड्यूल में उपलब्ध चिह्नों की मदद से बूट टाइम में इन्हें कम किया जा सकता है:

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

मॉड्यूल से डीबग सिंबल हटाने पर, बूट होने में कुछ सेकंड कम लग सकते हैं.

Android प्लैटफ़ॉर्म के बिल्ड में सिंबल स्ट्रिपिंग की सुविधा डिफ़ॉल्ट रूप से चालू होती है, लेकिन साफ़ तौर पर उन्हें चालू करने के लिए, आपके डिवाइस के हिसाब से कॉन्फ़िगरेशन में BOARD_DO_NOT_STRIP_VENDOR_RAMDISK_MODULES डिवाइस/vendor/device के तहत.

कर्नेल और रैमडिस्क के लिए LZ4 कंप्रेसन का इस्तेमाल करना

Gzip, LZ4 की तुलना में छोटा कंप्रेस किया गया आउटपुट जनरेट करता है. हालांकि, LZ4, Gzip की तुलना में तेज़ी से डिकंप्रेस करता है. Gzip का इस्तेमाल करने से, स्टोरेज का साइज़ कम हो जाता है. हालांकि, LZ4 की तुलना में, यह फ़ायदा उतना ज़्यादा नहीं है. LZ4 का इस्तेमाल करने पर, डेटा को डिकंप्रेस करने में कम समय लगता है.

अब Android प्लैटफ़ॉर्म पर, LZ4 रैमडिस्क कंप्रेशन की सुविधा भी उपलब्ध हो गई है BOARD_RAMDISK_USE_LZ4 से बिल्ड करें. इस विकल्प को, डिवाइस के हिसाब से कॉन्फ़िगरेशन में सेट किया जा सकता है. कर्नेल कंप्रेशन को kernel defconfig के ज़रिए सेट किया जा सकता है.

LZ4 पर स्विच करने से, डिवाइस को 500 से 1,000 मिलीसेकंड तक कम समय में बूट किया जा सकता है.

अपने ड्राइवर में ज़्यादा लॉगिंग से बचें

ARM64 और ARM32 में, ऐसे फ़ंक्शन कॉल जो तय दूरी से ज़्यादा हैं कॉल साइट को जंप टेबल (जिसे प्रोसेस लिंकिंग टेबल या PLT कहा जाता है) की ज़रूरत होती है, पूरे जंप पते को कोड में बदल सकता है. मॉड्यूल डाइनैमिक तौर पर लोड होते हैं, मॉड्यूल लोड के दौरान, इन जंप टेबल को ठीक करना ज़रूरी है. जिन कॉल को फिर से जगह तय करनी होती है उन्हें ELF फ़ॉर्मैट में, साफ़ तौर पर जोड़े गए एंडेंट (या छोटा नाम RELA) वाली रीलोकेशन एंट्री कहा जाता है.

PLT को असाइन करते समय, Linux kernel मेमोरी के साइज़ को ऑप्टिमाइज़ करता है. जैसे, कैश हिट ऑप्टिमाइज़ेशन. इस अपस्ट्रीम के साथ कमिट, ऑप्टिमाइज़ेशन स्कीम में एक O(N^2) जटिलता है, जहां N R_AARCH64_JUMP26 या R_AARCH64_CALL26 टाइप के RELAS. इसलिए, आपको कम रिलेटेड इनमें से मॉड्यूल के लोड होने का समय कम करने में मदद मिलती है.

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

लॉगिंग को कम करने से, बूट होने में लगने वाले समय में 100 से 300 मिलीसेकंड की बचत हो सकती है. यह इस बात पर निर्भर करता है कि मौजूदा लॉगिंग कितनी ज़्यादा है.

चुनिंदा तौर पर, एसिंक्रोनस प्रोबिंग की सुविधा चालू करना

जब कोई मॉड्यूल लोड होता है, तो अगर वह डिवाइस पहले से ही DT (डिवाइस ट्री) से भरा हुआ है और ड्राइवर कोर में जोड़ा गया है, तो module_init() कॉल के संदर्भ में डिवाइस की जांच की जाती है. जब डिवाइस की जांच की स्थिति module_init() के संदर्भ में किया गया है, तो मॉड्यूल तब तक लोड नहीं हो सकता, जब तक जांच पूरी हो जाती है. मॉड्यूल को आम तौर पर सीरियल नंबर के तौर पर लोड किया जाता है. इसलिए, ऐसा डिवाइस जो इसकी जांच में ज़्यादा समय लगता है. इससे बूट होने में लगने वाला समय कम हो जाता है.

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

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

किसी मॉड्यूल के लिए एसिंक्रोनस प्रोबिंग को चालू करने के लिए, यह सिर्फ़ PROBE_PREFER_ASYNCHRONOUS सेट करें फ़्लैग करें. मॉड्यूल के लिए, आपको यह भी जोड़ना होगा कर्नेल कमांड लाइन में module_name.async_probe=1 या मॉड्यूल लोड करते समय async_probe=1 को मॉड्यूल पैरामीटर के रूप में पास करें modprobe या insmod.

असाइनोक्रोनस प्रोबिंग की सुविधा चालू करने पर, आपके हार्डवेयर/ड्राइवर के हिसाब से, बूट होने में लगने वाले समय में 100 से 500 मिलीसेकंड का फ़ायदा मिल सकता है.

अपने सीपीयू ड्राइवर की जांच जल्द से जल्द करें

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

मॉड्यूल के लिए, लोड करने का क्रम initcall लेवल और ड्राइवर के क्रम के हिसाब से तय किया जा सकता है. MODULE_SOFTDEP() ड्राइवर को लोड होने वाले शुरुआती मॉड्यूल में शामिल करने के लिए, किसी दूसरे नाम का इस्तेमाल करें.

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

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

मॉड्यूल को दूसरे चरण के init, वेंडर याVendor_dlkm पार्टीशन में ले जाएं

पहले चरण की init प्रोसेस को क्रम से चलाया जाता है. इसलिए, बूट प्रोसेस को पैरलल में चलाने के बहुत कम अवसर होते हैं. अगर किसी मॉड्यूल की ज़रूरत नहीं है पहले चरण के चरण को पूरा करना बाकी है, तो मॉड्यूल को वेंडर या vendor_dlkm पार्टीशन में.

पहले स्टेज में दूसरे स्टेज पर जाने के लिए, कई डिवाइसों की जांच करने की ज़रूरत नहीं होती शुरू करें. केवल कंसोल और फ़्लैश मेमोरी क्षमताओं की आवश्यकता होती है सामान्य बूट फ़्लो हो.

ये ज़रूरी ड्राइवर लोड करें:

  • watchdog
  • reset
  • cpufreq

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

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

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

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

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

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

Android के नए बिल्ड की सुविधाओं के साथ बोर्ड कॉन्फ़िगरेशन की सुविधा मिलती है. इसकी मदद से, यह कंट्रोल किया जा सकता है कि मॉड्यूल हर चरण में कॉपी हो जाते हैं और कौनसे मॉड्यूल लोड होते हैं. इस सेक्शन में, इन सबसेट पर फ़ोकस किया गया है:

  • 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/lib/modules/ डायरेक्ट्री में वेंडर या vendor_dlkm पार्टीशन.
  • BOARD_VENDOR_KERNEL_MODULES_LOAD. दूसरे चरण के init में लोड किए जाने वाले मॉड्यूल की सूची.

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

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

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

इन कार्रवाइयों को करने के लिए, डिवाइस की 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 की जानकारी शामिल करें फ़ाइलें. पिछली स्क्रिप्ट चुने गए उपलब्ध कर्नेल मॉड्यूल के लिए, बाकी मॉड्यूल को कुछ सेकंड के लिए छोड़ दिया जाता है स्टेज इनिट.

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

डीबग मॉड्यूल लोड न होने की उस गड़बड़ी को अनदेखा किया जा सकता है जो उपयोगकर्ता के बिल्ड में मौजूद नहीं है. इस गड़बड़ी को अनदेखा करने के लिए, vendor.device.modules.ready प्रॉपर्टी को init rc स्क्रिप्टिंग बूटफ़्लो के बाद के चरणों को ट्रिगर करने के लिए सेट करें, ताकि लॉन्च स्क्रीन पर जाना जारी रखा जा सके. अगर आपके पास /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

हार्डवेयर rc फ़ाइल में, 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 प्रॉपर्टी सिग्नल). पक्का करें कि एचएएल, देर से लोड होने वाले हों कर्नेल ड्राइवर मौजूद न होने पर, मॉड्यूल ज़्यादा समय तक ब्लॉक रहते हैं.

इसके अलावा, बूट फ़्लो rc स्क्रिप्टिंग में init के wait<file>[<timeout>] कमांड का इस्तेमाल करके, चुनिंदा sysfs एंट्री के इंतज़ार किया जा सकता है. इससे यह पता चलता है कि ड्राइवर मॉड्यूल ने जांच के ऑपरेशन पूरे कर लिए हैं. इसका एक उदाहरण है रिकवरी के बैकग्राउंड में लोड होने की प्रोसेस पूरी करने के लिए ड्राइवर दिखाएं या fastbootd, मेन्यू के ग्राफ़िक को दिखाने से पहले.

बूटलोडर में, सीपीयू फ़्रीक्वेंसी को सही वैल्यू पर शुरू करें

ऐसा हो सकता है कि सभी SoC/प्रॉडक्ट, सबसे ज़्यादा फ़्रीक्वेंसी पर सीपीयू को बूट न कर पाएं. ऐसा, बूट लूप टेस्ट के दौरान थर्मल या पावर से जुड़ी समस्याओं की वजह से हो सकता है. हालांकि, पक्का करें कि बूटलोडर, सभी ऑनलाइन सीपीयू की फ़्रीक्वेंसी को सबसे सुरक्षित पर सेट करता है SoC या प्रॉडक्ट के लिए मुमकिन है. यह बहुत ज़रूरी है, क्योंकि पूरी तरह से मॉड्यूलर कर्नेल के अंदर, init ramdisk डीकंप्रेशन होता है जो CPUfreq से पहले होता है ड्राइवर लोड किया जा सकता है. इसलिए, अगर बूटलोडर की वजह से सीपीयू की फ़्रीक्वेंसी कम हो जाती है, तो रैमडिस्क को डिकंप्रेस करने में, स्टैटिक तौर पर कंपाइल किए गए कर्नेल से ज़्यादा समय लग सकता है. ऐसा इसलिए, क्योंकि सीपीयू पर ज़्यादा काम करने (डिकंप्रेस करने) पर, सीपीयू की फ़्रीक्वेंसी बहुत कम हो जाती है. यही बात मेमोरी और इंटरकनेक्ट फ़्रीक्वेंसी पर भी लागू होती है.

बूटलोडर में बड़े सीपीयू की सीपीयू फ़्रीक्वेंसी शुरू करें

CPUfreq ड्राइवर लोड होने से पहले, कर्नेल को सीपीयू फ़्रीक्वेंसी के बारे में पता नहीं होता. साथ ही, वह सीपीयू की मौजूदा फ़्रीक्वेंसी के लिए, शेड्यूल की गई सीपीयू क्षमता को स्केल नहीं करता. अगर छोटे सीपीयू पर लोड काफ़ी ज़्यादा है, तो हो सकता है कि कर्नेल, थ्रेड को बड़े सीपीयू पर माइग्रेट कर दे.

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

ड्राइवर को पहले चरण के शुरुआती दौर में फ़र्मवेयर लोड नहीं करना चाहिए

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