Linux啟動(dòng)時(shí)間的極限優(yōu)化

在上次完成嵌入式應用的Linux裁減后，Linux的啟動(dòng)時(shí)間仍需要 7s 左右，雖然勉強可以接受，但仍然沒(méi)有達到我個(gè)人所追求的目標——2s 以?xún)?。況且，在實(shí)際的商用環(huán)境中，設備可靠性的要求可是“5個(gè)9”(99.999%，即OOS時(shí)間低于5分鐘/年)，這就意味著(zhù)每減少一秒鐘Linux啟動(dòng)(設備復位)時(shí)間，對可靠性都是一個(gè)明顯的提升。

言歸正傳，如何著(zhù)手對Linux的啟動(dòng)時(shí)間進(jìn)行優(yōu)化呢?

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

(1)首先是對Linux啟動(dòng)過(guò)程的跟蹤和分析，生成詳細的啟動(dòng)時(shí)間報告。

較為簡(jiǎn)單可行的方式是通過(guò)PrintkTime功能為啟動(dòng)過(guò)程的所有內核信息增加時(shí)間戳，便于匯總分析。PrintkTime最早為CELF所提供的一個(gè)內核補丁，在后來(lái)的Kernel 2.6.11版本中正式納入標準內核。所以大家可能在新版本的內核中直接啟用該功能。如果你的Linux內核因為某些原因不能更新為2.6.11之后的版本，那么可以參考CELF提供的方法修改或直接下載它們提供的補?。簂inuxforum.org/CelfPubWiki>http://tree.celinuxforum.org/CelfPubWiki /PrintkTimes

開(kāi)啟PrintkTime功能的方法很簡(jiǎn)單，只需在內核啟動(dòng)參數中增加“time”即可。當然，你也可以選擇在編譯內核時(shí)直接指定“Kernel hacking”中的“Show timing information on printks”來(lái)強制每次啟動(dòng)均為內核信息增加時(shí)間戳。這一種方式還有另一個(gè)好處：你可以得到內核在解析啟動(dòng)參數前所有信息的時(shí)間。因此，我選擇后一種方式。

當完成上述配置后，重新啟動(dòng)Linux，然后通過(guò)以下命令將內核啟動(dòng)信息輸出到文件：

dmesg -s 131072 >ktime

然后利用一個(gè)腳本“show_delta”(位于Linux源碼的scripts文件夾下)將上述輸出的文件轉換為時(shí)間增量顯示格式：

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

這樣，你就得到了一份關(guān)于Linux啟動(dòng)時(shí)間消耗的詳細報告。

(2)然后，我們就來(lái)通過(guò)這份報告，找出啟動(dòng)中相對耗時(shí)的過(guò)程。

必須明確一點(diǎn)：報告中的時(shí)間增量和內核信息之間沒(méi)有必然的對應關(guān)系，真正的時(shí)間消耗必須從內核源碼入手分析。

這一點(diǎn)對于稍微熟悉編程的朋友來(lái)說(shuō)都不難理解，因為時(shí)間增量只是兩次調用printk之間的時(shí)間差值。通常來(lái)說(shuō)，內核啟動(dòng)過(guò)程中在完成一些耗時(shí)的任務(wù)，如創(chuàng )建hash索引、probe硬件設備等操作后會(huì )通過(guò)printk將結果打印出來(lái)，這種情況下，時(shí)間增量往往反映的是信息對應過(guò)程的耗時(shí);但有些時(shí)候，內核是在調用printk輸出信息后才開(kāi)始相應的過(guò)程，那么報告中內核信息相應過(guò)程的時(shí)間消耗對應的是其下一行的時(shí)間增量;還有一些時(shí)候，時(shí)間消耗在了兩次內核信息輸出之間的某個(gè)不確定的時(shí)段，這樣時(shí)間增量可能就完全無(wú)法通過(guò)內核信息反應出來(lái)了。

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

以下是我上次裁減后Linux內核的啟動(dòng)分析：

內核啟動(dòng)總時(shí)間： 6.188s

關(guān)鍵的耗時(shí)部分：

