বুট টাইম অপ্টিমাইজেশন

এই পৃষ্ঠায় বুট টাইম উন্নত করার ব্যাপারে পরামর্শ দেওয়া হয়েছে।

মডিউল থেকে ডিবাগ সিম্বল স্ট্রিপ করুন

প্রোডাকশন ডিভাইসে যেভাবে কার্নেল থেকে ডিবাগ সিম্বল সরিয়ে দেওয়া হয়, সেই একই পদ্ধতিতে মডিউল থেকেও ডিবাগ সিম্বল সরিয়ে দিতে ভুলবেন না। মডিউল থেকে ডিবাগ সিম্বল সরিয়ে দিলে নিম্নলিখিত বিষয়গুলি কমানোর মাধ্যমে বুট করার সময় কম লাগে:

• ফ্ল্যাশ থেকে বাইনারি পড়তে যে সময় লাগে।
• রামডিস্ক ডিকম্প্রেস করতে যে সময় লাগে।
• মডিউল লোড হতে যে সময় লাগে।

মডিউল থেকে ডিবাগ সিম্বল বাদ দিলে বুট করার সময় কয়েক সেকেন্ড বাঁচানো যেতে পারে।

Android প্ল্যাটফর্ম বিল্ডে ডিফল্ট হিসেবে সিম্বল স্ট্রিপিং চালু করা থাকে, কিন্তু সেগুলি স্পষ্টভাবে চালু করতে, আপনার ডিভাইস-নির্দিষ্ট কনফিগে BOARD_DO_NOT_STRIP_VENDOR_RAMDISK_MODULES সেট করুন device/vendor/device-এর অধীনে।

কার্নেল ও র‍্যামডিস্কের জন্য LZ4 কম্প্রেশন ব্যবহার করুন

LZ4-এর তুলনায় Gzip কম সাইজের কম্প্রেস করা আউটপুট তৈরি করে, কিন্তু LZ4 Gzip-এর তুলনায় দ্রুত ডিকম্প্রেস করে। কার্নেল ও মডিউলের ক্ষেত্রে, Gzip ব্যবহার করার ফলে স্টোরেজের আসল সাইজ যতটা কমে, LZ4-এর ক্ষেত্রে ডিকম্প্রেশন টাইম অনেক কম লাগে।

Android প্ল্যাটফর্মে LZ4 ramdisk কম্প্রেশন কাজ করে BOARD_RAMDISK_USE_LZ4-এর মাধ্যমে বিল্ড করা হয়েছে। আপনি এই বিকল্পটি আপনার ডিভাইস-নির্দিষ্ট কনফিগারেশনে সেট করতে পারেন। কার্নেল ডিফকনফিগের মাধ্যমে কার্নেল কম্প্রেশন সেট করা যেতে পারে।

LZ4-এ পরিবর্তন করলে বুট টাইম ৫০০ থেকে ১০০০ মিলি সেকেন্ড কমে যাবে।

আপনার ড্রাইভারদের অতিরিক্ত লগ-ইন করা এড়িয়ে চলুন

ARM64 এবং ARM32-এ, কল সাইট থেকে নির্দিষ্ট দূরত্বের বেশি ফাংশন কলের জন্য সম্পূর্ণ জাম্প অ্যাড্রেস এনকোড করার জন্য জাম্প টেবিল (প্রসিডিওর লিঙ্কিং টেবিল বা PLT বলা হয়) প্রয়োজন। মডিউল ডায়নামিক লোড করা হয় বলে, মডিউল লোড করার সময় এই জাম্প টেবিলগুলি ঠিক করতে হবে। যেসব কলকে রিলোকেট করতে হয় সেগুলিকে এক্সপ্লিসিট অ্যাডেন্ড (বা সংক্ষেপে RELA) সহ রিলোকেশন এন্ট্রি বলা হয়, যা ELF ফর্ম্যাটে থাকে।

