優化嵌入式Linux的啟動時間之核心

1.2 使用核心啟**進行有目的的優化

使用initcall_debug可以生成啟**，從而輕鬆檢視哪些核心初始化函式需要最多時間來執行。

1.3 減小核心尺寸

首先，我們專注於在不刪除功能的情況下縮小尺寸

然後考慮核心壓縮的方式：

根據儲存讀取速度和cpu解壓縮核心之間的平衡，需要對不同的壓縮演算法進行測試。還建議在核心優化過程結束時嘗試壓縮選項，因為結果可能會因核心大小而異。

在基於ti am335x (arm), 1 ghz, linux 5.1測試：

lzo和gzip似乎是最好的解決方案。但這結果取決於儲存和cpu效能，故在決定方案是務必進行測試。

另外核心的編譯選項也有可以優化的可能：

1.4 延遲驅動程式和初始化呼叫

如果有點功能無法編譯為模組（例如，網路或模組子系統），可以嘗試推遲執行。核心不會縮小，但某些初始化將被推遲，所以啟動變快。通常，您可以修改probe（）函式以返回-eprobe_defer，直到它們準備好執行為止。

有關支援此功能的詳細資訊，請參見

1.5 關閉控制台輸出

控制台輸出實際上要花費很多時間（非常慢的裝置）。產品中可能不需要。通過在核心命令列中傳遞quiet引數來禁用它。但仍然可以使用dmesg獲取核心訊息。這一步一般建議等最後一步再做，否則將損失控制台進行除錯。

1.6 預置jiffy

每次引導時，linux核心都會校準延遲迴圈（用於udelay()函式）。這將測量每個jiff y(lpj)值的迴圈次數。只需要測量一次！在核心啟動訊息中找到 lpj值：

calibrating delay loop… 996.14 bogomips (lpj=4980736)

然後將lpj = 新增到核心命令列：

calibrating delay loop (skipped) preset value… 996.14 bogomips (lpj=4980736)

1.7 多處理器

smp初始化很慢，即使您只有乙個核心cpu，通常也會在預設配置中啟用它（預設配置應支援多個系統）。因此，如果只有乙個cpu核心，請確保將其禁用。beaglebone black上的結果：壓縮核心大小：-188 kb

要節省最後的毫秒數，您可能需要刪除不必要的功能：

![在這裡插入描述](