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

এই পৃষ্ঠাটি টিপসের একটি সেট প্রদান করে, যেগুলি থেকে আপনি বুট করার সময় উন্নত করতে বেছে নিতে পারেন।

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

প্রোডাকশন ডিভাইসে কার্নেল থেকে ডিবাগ চিহ্নগুলি কীভাবে ছিনতাই করা হয় তার অনুরূপ, নিশ্চিত করুন যে আপনি মডিউল থেকে ডিবাগ প্রতীকগুলিও ছিনিয়ে নিয়েছেন। মডিউলগুলি থেকে ডিবাগ চিহ্নগুলি স্ট্রিপ করা নিম্নলিখিতগুলি হ্রাস করে বুট সময়কে সহায়তা করে:

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

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

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

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

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

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

LZ4 এ স্যুইচ করলে 500ms থেকে 1000ms দ্রুত বুট টাইম পাওয়া যাবে।

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

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

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

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

বিদ্যমান লগিং কতটা অত্যধিক তার উপর নির্ভর করে বুট টাইমে প্রায় 100 - 300ms সংরক্ষণ করতে পারে লগিং হ্রাস করা।

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

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

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

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

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

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

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

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

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

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

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

দ্বিতীয় পর্যায়ের init, vendor বা vendor_dlkm পার্টিশনে মডিউল সরান

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

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

নিম্নলিখিত অপরিহার্য ড্রাইভার লোড করুন:

• প্রহরী
• রিসেট
• cpufreq

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

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

মডিউলগুলিকে দ্বিতীয় পর্যায়ের init-এ সরানো হলে নিম্নলিখিত উপায়ে বুট সময় হ্রাস পায়:

• রামডিস্কের আকার হ্রাস।
  • বুটলোডার যখন রামডিস্ক (ক্রমিক বুট ধাপ) লোড করে তখন এটি দ্রুত ফ্ল্যাশ রিড দেয়।
  • কার্নেল রামডিস্ক (ক্রমিক বুট ধাপ) ডিকম্প্রেস করলে এটি দ্রুত ডিকম্প্রেশন গতি দেয়।
• দ্বিতীয় পর্যায়ের init সমান্তরালভাবে কাজ করে, যা দ্বিতীয় পর্যায়ের init-এ কাজ করার সাথে মডিউলের লোডিং সময় লুকিয়ে রাখে।

দ্বিতীয় পর্যায়ে মডিউল সরানো বুট সময়ে 500 - 1000ms সংরক্ষণ করতে পারে আপনি কত মডিউল দ্বিতীয় পর্যায়ে যেতে পারবেন তার উপর নির্ভর করে।

মডিউল লোডিং রসদ

সর্বশেষ অ্যান্ড্রয়েড বিল্ডে বোর্ড কনফিগারেশনের বৈশিষ্ট্য রয়েছে যা নিয়ন্ত্রণ করে কোন মডিউল প্রতিটি পর্যায়ে কপি করা হবে এবং কোন মডিউল লোড হবে। এই বিভাগটি নিম্নলিখিত উপসেটের উপর দৃষ্টি নিবদ্ধ করে:

• 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.

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

দ্বিতীয় পর্যায়ের init-এর জন্য, আমরা মডিউল লোডিং একটি পরিষেবা হিসাবে চালানোর পরামর্শ দিই যাতে এটি বুট প্রবাহকে বাধা না দেয়। মডিউল লোডিং পরিচালনা করার জন্য একটি শেল স্ক্রিপ্ট ব্যবহার করুন যাতে অন্যান্য লজিস্টিক, যেমন ত্রুটি পরিচালনা এবং প্রশমন, বা মডিউল লোড সমাপ্তি, প্রয়োজনে আবার রিপোর্ট করা যেতে পারে (বা উপেক্ষা করা)।

আপনি একটি ডিবাগ মডিউল লোড ব্যর্থতা উপেক্ষা করতে পারেন যা ব্যবহারকারী বিল্ডে উপস্থিত নয়। এই ব্যর্থতা উপেক্ষা করার জন্য, লঞ্চ স্ক্রিনে চালিয়ে যেতে 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

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

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

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

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

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

বুটলোডারে বড় CPU-এর CPU ফ্রিকোয়েন্সি শুরু করুন

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

বুটলোডার যে ফ্রিকোয়েন্সিতে তাদের ছেড়ে দেয় তার জন্য বড় CPU গুলি অন্তত ছোট CPU-র মতো পারফরম্যান্স করে তা নিশ্চিত করুন। উদাহরণস্বরূপ, যদি বড় CPU একই ফ্রিকোয়েন্সির জন্য ছোট CPU-এর মতো 2x পারফরম্যান্ট হয়, কিন্তু বুটলোডার সেট করে ছোট CPU-এর ফ্রিকোয়েন্সি 1.5 GHz এবং বড় CPU-এর ফ্রিকোয়েন্সি 300 MHz, তারপর কার্নেল বড় CPU-তে একটি থ্রেড স্থানান্তর করলে বুট কর্মক্ষমতা কমে যাবে। এই উদাহরণে, 750 MHz-এ বড় CPU বুট করা নিরাপদ হলে, আপনি স্পষ্টভাবে এটি ব্যবহার করার পরিকল্পনা না করলেও তা করা উচিত।

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

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