PLT অ্যাসাইন করার সময় Linux কার্নেল কিছু মেমরি সাইজ অপ্টিমাইজেশন (যেমন, ক্যাশে হিট অপ্টিমাইজেশন) করে। এই আপস্ট্রিম কমিট-এর সাথে, অপ্টিমাইজেশন স্কিমের O(N^2) জটিলতা আছে, যেখানে N হল R_AARCH64_JUMP26 বা R_AARCH64_CALL26 ধরনের RELAs-এর সংখ্যা। তাই, এই ধরনের কম RELA থাকলে মডিউল লোড হওয়ার সময় কমে যায়।

একটি সাধারণ কোডিং প্যাটার্ন যা R_AARCH64_CALL26 বা R_AARCH64_JUMP26 RELA-এর সংখ্যা বাড়ায় তা হল ড্রাইভারের মধ্যে অত্যধিক লগিং। printk()-এ প্রতিটি কল বা অন্য কোনও লগিং স্কিম সাধারণত একটি CALL26/JUMP26 RELA এন্ট্রি যোগ করে। আপস্ট্রিম কমিট টেক্সটে কমিট করুন, ,লক্ষ্য করুন যে অপ্টিমাইজেশন করা সত্ত্বেও, ছয়টি মডিউল লোড হতে প্রায় ২৫০ms সময় লাগে—এর কারণ হল, এই ছয়টি মডিউল হল সবচেয়ে বেশি লগ করা টপ ছয়টি মডিউল।

লগিং কমানোর ফলে বুট করার সময় ১০০ - ৩০০ মিলি সেকেন্ড বাঁচানো যেতে পারে। এটি নির্ভর করে বর্তমান লগিং কতটা বেশি তার উপর।

অ্যাসিঙ্ক্রোনাস প্রোবিং চালু করুন, বেছে বেছে

কোনও মডিউল লোড করা হলে, এটি কাজ করে এমন ডিভাইসে যদি DT (ডিভাইস ট্রি) থেকে আগে থেকেই ডেটা যোগ করা থাকে এবং ড্রাইভার কোরে যোগ করা থাকে, তাহলে module_init() কলের কনটেক্সটে ডিভাইস প্রোব করা হয়। module_init()-এর প্রসঙ্গে কোনও ডিভাইস প্রোব করা হলে, প্রোব সম্পূর্ণ না হওয়া পর্যন্ত মডিউল লোড করা শেষ করতে পারে না। মডিউল লোডিং বেশিরভাগ ক্ষেত্রেই সিরিয়ালাইজ করা হয়, তাই কোনও ডিভাইসকে প্রোব করতে তুলনামূলকভাবে বেশি সময় লাগলে বুট টাইম কমে যায়।

বুট করার সময় যাতে বেশি সময় না লাগে, তার জন্য যে মডিউলগুলি তাদের ডিভাইস প্রোব করতে কিছু সময় নেয় সেগুলির জন্য অ্যাসিঙ্ক্রোনাস প্রোবিং চালু করুন। সব মডিউলের জন্য অ্যাসিঙ্ক্রোনাস প্রোবিং চালু করলে সুবিধা নাও হতে পারে, কারণ একটি থ্রেড ফর্ক করতে এবং প্রোব চালু করতে যতটা সময় লাগে তা ডিভাইস প্রোব করার জন্য প্রয়োজনীয় সময়ের সমান হতে পারে।

I2C-এর মতো স্লো বাসের মাধ্যমে কানেক্ট করা ডিভাইস, প্রোব ফাংশনে ফার্মওয়্যার লোড করা ডিভাইস এবং অনেক হার্ডওয়্যার ইনিশিয়ালাইজেশন করা ডিভাইসের ক্ষেত্রে টাইমিং সংক্রান্ত সমস্যা হতে পারে। এটি কখন ঘটে তা শনাক্ত করার সেরা উপায় হল প্রতিটি ড্রাইভারের জন্য প্রোব টাইম সংগ্রহ করা এবং এটি সাজানো।

