Tối ưu hoá thời gian khởi động

Trang này cung cấp các mẹo để cải thiện thời gian khởi động.

Xoá biểu tượng gỡ lỗi khỏi các mô-đun

Tương tự như cách các biểu tượng gỡ lỗi bị xoá khỏi nhân trên thiết bị sản xuất, hãy đảm bảo bạn cũng xoá các biểu tượng gỡ lỗi khỏi các mô-đun. Việc loại bỏ các biểu tượng gỡ lỗi khỏi các mô-đun giúp giảm thời gian khởi động bằng cách giảm những yếu tố sau:

  • Thời gian cần thiết để đọc các tệp nhị phân từ bộ nhớ flash.
  • Thời gian cần thiết để giải nén ramdisk.
  • Thời gian cần thiết để tải các mô-đun.

Việc loại bỏ biểu tượng gỡ lỗi khỏi các mô-đun có thể giúp bạn tiết kiệm vài giây trong quá trình khởi động.

Theo mặc định, tính năng xoá biểu tượng được bật trong bản dựng nền tảng Android, nhưng để bật rõ ràng tính năng này, hãy đặt BOARD_DO_NOT_STRIP_VENDOR_RAMDISK_MODULES trong cấu hình dành riêng cho thiết bị trong device/vendor/device.

Sử dụng phương thức nén LZ4 cho nhân và ramdisk

Gzip tạo ra đầu ra nén nhỏ hơn so với LZ4, nhưng LZ4 giải nén nhanh hơn Gzip. Đối với nhân và các mô-đun, mức giảm kích thước bộ nhớ tuyệt đối khi sử dụng Gzip không đáng kể so với lợi ích về thời gian giải nén của LZ4.

Tính năng hỗ trợ nén ramdisk LZ4 đã được thêm vào bản dựng nền tảng Android thông qua BOARD_RAMDISK_USE_LZ4. Bạn có thể đặt lựa chọn này trong cấu hình dành riêng cho thiết bị. Bạn có thể thiết lập tính năng nén nhân thông qua defconfig nhân.

Việc chuyển sang LZ4 sẽ giúp thời gian khởi động nhanh hơn từ 500 mili giây đến 1000 mili giây.

Tránh ghi nhật ký quá mức trong trình điều khiển

Trong ARM64 và ARM32, các lệnh gọi hàm cách xa vị trí gọi một khoảng cách cụ thể cần có bảng nhảy (gọi là bảng liên kết quy trình hoặc PLT) để có thể mã hoá địa chỉ nhảy đầy đủ. Vì các mô-đun được tải động, nên các bảng chuyển hướng này cần được sửa trong quá trình tải mô-đun. Các lệnh gọi cần di dời được gọi là các mục di dời có số hạng bổ sung rõ ràng (hoặc các mục RELA, viết tắt) ở định dạng ELF.

Nhân Linux thực hiện một số hoạt động tối ưu hoá kích thước bộ nhớ (chẳng hạn như tối ưu hoá lượt truy cập vào bộ nhớ đệm) khi phân bổ PLT. Với cam kết ngược dòng này, lược đồ tối ưu hoá có độ phức tạp O(N^2), trong đó N là số lượng RLA thuộc loại R_AARCH64_JUMP26 hoặc R_AARCH64_CALL26. Vì vậy, việc có ít RLA thuộc các loại này sẽ giúp giảm thời gian tải mô-đun.

Một mẫu mã hoá phổ biến làm tăng số lượng R_AARCH64_CALL26 hoặc R_AARCH64_JUMP26 RELA là việc ghi nhật ký quá mức trong một trình điều khiển. Mỗi lệnh gọi đến printk() hoặc bất kỳ sơ đồ ghi nhật ký nào khác thường sẽ thêm một mục nhập CALL26/JUMP26 RELA. Trong văn bản cam kết trong cam kết ngược dòng, hãy lưu ý rằng ngay cả khi đã tối ưu hoá, 6 mô-đun này vẫn mất khoảng 250 mili giây để tải. Đó là vì 6 mô-đun này là 6 mô-đun hàng đầu có lượng nhật ký lớn nhất.

