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 biểu tượng gỡ lỗi bị xoá khỏi nhân hệ điều hành trong quá trình phát hành công khai thiết bị, hãy đảm bảo bạn cũng xoá biểu tượng gỡ lỗi khỏi các mô-đun. Xoá gỡ lỗi từ các mô-đun giúp thời gian khởi động bằng cách giảm những mục sau:

  • Thời gian cần thiết để đọc tệp nhị phân từ bộ nhớ flash.
  • Thời gian cần thiết để giải nén ổ đĩa RAM.
  • Thời gian 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ể tiết kiệm vài giây trong quá trình khởi động.

Tính năng loại bỏ biểu tượng được bật theo mặc định trong bản dựng nền tảng Android, nhưng để cho phép chúng một cách rõ ràng, hãy đặt BOARD_DO_NOT_STRIP_VENDOR_RAMDISK_MODULES trong cấu hình dành riêng cho thiết bị của bạn trong thiết bị/vendor/device.

Sử dụng tính năng 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 so với Gzip. Đối với nhân và mô-đun, việ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.

Chúng tôi đã thêm tính năng hỗ trợ nén ramdisk LZ4 vào nền tảng Android tạo thông qua BOARD_RAMDISK_USE_LZ4. Bạn có thể đặt tuỳ 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 hạt nhân thông qua tính năng defconfig hạt nhân.

Nếu bạn chuyển sang LZ4, thời gian khởi động nhanh hơn từ 500 mili giây đến 1.000 mili giây.

Tránh đăng nhập quá nhiều vào trình điều khiển

Trong ARM64 và ARM32, các lệnh gọi hàm ở quá một khoảng cách cụ thể từ trang web cuộc gọi cần một bảng nhảy (được gọi là bảng liên kết quy trình hay PLT) để có thể mã hoá địa chỉ nhảy đầy đủ. Vì các mô-đun được tải động, nên bạn cần sửa các bảng nhảy này trong quá trình tải mô-đun. Các lệnh gọi cần di chuyển được gọi là mục nhập di chuyển có các mục bổ sung rõ ràng (viết tắt là RELA) ở đị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ư kết quả tìm kiếm trong bộ nhớ đệm) tối ưu hoá) 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 RELA thuộc loại R_AARCH64_JUMP26 hoặc R_AARCH64_CALL26. Vì vậy, việc có ít RELA hơn thuộc các loại này sẽ giúp giảm thời gian tải mô-đun.

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

Việc giảm hoạt động ghi nhật ký có thể giúp 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ộ, có 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 từ DT (cây thiết bị) và thêm vào lõi trình điều khiển, thì quy trình thăm dò thiết bị sẽ được thực hiện trong ngữ cảnh của lệnh gọi module_init(). Khi một quy trình thăm dò thiết bị được thực hiện trong ngữ cảnh của module_init(), mô-đun không thể tải xong cho đến khi quy trình thăm dò 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 để thăm dò 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 lấy trong khi thăm dò thiết bị của chúng. 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 có lợi vì thời gian cần để phân nhánh một luồng và bắt đầu đầu 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ị tải firmware trong hàm thăm dò và các thiết bị thực hiện nhiều quá trình khởi chạy phần cứng có thể dẫn đến vấn đề về thời gian. Cách tốt nhất để xác định khi nào điều này xảy ra là thu thập thời gian thăm dò cho mỗi người lái xe và sắp xếp thời gian đó.

Để bật tính năng thăm dò không đồng bộ cho một mô-đun, không đủ chỉ đặ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 trong dòng lệnh kernel hoặc truyền async_probe=1 dưới dạng tham số mô-đun khi tải mô-đun bằng cách sử dụng modprobe hoặc insmod.

Việc bật tính năng thăm dò không đồng bộ có thể 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