মডিউলের জন্য অ্যাসিঙ্ক্রোনাস প্রোবিং চালু করতে, ড্রাইভার কোডে শুধু PROBE_PREFER_ASYNCHRONOUS ফ্ল্যাগ সেট করলেই হবে না। মডিউলের ক্ষেত্রে, আপনাকে module_name.async_probe=1 কার্নেল কমান্ড লাইনে যোগ করতে হবে অথবা modprobe বা insmod ব্যবহার করে মডিউল লোড করার সময় async_probe=1-কে মডিউল প্যারামিটার হিসেবে পাস করতে হবে।

অ্যাসিঙ্ক্রোনাস প্রোবিং চালু করলে, আপনার হার্ডওয়্যার/ড্রাইভারের উপর নির্ভর করে বুট করার সময় প্রায় ১০০ - ৫০০ms বাঁচানো যেতে পারে।

যত তাড়াতাড়ি সম্ভব আপনার CPUfreq ড্রাইভারকে প্রোব করুন

আপনার CPUfreq ড্রাইভার যত তাড়াতাড়ি প্রোব করবে, বুট করার সময় আপনি তত তাড়াতাড়ি CPU ফ্রিকোয়েন্সি সর্বোচ্চ (বা কিছু থার্মালি সীমিত সর্বোচ্চ) স্কেল করতে পারবেন। CPU যত দ্রুত হবে, বুট তত দ্রুত হবে। এই নির্দেশিকা devfreq DRAM, মেমরি ও ইন্টারকানেক্ট ফ্রিকোয়েন্সি কন্ট্রোল করে এমন ড্রাইভারের ক্ষেত্রেও প্রযোজ্য।

মডিউল ব্যবহার করলে, লোড করার ক্রম initcall লেভেল এবং ড্রাইভারের কম্পাইল বা লিঙ্ক করার ক্রমের উপর নির্ভর করতে পারে। cpufreq ড্রাইভার যাতে প্রথম কয়েকটা মডিউলের মধ্যে লোড হয় তা নিশ্চিত করতে একটি ছদ্মনাম MODULE_SOFTDEP() ব্যবহার করুন।

মডিউলটি আগে লোড করা ছাড়াও, আপনাকে এটিও নিশ্চিত করতে হবে যে CPUfreq ড্রাইভারকে প্রোব করার জন্য প্রয়োজনীয় সমস্ত নির্ভরতাও প্রোব করা হয়েছে। যেমন, আপনার CPU-এর ফ্রিকোয়েন্সি কন্ট্রোল করার জন্য ক্লক বা রেগুলেটর হ্যান্ডেলের প্রয়োজন হলে, সেগুলি প্রথমে প্রোব করা হয়েছে কিনা তা নিশ্চিত করুন। অথবা, বুট আপের সময় আপনার CPU খুব গরম হয়ে যাওয়ার সম্ভাবনা থাকলে, CPUfreq ড্রাইভারের আগে থার্মাল ড্রাইভার লোড করতে হতে পারে। তাই, CPUfreq এবং প্রাসঙ্গিক devfreq ড্রাইভার যত তাড়াতাড়ি সম্ভব প্রোব করার জন্য যা যা করতে পারেন করুন।

আপনার CPUfreq ড্রাইভারকে আগেভাগে প্রোব করার ফলে হওয়া সেভিংস খুব ছোট থেকে খুব বড় হতে পারে, এটি নির্ভর করে আপনি কত আগে এগুলিকে প্রোব করতে পারছেন এবং বুটলোডার কত ফ্রিকোয়েন্সিতে CPU-কে ছেড়ে দিচ্ছে তার উপর।

মডিউলগুলিকে সেকেন্ড স্টেজ ইনিট, ভেন্ডর বা vendor_dlkm পার্টিশনে সরানো

প্রথম স্টেজের ইনিট প্রসেস সিরিয়ালাইজ করা হয় বলে, বুট প্রসেসকে প্যারালাইজ করার সুযোগ খুব কম থাকে। প্রথম পর্যায়ের init শেষ করার জন্য কোনও মডিউলের প্রয়োজন না হলে, সেটিকে ভেন্ডর বা vendor_dlkm পার্টিশনে রেখে দ্বিতীয় পর্যায়ের init-এ সরিয়ে দিন।