Việc giảm ghi nhật ký có thể tiết kiệm khoảng 100 – 300 mili giây thời gian khởi động, tuỳ thuộc vào mức độ ghi nhật ký hiện tại.

Bật tính năng thăm dò không đồng bộ một cách chọn lọc

Khi một mô-đun được tải, nếu thiết bị mà mô-đun đó hỗ trợ đã được điền sẵn từ DT (cây thiết bị) và được thêm vào lõi trình điều khiển, thì quá trình kiểm tra thiết bị sẽ được thực hiện trong bối cảnh của lệnh gọi module_init(). Khi quá trình kiểm tra thiết bị được thực hiện trong bối cảnh module_init(), mô-đun sẽ không thể hoàn tất quá trình tải cho đến khi quá trình kiểm tra hoàn tất. Vì quá trình tải mô-đun chủ yếu được chuyển đổi tuần tự, nên một thiết bị mất tương đối nhiều thời gian để kiểm tra sẽ làm chậm thời gian khởi động.

Để tránh thời gian khởi động chậm hơn, hãy bật tính năng thăm dò không đồng bộ cho các mô-đun mất một khoảng thời gian để thăm dò thiết bị của chúng. Việc bật tính năng thăm dò không đồng bộ cho tất cả các mô-đun có thể không mang lại lợi ích gì vì thời gian cần thiết để phân nhánh một luồng và bắt đầu thăm dò có thể cao bằng thời gian cần thiết để thăm dò thiết bị.

Các thiết bị được kết nối thông qua một bus chậm như I2C, các thiết bị thực hiện tải chương trình cơ sở trong chức năng thăm dò và các thiết bị thực hiện nhiều hoạt động khởi động phần cứng có thể dẫn đến vấn đề về thời gian. Cách tốt nhất để xác định thời điểm xảy ra tình trạng này là thu thập thời gian dò tìm cho mọi trình điều khiển và sắp xếp thời gian đó.

Để bật tính năng kiểm tra không đồng bộ cho một mô-đun, bạn không chỉ cần đặt cờ PROBE_PREFER_ASYNCHRONOUS trong mã trình điều khiển. Đối với các mô-đun, bạn cũng cần thêm module_name.async_probe=1 vào dòng lệnh của nhân hoặc truyền async_probe=1 làm tham số mô-đun khi tải mô-đun bằng modprobe hoặc insmod.

Việc bật tính năng thăm dò không đồng bộ có thể giúp tiết kiệm khoảng 100 – 500 mili giây thời gian khởi động, tuỳ thuộc vào phần cứng/trình điều khiển của bạn.

Thăm dò trình điều khiển CPUfreq càng sớm càng tốt

Trình điều khiển CPUfreq càng thăm dò sớm, bạn càng có thể điều chỉnh tần số CPU lên mức tối đa (hoặc mức tối đa bị giới hạn nhiệt) trong quá trình khởi động. CPU càng nhanh thì quá trình khởi động càng nhanh. Nguyên tắc này cũng áp dụng cho devfreqtrình điều khiển kiểm soát tần số DRAM, bộ nhớ và kết nối.

Với các mô-đun, thứ tự tải có thể phụ thuộc vào cấp initcall và thứ tự biên dịch hoặc liên kết của trình điều khiển. Sử dụng bí danh MODULE_SOFTDEP() để đảm bảo trình điều khiển cpufreq nằm trong số ít mô-đun đầu tiên được tải.

Ngoài việc tải mô-đun sớm, bạn cũng cần đảm bảo rằng tất cả các phần phụ thuộc để kiểm tra trình điều khiển CPUfreq cũng đã được kiểm tra. Ví dụ: nếu bạn cần một đồng hồ hoặc tay cầm bộ điều chỉnh để kiểm soát tần số của CPU, hãy đảm bảo rằng chúng được thăm dò trước. Hoặc bạn có thể cần tải trình điều khiển nhiệt trước trình điều khiển CPUfreq nếu có thể CPU của bạn sẽ quá nóng trong quá trình khởi động. Vì vậy, hãy làm những gì có thể để đảm bảo CPUfreq và các trình điều khiển devfreq có liên quan sẽ dò tìm càng sớm càng tốt.