Các thăm dò trình điều khiển CPUfreq càng sớm thì bạn càng có thể mở rộng CPU sớm hơn tần số lên tối đa (hoặc một số tối đa bị giới hạn nhiệt) trong khi khởi động. Chiến lược phát hành đĩa đơn CPU càng nhanh thì khởi động càng nhanh. Nguyên tắc này cũng áp dụng cho devfreq các trình điều khiển điều khiển DRAM, bộ nhớ và tần số kết nối liên kết.

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 sớm mô-đun, bạn cũng cần đảm bảo tất cả để thăm dò trình điều khiển CPUfreq cũng đã được thăm dò. Ví dụ: nếu bạn cần một đồng hồ hoặc tay điều khiển bộ điều chỉnh để kiểm soát tần số của CPU, hãy đảm bảo chúng sẽ được thăm dò trước tiên. 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 CPU có thể quá nóng trong quá trình khởi động. Vì vậy, hãy làm mọi thứ có thể để đảm bảo CPUfreq và trình điều khiển devfreq liên quan thăm dò càng sớm càng tốt.

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

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

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

Quá trình khởi chạy giai đoạn đầu không yêu cầu thăm dò một số thiết bị để chuyển sang giai đoạn khởi chạy thứ hai. Chỉ cần khả 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à fastbootd không gian người dùng, quá trình khởi chạy giai đoạn đầu yêu cầu nhiều thiết bị hơn để thăm dò (chẳng hạn như USB) và hiển thị. Lưu một bản sao của các mô-đun này trong ramdisk giai đoạn đầu tiên và trong phân vùng nhà cung cấp hoặc vendor_dlkm. Điều này cho phép họ được tải trong khởi tạo giai đoạn đầu tiên để khôi phục hoặc quy trình khởi động fastbootd. Tuy nhiên, không tải các mô-đun chế độ khôi phục trong khởi động giai đoạn đầu tiên trong quá trình khởi động bình thường luồ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 khởi tạo giai đoạn đầu tiên nên là được di chuyển sang phân vùng nhà cung cấp hoặc vendor_dlkm.

Với danh sách các thiết bị lá (ví dụ: UFS hoặc nối tiếp), tập lệnh dev needs.sh sẽ tìm thấy 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) để thăm dò.

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

  • Giảm kích thước ramdisk.
    • Điều này giúp đọc flash nhanh hơn khi trình tải khởi động tải ổ đĩa ram (bước khởi động nối tiếp).
    • Điều này giúp tăng tốc độ giải nén khi nhân giải nén ramdisk (bước khởi động tuần tự).
  • Init giai đoạn hai hoạt động song song, giúp ẩn thời gian tải của mô-đun với công việc được thực hiện trong khởi tạo giai đoạn hai.

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

Quy trình tải mô-đun

Cấu hình bảng tính năng bản dựng mới nhất của Android kiểm soát các mô-đun sẽ sao chép sang từng giai đoạn và mô-đun nào sẽ tải. Phần này tập trung vào trên tập hợp con sau:

  • BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Danh sách các mô-đun cần sao chép vào ramdisk.
  • BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. Danh sách các mô-đun sẽ được tải trong quá trình khởi chạy giai đoạn đầu tiên.
  • BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD. Danh sách mô-đun này để sẽ được tải khi khôi phục hoặc fastbootd được chọn từ ổ đĩa ram.
  • BOARD_VENDOR_KERNEL_MODULES. 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. Danh sách mô-đun sẽ được tải này khởi tạo giai đoạn 2.

Bạn cũng phải sao chép các mô-đun khởi động và khôi phục trong ramdisk vào phân vùng nhà cung cấp hoặc vendor_dlkm tại /vendor/lib/modules. 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 tạo giai đoạn hai, rất hữu ích khi gỡ lỗi và thu thập modinfo để báo cáo lỗi.

Quá trình sao chép sẽ tốn ít dung lượng trên phân vùng nhà cung cấp hoặc vendor_dlkm miễ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 các mô-đun đã lọc trong /vendor/lib/modules. Danh sách đã lọc đảm bảo thời gian khởi động không bị ảnh hưởng bởi việc tải các mô-đun (một quá trình tốn kém).

Đảm bảo rằng các mô-đun chế độ khôi phục tải dưới dạng một nhóm. Đang tải các mô-đun chế độ khôi phục có thể thực hiện ở chế độ khôi phục hoặc ở đầu giai đoạn thứ hai init 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 hành động này như bạn thấy 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 cho thấy một tập hợp con dễ quản lý hơn gồm BOOT_KERNEL_MODULES và RECOVERY_KERNEL_MODULES sẽ được chỉ định cục bộ trong cấu hình bảng tệp. Tập lệnh trước tìm và điền từng mô-đun con trong các mô-đun nhân hiện có đã chọn, để lại các mô-đun còn lại cho quá trình khởi động giai đoạn thứ hai.