প্রথম স্টেজে ইনিশিয়ালাইজ করার জন্য দ্বিতীয় স্টেজে ইনিশিয়ালাইজ করার জন্য একাধিক ডিভাইস প্রোব করার প্রয়োজন নেই। সাধারণ বুট ফ্লোয়ের জন্য শুধু কনসোল ও ফ্ল্যাশ স্টোরেজ ক্ষমতা প্রয়োজন।

নিম্নলিখিত প্রয়োজনীয় ড্রাইভার লোড করুন:

• watchdog
• reset
• cpufreq

রিকভারি ও ইউজার স্পেস fastbootd মোডের জন্য, প্রথম পর্যায়ের init-এর আরও ডিভাইস প্রোব (যেমন USB) ও ডিসপ্লে প্রয়োজন। প্রথম স্টেজের র‍্যামডিস্ক এবং ভেন্ডর বা vendor_dlkm পার্টিশনে এইসব মডিউলের কপি রাখুন। এর ফলে সেগুলি রিকভারি বা fastbootd বুট ফ্লোয়ের জন্য প্রথম স্টেজে লোড করা যায়। তবে, সাধারণ বুট ফ্লো চলাকালীন প্রথম স্টেজে রিকভারি মোড মডিউল লোড করবেন না। বুট টাইম কমানোর জন্য রিকভারি মোড মডিউলকে সেকেন্ড স্টেজ ইনিটে ডিফার করা যেতে পারে। প্রথম স্টেজে ইনিশিয়ালাইজ করার জন্য প্রয়োজন নেই এমন অন্যান্য সব মডিউলকে ভেন্ডর বা vendor_dlkm পার্টিশনে সরাতে হবে।

লিফ ডিভাইসের একটি তালিকা (যেমন, UFS বা সিরিয়াল) দেওয়া হলে, dev needs.sh ডিপেন্ডেন্সি বা সাপ্লায়ারদের (যেমন, ক্লক, রেগুলেটর বা gpio) প্রোব করার জন্য প্রয়োজনীয় সমস্ত ড্রাইভার, ডিভাইস এবং মডিউল স্ক্রিপ্ট খুঁজে পায়।

মডিউলগুলিকে সেকেন্ড স্টেজ ইনিটে সরানো হলে, নিম্নলিখিত উপায়ে বুট টাইম কমে যায়:

• Ramdisk-এর সাইজ কমানো।
  • বুটলোডার র‍্যামডিস্ক লোড করার সময় এটি আরও দ্রুত ফ্ল্যাশ রিড করে (সিরিয়ালাইজ করা বুট স্টেপ)।
  • এর ফলে, কার্নেল যখন ramdisk (সিরিয়ালাইজ করা বুট স্টেপ) ডিকম্প্রেস করে, তখন ডিকম্প্রেশন স্পিড আরও বেশি হয়।
• সেকেন্ড স্টেজ ইনিট প্যারালাল প্রসেসে কাজ করে, যা সেকেন্ড স্টেজ ইনিটে করা কাজের সাথে মডিউল লোডিং টাইম লুকিয়ে রাখে।

মডিউলগুলিকে দ্বিতীয় স্টেজে নিয়ে গেলে, আপনি কতগুলি মডিউলকে দ্বিতীয় স্টেজে নিয়ে যেতে পারছেন তার উপর নির্ভর করে, বুট করার সময় ৫০০ - ১০০০ms সেভ করা যেতে পারে।

মডিউল লোডিং লজিস্টিকস

লেটেস্ট Android বিল্ডে বোর্ড কনফিগারেশন ফিচার থাকে যা কন্ট্রোল করে কোন কোন মডিউল প্রতিটি স্টেজে কপি করা হবে এবং কোন কোন মডিউল লোড করা হবে। এই বিভাগে নিম্নলিখিত সাবসেটের উপর ফোকাস করা হয়:

• BOARD_VENDOR_RAMDISK_KERNEL_MODULES. মডিউলের এই তালিকা ramdisk-এ কপি করা হবে।
• BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. ফার্স্ট স্টেজ ইনিটে লোড করা হবে এমন মডিউলের এই তালিকা।
• BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD. রিকভারি বা fastbootd বেছে নেওয়া হলে, ramdisk থেকে লোড করার জন্য মডিউলের এই তালিকা।
• BOARD_VENDOR_KERNEL_MODULES. এই মডিউলগুলির তালিকা /vendor/lib/modules/ ডিরেক্টরিতে ভেন্ডর বা vendor_dlkm পার্টিশনে কপি করতে হবে।
• BOARD_VENDOR_KERNEL_MODULES_LOAD. দ্বিতীয় পর্যায়ের ইনিশিয়ালাইজেশনে লোড করার জন্য মডিউলের তালিকা।

এছাড়াও, ramdisk-এর বুট ও রিকভারি মডিউল অবশ্যই ভেন্ডর বা vendor_dlkm পার্টিশনে /vendor/lib/modules কপি করতে হবে। এইসব মডিউল ভেন্ডর পার্টিশনে কপি করলে, সেকেন্ড স্টেজ init-এর সময় মডিউলগুলি অদৃশ্য হয়ে যায় না, যা ডিবাগিং এবং বাগ রিপোর্টের জন্য 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

মডিউল প্রথম থেকে দ্বিতীয় ধাপে যাওয়ার পরে অতিরিক্ত অপ্টিমাইজেশন করা যেতে পারে। আপনি modprobe blocklist ফিচার ব্যবহার করে দ্বিতীয় স্টেজ বুট ফ্লোকে ভাগ করতে পারেন যাতে অপ্রয়োজনীয় মডিউল লোড করা ডিফার করা যায়। শুধুমাত্র নির্দিষ্ট HAL-এর মাধ্যমে ব্যবহার করা মডিউল লোড করার প্রসেস পিছিয়ে দেওয়া যেতে পারে যাতে HAL চালু হওয়ার পরেই মডিউল লোড করা হয়।

বুট টাইম আরও কম করতে, আপনি মডিউল লোডিং পরিষেবাতে এমন মডিউল বেছে নিতে পারেন যা লঞ্চ স্ক্রিনের পরে লোড করার জন্য আরও উপযুক্ত। যেমন, আপনি স্পষ্টভাবে ভিডিও ডিকোডার বা ওয়াই-ফাইয়ের জন্য মডিউলগুলি দেরিতে লোড করতে পারেন ইনিট বুট ফ্লো মুছে ফেলার পরে (sys.boot_complete Android প্রপার্টি সিগন্যাল, উদাহরণস্বরূপ)। কার্নেল ড্রাইভার না থাকলে, লেট লোডিং মডিউলের জন্য HAL যাতে যথেষ্ট সময় ধরে ব্লক করে তা নিশ্চিত করুন।

বিকল্প হিসেবে, আপনি বুট ফ্লো rc স্ক্রিপ্টিংয়ে init-এর wait<file>[<timeout>] কমান্ড ব্যবহার করে বেছে নেওয়া sysfs এন্ট্রি দেখানোর জন্য অপেক্ষা করতে পারেন, এর মাধ্যমে বোঝা যাবে যে ড্রাইভার মডিউল প্রোব অপারেশন সম্পূর্ণ করেছে। এর একটি উদাহরণ হল, মেনু গ্রাফিক্স দেখানোর আগে রিকভারি বা fastbootd-এর ব্যাকগ্রাউন্ডে ডিসপ্লে ড্রাইভার লোড করা সম্পূর্ণ হওয়ার জন্য অপেক্ষা করা।

বুটলোডারে CPU ফ্রিকোয়েন্সি একটি যুক্তিসঙ্গত ভ্যালুতে ইনিশিয়ালাইজ করা