Mức tiết kiệm khi thăm dò trình điều khiển CPUfreq sớm có thể rất nhỏ hoặc rất lớn, tuỳ thuộc vào thời điểm bạn có thể thăm dò và tần suất mà trình tải khởi động để CPU ở trạng thái đó.

Di chuyển các mô-đun sang giai đoạn khởi động thứ hai, phân vùng nhà cung cấp hoặc vendor_dlkm

Vì quy trình init giai đoạn đầu được chuyển đổi tuần tự, nên không có nhiều cơ hội để song song hoá quy trình khởi động. Nếu không cần mô-đun để hoàn tất quá trình khởi động giai đoạn đầu, hãy di chuyển mô-đun đó sang giai đoạn khởi động thứ hai bằng cách đặt mô-đun đó vào phân vùng nhà cung cấp hoặc vendor_dlkm.

Giai đoạn khởi động đầu tiên không yêu cầu bạn thăm dò một số thiết bị để chuyển sang giai đoạn khởi động thứ hai. Chỉ cần có các chức năng của bảng điều khiển và bộ nhớ flash cho quy trình khởi động thông thường.

Tải các trình điều khiển thiết yếu sau:

  • watchdog
  • reset
  • cpufreq

Đối với chế độ khôi phục và không gian người dùng fastbootd, quy trình khởi động giai đoạn đầu tiên cần nhiều thiết bị hơn để kiểm tra (chẳng hạn như USB) và màn hình. Lưu một bản sao của các mô-đun này trong ramdisk giai đoạn đầu và trong phân vùng nhà cung cấp hoặc vendor_dlkm. Điều này cho phép tải các tệp này trong quá trình khởi động giai đoạn đầu để khôi phục hoặc khởi động fastbootd. Tuy nhiên, đừng tải các mô-đun chế độ khôi phục trong quy trình khởi động giai đoạn đầu trong quy trình khởi động thông thường. Bạn có thể trì hoãn các mô-đun ở chế độ khôi phục đến giai đoạn khởi động thứ hai để giảm thời gian khởi động. Tất cả các mô-đun khác không cần thiết trong giai đoạn khởi động đầu tiên sẽ được chuyển sang phân vùng nhà cung cấp hoặc vendor_dlkm.

Cho trước danh sách các thiết bị lá (ví dụ: UFS hoặc cổng nối tiếp), tập lệnh dev needs.sh sẽ tìm tất cả trình điều khiển, thiết bị và mô-đun cần thiết cho các phần phụ thuộc hoặc nhà cung cấp (ví dụ: đồng hồ, bộ điều chỉnh hoặc gpio) để kiểm tra.

Việc di chuyển các mô-đun sang giai đoạn khởi động thứ hai sẽ giảm thời gian khởi động theo những cách sau:

  • Giảm kích thước ramdisk.
    • Điều này giúp tăng tốc độ đọc dữ liệu flash khi trình tải khởi động tải ổ đĩa RAM (bước khởi động được chuyển đổi tuần tự).
    • Điều này giúp tốc độ giải nén nhanh hơn khi nhân giải nén ramdisk (bước khởi động được chuyển đổi tuần tự).
  • Quá trình khởi động giai đoạn thứ hai diễn ra song song, giúp ẩn thời gian tải của mô-đun bằng công việc được thực hiện trong quá trình khởi động giai đoạn thứ hai.

Việc di chuyển các mô-đun sang giai đoạn thứ hai có thể giúp tiết kiệm 500 – 1000 mili giây thời gian khởi động, tuỳ thuộc vào số lượng mô-đun bạn có thể di chuyển sang giai đoạn khởi động thứ hai.

Hậu cần tải mô-đun