1) 0.652s - Timer,IRQ,Cache,Mem Pages等核心部分的初始化

2) 0.611s - 內核與RTC時(shí)鐘同步

3) 0.328s - 計算Calibrating Delay(4個(gè)CPU核心的總消耗)

4) 0.144s - 校準APIC時(shí)鐘

5) 0.312s - 校準Migration Cost

6) 3.520s - Intel E1000網(wǎng)卡初始化

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

(3)接下來(lái)，進(jìn)行具體的分項優(yōu)化。

CELF已經(jīng)提出了一整套針對消費類(lèi)電子產(chǎn)品所使用的嵌入式Linux的啟動(dòng)優(yōu)化方案，但是由于面向不同應用，所以我們只能部分借鑒他們的經(jīng)驗，針對自己面對的問(wèn)題作出具體的分析和嘗試。

內核關(guān)鍵部分(Timer、IRQ、Cache、Mem Pages……)的初始化目前暫時(shí)沒(méi)有比較可靠和可行的優(yōu)化方案，所以暫不考慮。

對于上面分析結果中的 2、3 兩項，CELF已有專(zhuān)項的優(yōu)化方案：“RTCNoSync”和“PresetLPJ”。

前者通過(guò)屏蔽啟動(dòng)過(guò)程中所進(jìn)行的RTC時(shí)鐘同步或者將這一過(guò)程放到啟動(dòng)后進(jìn)行(視具體應用對時(shí)鐘精度的需求而定)，實(shí)現起來(lái)比較容易，但需要為內核打補丁。似乎CELF目前的工作僅僅是去掉了該過(guò)程，而沒(méi)有實(shí)現所提到的“延后”處理RTC時(shí)鐘的同步?？紤]到這個(gè)原因，我的方案中暫時(shí)沒(méi)有引入這一優(yōu)化(畢竟它所帶來(lái)的時(shí)間漂移已經(jīng)達到了“秒”級)，繼續關(guān)注中。

后者是通過(guò)在啟動(dòng)參數中強制指定LPJ值而跳過(guò)實(shí)際的計算過(guò)程，這是基于LPJ值在硬件條件不變的情況下不會(huì )變化的考慮。所以在正常啟動(dòng)后記錄下內核信息中的“Calibrating Delay”數值后就可以在啟動(dòng)參數中以下面的形式強制指定LPJ值了：

lpj=9600700

上面分析結果中的 4、5 兩項都是SMP初始化的一部分，因此不在CELF研究的范疇(或許將來(lái)會(huì )有采用多核的MP4出現?……)，只能自力更生了。研究了一下SMP的初始化代碼，發(fā)現“Migration Cost”其實(shí)也可以像“Calibrating Delay”采用預置的方式跳過(guò)校準時(shí)間。方法類(lèi)似，最后在內核啟動(dòng)參數中增加：

migration_cost=4000,4000

而Intel的網(wǎng)卡驅動(dòng)初始化優(yōu)化起來(lái)就比較麻煩了，雖然也是開(kāi)源，但讀硬件驅動(dòng)完全不比讀一般的C代碼，況且建立在如此膚淺理解基礎上的“優(yōu)化”修改也實(shí)在難保萬(wàn)全?；诳煽啃缘目紤]，我最終在兩次嘗試均告失敗后放棄了這一條路。那么，換一個(gè)思維角度，可以借鑒CELF在“ParallelRCScripts”方案中的“并行初始化”思想，將網(wǎng)卡驅動(dòng)獨立編譯為模塊，放在初始化腳本中與其它模塊和應用同步加載，從而消除Probe阻塞對啟動(dòng)時(shí)間的影響?？紤]到應用初始化也可能使用到網(wǎng)絡(luò )，而在我們的實(shí)際硬件環(huán)境中，只有eth0是供應用使用的，因此需要將第一個(gè)網(wǎng)口初始化的0.3s時(shí)間計算在內。

除了在我的方案中所遇到的上述各優(yōu)化點(diǎn)，CELF還提出了一些你可能會(huì )感興趣的有特定針對性的專(zhuān)項優(yōu)化，如：