বুট লুপ টেস্টের সময় থার্মাল বা পাওয়ার সংক্রান্ত সমস্যার কারণে সব SoC/প্রোডাক্ট সর্বোচ্চ ফ্রিকোয়েন্সিতে CPU বুট করতে নাও পারে। তবে, নিশ্চিত করুন যে বুটলোডার সব অনলাইন সিপিইউ-এর ফ্রিকোয়েন্সি SoC বা প্রোডাক্টের জন্য নিরাপদে সম্ভব সর্বোচ্চ হিসেবে সেট করে। এটি খুবই গুরুত্বপূর্ণ কারণ, সম্পূর্ণ মডুলার কার্নেলের ক্ষেত্রে, CPUfreq ড্রাইভার লোড করার আগে init ramdisk ডিকম্প্রেশন হয়। তাই, বুটলোডার যদি সিপিইউ-কে তার ফ্রিকোয়েন্সির নিচের দিকে রেখে দেয়, তাহলে র‍্যামডিস্ক ডিকম্প্রেশন করতে স্ট্যাটিক্যালি কম্পাইল করা কার্নেলের চেয়ে বেশি সময় লাগতে পারে (র‍্যামডিস্কের সাইজের পার্থক্যের জন্য অ্যাডজাস্ট করার পরে) কারণ সিপিইউ-ইনটেনসিভ কাজ (ডিকম্প্রেশন) করার সময় সিপিইউ ফ্রিকোয়েন্সি খুব কম থাকবে। মেমরি ও ইন্টারকানেক্ট ফ্রিকোয়েন্সির ক্ষেত্রেও একই বিষয় প্রযোজ্য।

বুটলোডারে বড় সিপিইউয়ের সিপিইউ ফ্রিকোয়েন্সি ইনিশিয়ালাইজ করা

CPUfreq ড্রাইভার লোড হওয়ার আগে, কার্নেল CPU ফ্রিকোয়েন্সি সম্পর্কে অবগত থাকে না এবং বর্তমান ফ্রিকোয়েন্সির জন্য CPU শিডিউল ক্যাপাসিটি স্কেল করে না। ছোট সিপিইউতে লোড যথেষ্ট বেশি হলে, কার্নেল থ্রেডগুলিকে বড় সিপিইউতে মাইগ্রেট করতে পারে।

বুটলোডার যে ফ্রিকোয়েন্সিতে বড় সিপিইউগুলিকে ছেড়ে দেয়, সেই ফ্রিকোয়েন্সিতে বড় সিপিইউগুলি যেন অন্তত ছোট সিপিইউগুলির মতো পারফর্ম করে তা নিশ্চিত করুন। যেমন, একই ফ্রিকোয়েন্সির জন্য বড় CPU যদি ছোট CPU-এর তুলনায় ২ গুণ বেশি পারফর্ম্যান্স দেয়, কিন্তু বুটলোডার যদি ছোট CPU-এর ফ্রিকোয়েন্সি ১.৫ GHz এবং বড় CPU-এর ফ্রিকোয়েন্সি ৩০০ MHz-এ সেট করে, তাহলে কার্নেল যদি কোনও থ্রেড বড় CPU-তে সরিয়ে দেয়, তাহলে বুট পারফর্ম্যান্স কমে যাবে। এই উদাহরণে, যদি 750 MHz-এ big CPU বুট করা নিরাপদ হয়, তাহলে আপনার এটি করা উচিত, এমনকি আপনি যদি এটি স্পষ্টভাবে ব্যবহার করার পরিকল্পনা না করেন।

ড্রাইভারদের ফার্স্ট স্টেজ ইনিটে ফার্মওয়্যার লোড করা উচিত নয়

কিছু অনিবার্য ক্ষেত্রে, প্রথম পর্যায়ের ইনিটে ফার্মওয়্যার লোড করতে হতে পারে। তবে, সাধারণভাবে, ড্রাইভারদের প্রথম স্টেজ ইনিটে কোনও ফার্মওয়্যার লোড করা উচিত নয়, বিশেষ করে ডিভাইস প্রোব প্রসঙ্গে। ফার্স্ট স্টেজ init-এ ফার্মওয়্যার লোড করা ফার্স্ট স্টেজ র‍্যামডিস্কে ফার্মওয়্যার উপলভ্য না থাকলে সম্পূর্ণ বুট প্রসেস বন্ধ করে দেয়। এমনকি ফার্মওয়্যার যদি প্রথম স্টেজের রামডিস্কে থাকে, তাহলেও এটি অপ্রয়োজনীয় বিলম্ব ঘটায়।