Bản dựng Android mới nhất có các cấu hình bảng điều khiển kiểm soát những mô-đun nào sao chép sang từng giai đoạn và những mô-đun nào tải. Phần này tập trung vào nhóm nhỏ sau:

  • BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Đây là danh sách các mô-đun sẽ được sao chép vào ramdisk.
  • BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. Đây là danh sách các mô-đun sẽ được tải trong quá trình khởi động giai đoạn đầu.
  • BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD. Danh sách các mô-đun sẽ được tải khi bạn chọn chế độ khôi phục hoặc fastbootd trong ramdisk.
  • BOARD_VENDOR_KERNEL_MODULES. Đây là danh sách các mô-đun sẽ được sao chép vào phân vùng nhà cung cấp hoặc vendor_dlkm tại thư mục /vendor/lib/modules/.
  • BOARD_VENDOR_KERNEL_MODULES_LOAD. Đây là danh sách các mô-đun sẽ được tải trong giai đoạn khởi động thứ hai.

Các mô-đun khởi động và khôi phục trong ramdisk cũng phải được sao chép vào phân vùng nhà cung cấp hoặc vendor_dlkm tại /vendor/lib/modules. Việc sao chép các mô-đun này vào phân vùng nhà cung cấp đảm bảo các mô-đun không bị ẩn trong quá trình khởi động giai đoạn thứ hai. Điều này rất hữu ích cho việc gỡ lỗi và thu thập modinfo cho báo cáo lỗi.

Việc sao chép sẽ tốn ít dung lượng trên nhà cung cấp hoặc phân vùng vendor_dlkmmiễn là bộ mô-đun khởi động được giảm thiểu. Đảm bảo rằng tệp modules.list của nhà cung cấp có danh sách mô-đun được lọc trong /vendor/lib/modules. Danh sách được lọc đảm bảo thời gian khởi động không bị ảnh hưởng bởi các mô-đun tải lại (đây là một quy trình tốn kém).

Đảm bảo các mô-đun ở chế độ khôi phục tải dưới dạng một nhóm. Bạn có thể tải các mô-đun chế độ khôi phục trong chế độ khôi phục hoặc khi bắt đầu giai đoạn khởi động thứ hai trong mỗi quy trình khởi động.

Bạn có thể sử dụng các tệp Board.Config.mk của thiết bị để thực hiện những thao tác này như trong ví dụ sau:

# 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)))

Ví dụ này minh hoạ một tập hợp con dễ quản lý hơn của BOOT_KERNEL_MODULES và RECOVERY_KERNEL_MODULES sẽ được chỉ định cục bộ trong các tệp cấu hình bo mạch. Tập lệnh trước đó sẽ tìm và điền vào từng mô-đun con trong số các mô-đun hạt nhân có sẵn đã chọn, để lại các mô-đun còn lại cho giai đoạn khởi động thứ hai.

Đối với giai đoạn khởi động thứ hai, bạn nên chạy quá trình tải mô-đun dưới dạng một dịch vụ để quá trình này không chặn luồng khởi động. Sử dụng một tập lệnh shell để quản lý quá trình tải mô-đun để các hoạt động hậu cần khác (chẳng hạn như xử lý và giảm thiểu lỗi hoặc hoàn tất quá trình tải mô-đun) có thể được báo cáo lại (hoặc bỏ qua) nếu cần.

Bạn có thể bỏ qua lỗi tải mô-đun gỡ lỗi không có trên bản dựng của người dùng. Để bỏ qua lỗi này, hãy đặt thuộc tính vendor.device.modules.ready để kích hoạt các giai đoạn sau của quy trình khởi động tập lệnh init rc nhằm tiếp tục đến màn hình khởi động. Tham khảo tập lệnh ví dụ sau đây, nếu bạn có mã sau đây trong /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

Trong tệp rc phần cứng, dịch vụ one shot có thể được chỉ định bằng:

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

Bạn có thể thực hiện các bước tối ưu hoá khác sau khi các mô-đun chuyển từ giai đoạn đầu tiên sang giai đoạn thứ hai. Bạn có thể sử dụng tính năng danh sách chặn modprobe để chia quy trình khởi động giai đoạn thứ hai nhằm đưa vào quá trình tải mô-đun bị trì hoãn của các mô-đun không cần thiết. Bạn có thể hoãn tải các mô-đun chỉ được dùng bởi một HAL cụ thể để chỉ tải các mô-đun khi HAL được khởi động.