Đối với init giai đoạn hai, bạn nên chạy mô-đun tải dưới dạng dịch vụ để nó không chặn luồng khởi động. Sử dụng tập lệnh shell để quản lý việc tải mô-đun để các công việc hậu cần khác, chẳng hạn như xử lý và giảm thiểu lỗi hoặc tải mô-đun hoàn thành, 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 để tiếp tục chuyển đến màn hình khởi chạy. Tham khảo tập lệnh mẫu sau đây, nếu bạn có mã sau 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ể tối ưu hoá thêm sau khi các mô-đun chuyển từ mô-đun đầu tiên sang giai đoạn hai. Bạn có thể sử dụng tính năng danh sách chặn modprobe để phân tách quy trình khởi động giai đoạn thứ hai để bao gồm cả việc tải mô-đun bị trì hoãn của các mô-đun không cần thiết. Việc tải các mô-đun mà một HAL cụ thể sử dụng riêng có thể bị trì hoãn để tải mô-đun chỉ khi HAL được khởi động.

Để cải thiện thời gian khởi động rõ ràng, bạn có thể chọn cụ thể các mô-đun trong dịch vụ tải mô-đun thuận lợi hơn cho việc tải sau khi khởi chạy màn hình. Ví dụ: bạn có thể tải trễ các mô-đun cho bộ giải mã video hoặc Wi-Fi một cách rõ ràng sau khi xoá luồng khởi động ban đầu (ví dụ: tín hiệu thuộc tính Android sys.boot_complete). Đảm bảo HAL cho hoạt động tải trễ các mô-đun chặn đủ lâu khi không có trình điều khiển 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 để chờ các mục sysfs đã 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ụ về điều này là chờ trình điều khiển hiển thị để hoàn tất việc tải trong nền khôi phục hoặc fastbootd, trước khi trình bày hình ảnh trình đơn.

Khởi động tần suất của CPU với một giá trị hợp lý trong trình tải khởi động

Không phải mọi SoC/sản phẩm đều có thể khởi động CPU ở tần số cao nhất do các vấn đề về nhiệt hoặc nguồn điện trong quá trình kiểm thử vòng lặp khởi động. Tuy nhiên, hãy đảm bảo trình tải khởi động đặt tần suất của tất cả CPU trực tuyến ở 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 đầy đủ nhân mô-đun, quá trình giải nén ramdisk init diễn ra trước CPUfreq trình điều khiển có thể tải được. Vì vậy, nếu CPU không còn tần số do trình tải khởi động, thời gian giải nén ramdisk có thể mất nhiều thời gian nhân biên dịch tĩnh (sau khi điều chỉnh sự chênh lệch về kích thước ổ đĩa RAM) vì tần suất của CPU sẽ rất thấp khi thực hiện công việc đòi hỏi nhiều CPU (giải nén). Điều tương tự cũng áp dụng cho bộ nhớ và tần suất 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 hệ điều hành không biết về Tần số của CPU và không điều chỉnh theo tỷ lệ công suất dự kiến của CPU cho dòng điện tương ứng tần suất. Hạt nhân có thể di chuyển luồng sang CPU lớn nếu tải đủ cao trên CPU nhỏ.

Hãy đảm bảo các CPU lớn cũng hoạt động hiệu quả bằng các CPU nhỏ cho tần suất mà trình tải khởi động để chúng. Ví dụ: nếu CPU lớn có hiệu suất cao gấp 2 lần so với 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 luồng sang CPU lớn. Trong ví dụ này, nếu an toàn khởi động CPU ở 750 MHz, bạn nên làm vậy ngay cả khi không có ý định sử dụng một cách rõ ràng.

Trình điều khiển không được tải chương trình cơ sở trong khởi tạo giai đoạn đầ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 phần mềm trong giai đoạn khởi tạo đầu tiên. Nhưng nhìn chung, trình điều khiển không nên tải bất kỳ chương trình cơ sở nào trong giai đoạn đầu tiên init, đặc biệt là trong ngữ 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ộ quá trình khởi động bị đình trệ nếu chương trình cơ sở không có trong ramdisk giai đoạn đầu. Và ngay cả khi có chương trình cơ sở trong ramdisk giai đoạn đầu, nó vẫn gây ra độ trễ không cần thiết.