Linux加速啓動，啓動時間的極限優化

原文鏈接：http://hi.baidu.com/xnej/blog/item/82ecdc8b7ef07cd0fc1f106d.html

在上次完成嵌入式應用的Linux裁減後，Linux的啓動時間仍需要 7s 左右，雖然勉強可以接受，但仍然沒有達到我個人所追求的目標——2s 以內。況且，在實際的商用環境中，設備可靠性的要求可是“5個9”（99.999%，即OOS時間低於5分鐘/年），這就意味着每減少一秒鐘Linux啓 動（設備復位）時間，對可靠性都是一個明顯的提升。
　　言歸正傳，如何着手對Linux的啓動時間進行優化呢？

　　CELF(The Consumer Electronics Linux Forum)論壇爲我們指引了一個方向。

 

（1）首先是對Linux啓動過程的跟蹤和分析，生成詳細的啓動時間報告。

 

　　較爲簡單可行的方式是通過PrintkTime功能爲啓動過程的所有內核信息增加時間戳，便於彙總分析。PrintkTime最早爲 CELF所提供的一個內核補丁，在後來的Kernel 2.6.11版本中正式納入標準內核。所以大家可能在新版本的內核中直接啓用該功能。如果你的Linux內核因爲某些原因不能更新爲2.6.11之後的版 本，那麼可以參考CELF提供的方法修改或直接下載它們提供的補丁：http://tree.celinuxforum.org/CelfPubWiki/PrintkTimes

 

　　開啓PrintkTime功能的方法很簡單，只需在內核啓動參數中增加“time”即可。當然，你也可以選擇在編譯內核時直接指定 “Kernel hacking”中的“Show timing information on printks”來強制每次啓動均爲內核信息增加時間戳。這一種方式還有另一個好處：你可以得到內核在解析啓動參數前所有信息的時間。因此，我選擇後一種 方式。

 

　　當完成上述配置後，重新啓動Linux，然後通過以下命令將內核啓動信息輸出到文件：

 

dmesg -s 131072 > ktime

 

　　然後利用一個腳本“show_delta”（位於Linux源碼的scripts文件夾下）將上述輸出的文件轉換爲時間增量顯示格式：

 

/usr/src/linux-x.xx.xx/scripts/show_delta ktime > dtime

 

　　這樣，你就得到了一份關於Linux啓動時間消耗的詳細報告。

 

（2）然後，我們就來通過這份報告，找出啓動中相對耗時的過程。

 

　　必須明確一點：報告中的時間增量和內核信息之間沒有必然的對應關係，真正的時間消耗必須從內核源碼入手分析。

 

　　這一點對於稍微熟悉編程的朋友來說都不難理解，因爲時間增量只是兩次調用printk之間的時間差值。通常來說，內核啓動過程中在完成一些 耗時的任務，如創建hash索引、probe硬件設備等操作後會通過printk將結果打印出來，這種情況下，時間增量往往反映的是信息對應過程的耗時； 但有些時候，內核是在調用printk輸出信息後纔開始相應的過程，那麼報告中內核信息相應過程的時間消耗對應的是其下一行的時間增量；還有一些時候，時 間消耗在了兩次內核信息輸出之間的某個不確定的時段，這樣時間增量可能就完全無法通過內核信息反應出來了。

 

　　所以，爲了準確判斷真正的時間消耗，我們需要結合內核源碼進行分析。必要的時候，例如上述第三種情形下，還得自己在源碼中插入printk打印，以進一步確定實際的時間消耗過程。

 

　　以下是我上次裁減後Linux內核的啓動分析：

 

　　內核啓動總時間： 6.188s

 

　　關鍵的耗時部分：
　　1) 0.652s - Timer,IRQ,Cache,Mem Pages等核心部分的初始化
　　2) 0.611s - 內核與RTC時鐘同步
　　3) 0.328s - 計算Calibrating Delay（4個CPU核心的總消耗）
　　4) 0.144s - 校準APIC時鐘
　　5) 0.312s - 校準Migration Cost
　　6) 3.520s - Intel E1000網卡初始化

 