Để cải thiện thời gian khởi động biểu kiến, bạn có thể chọn cụ thể những mô-đun trong dịch vụ tải mô-đun có lợi hơn cho việc tải sau màn hình khởi động. Ví dụ: bạn có thể tải muộn một cách rõ ràng các mô-đun cho bộ giải mã video hoặc Wi-Fi sau khi xoá quy trình khởi động init (ví dụ: tín hiệu thuộc tính sys.boot_complete Android). Đảm bảo HAL cho các mô-đun tải muộn chặn đủ lâu khi không có trình điều khiển hạt nhân.

Ngoài ra, bạn có thể sử dụng lệnh wait<file>[<timeout>] của init trong tập lệnh rc của quy trình khởi động để đợi các mục sysfs được chọn cho biết rằng các mô-đun trình điều khiển đã hoàn tất các thao tác thăm dò. Ví dụ: chờ trình điều khiển màn hình hoàn tất quá trình tải ở chế độ nền của quá trình khôi phục hoặc fastbootd, trước khi trình bày đồ hoạ trình đơn.

Khởi tạo tần số CPU thành một giá trị hợp lý trong trình tải khởi động

Không phải SoC/sản phẩm nào cũng có thể khởi động CPU ở tần số cao nhất do lo ngại về nhiệt hoặc nguồn trong các thử nghiệm vòng lặp khởi động. Tuy nhiên, hãy đảm bảo rằng trình tải khởi động đặt tần số của tất cả CPU đang hoạt động ở mức cao nhất có thể một cách an toàn cho một SoC hoặc sản phẩm. Điều này rất quan trọng vì với một nhân hoàn toàn theo mô-đun, quá trình giải nén ramdisk khởi động diễn ra trước khi trình điều khiển CPUfreq có thể được tải. Vì vậy, nếu trình tải khởi động để CPU ở cuối tần số thấp hơn, thì thời gian giải nén ramdisk có thể lâu hơn so với một hạt nhân được biên dịch tĩnh (sau khi điều chỉnh cho sự khác biệt về kích thước ramdisk) vì tần số CPU sẽ rất thấp khi thực hiện công việc chuyên sâu về CPU (giải nén). Điều này cũng áp dụng cho bộ nhớ và tần số kết nối.

Khởi động tần số CPU của các CPU lớn trong trình tải khởi động

Trước khi trình điều khiển CPUfreq được tải, nhân không biết tần số CPU và không điều chỉnh khả năng lập lịch CPU cho tần số hiện tại của chúng. Hạt nhân có thể di chuyển các luồng đến CPU lớn nếu tải đủ cao trên CPU nhỏ.

Đảm bảo các CPU lớn có hiệu suất ít nhất bằng các CPU nhỏ đối với tần số mà trình tải khởi động để chúng ở trạng thái đó. Ví dụ: nếu CPU lớn có hiệu suất gấp 2 lần CPU nhỏ ở cùng tần số, nhưng trình tải khởi động đặt tần số của CPU nhỏ thành 1, 5 GHz và tần số của CPU lớn thành 300 MHz, thì hiệu suất khởi động sẽ giảm nếu nhân di chuyển một luồng sang CPU lớn. Trong ví dụ này, nếu có thể khởi động CPU lớn ở tốc độ 750 MHz, bạn nên làm như vậy ngay cả khi không có ý định sử dụng rõ ràng.

Trình điều khiển không được tải chương trình cơ sở trong giai đoạn khởi động đầu tiên

Có thể có một số trường hợp không thể tránh khỏi khi cần tải chương trình cơ sở trong quá trình khởi động giai đoạn đầu tiên. Nhưng nói chung, trình điều khiển không được tải bất kỳ chương trình cơ sở nào trong quá trình khởi động giai đoạn đầu, đặc biệt là trong bối cảnh thăm dò thiết bị. Việc tải chương trình cơ sở trong quá trình khởi động giai đoạn đầu sẽ khiến toàn bộ quy trình khởi động bị ngưng trệ nếu chương trình cơ sở không có trong ramdisk giai đoạn đầu. Ngay cả khi chương trình cơ sở có trong ramdisk giai đoạn đầu, thì chương trình này vẫn gây ra sự chậm trễ không cần thiết.