　　下面，將針對上述各部分進行逐一分析和化解。

 

（3）接下來，進行具體的分項優化。

 

　　CELF已經提出了一整套針對消費類電子產品所使用的嵌入式Linux的啓動優化方案，但是由於面向不同應用，所以我們只能部分借鑑他們的經驗，針對自己面對的問題作出具體的分析和嘗試。

 

　　內核關鍵部分（Timer、IRQ、Cache、Mem Pages……）的初始化目前暫時沒有比較可靠和可行的優化方案，所以暫不考慮。

 

　　對於上面分析結果中的 2、3 兩項，CELF已有專項的優化方案：“RTCNoSync”和“PresetLPJ”。

 

　　前者通過屏蔽啓動過程中所進行的RTC時鐘同步或者將這一過程放到啓動後進行（視具體應用對時鐘精度的需求而定），實現起來比較容易，但需 要爲內核打補丁。似乎CELF目前的工作僅僅是去掉了該過程，而沒有實現所提到的“延後”處理RTC時鐘的同步。考慮到這個原因，我的方案中暫時沒有引入 這一優化（畢竟它所帶來的時間漂移已經達到了“秒”級），繼續關注中。

 

　　後者是通過在啓動參數中強制指定LPJ值而跳過實際的計算過程，這是基於LPJ值在硬件條件不變的情況下不會變化的考慮。所以在正常啓動後記錄下內核信息中的“Calibrating Delay”數值後就可以在啓動參數中以下面的形式強制指定LPJ值了：

 

lpj=9600700

 

　　上面分析結果中的 4、5 兩項都是SMP初始化的一部分，因此不在CELF研究的範疇（或許將來會有采用多核的MP4出現？……），只能自力更生了。研究了一下SMP的初始化代 碼，發現“Migration Cost”其實也可以像“Calibrating Delay”採用預置的方式跳過校準時間。方法類似，最後在內核啓動參數中增加：

 

migration_cost=4000,4000

 

　　而Intel的網卡驅動初始化優化起來就比較麻煩了，雖然也是開源，但讀硬件驅動完全不比讀一般的C代碼，況且建立在如此膚淺理解基礎上的 “優化”修改也實在難保萬全。基於可靠性的考慮，我最終在兩次嘗試均告失敗後放棄了這一條路。那麼，換一個思維角度，可以借鑑CELF在 “ParallelRCScripts”方案中的“並行初始化”思想，將網卡驅動獨立編譯爲模塊，放在初始化腳本中與其它模塊和應用同步加載，從而消除 Probe阻塞對啓動時間的影響。考慮到應用初始化也可能使用到網絡，而在我們的實際硬件環境中，只有eth0是供應用使用的，因此需要將第一個網口初始 化的0.3s時間計算在內。

 

　　除了在我的方案中所遇到的上述各優化點，CELF還提出了一些你可能會感興趣的有特定針對性的專項優化，如：

 

　　ShortIDEDelays - 縮短IDE探測時長（我的應用場景中不包含硬盤，所以用不上）
　　KernelXIP - 直接在ROM或Flash中運行內核（考慮到兼容性因素，未採用）
　　IDENoProbe - 跳過未連接設備的IDE口
　　OptimizeRCScripts - 優化initrd中的linuxrc腳本（我採用了BusyBox更簡潔的linuxrc）

 

　　以及其它一些尚處於設想階段的優化方案，感興趣的朋友可以訪問CELF Developer Wiki瞭解詳情。

 

（4）優化結果

 

　　經過上述專項優化，以及對inittab、rcS腳本的冗餘裁減，整個Linux內核的啓動時間從優化前的 6.188s 下降到了最終的 2.016s，如果不包含eth0的初始化，則僅需 1.708s（eth0初始化可以和系統中間件及部分應用加載並行），基本達到了既定目標。與Kexec配合，可以大大降低軟件故障導致的復位時間，有效 的提升了產品的可靠性。