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

較為簡單可行的方式是通過PrintkTime功能為啟動過程的所有內(nèi)核信息增加時間戳，便于匯總分析。PrintkTime最早為CELF所提供的一個內(nèi)核補丁，在后來的Kernel 2.6.11版本中正式納入標(biāo)準(zhǔn)內(nèi)核。所以大家可能在新版本的內(nèi)核中直接啟用該功能。如果你的Linux內(nèi)核因為某些原因不能更新為2.6.11之后的版本，那么可以參考CELF提供的方法修改或直接下載它們提供的補?。?br />
開啟PrintkTime功能的方法很簡單，只需在內(nèi)核啟動參數(shù)中增加“time”即可。當(dāng)然，你也可以選擇在編譯內(nèi)核時直接指定“Kernel hacking”中的“Show timing information on printks”來強制每次啟動均為內(nèi)核信息增加時間戳。這一種方式還有另一個好處：你可以得到內(nèi)核在解析啟動參數(shù)前所有信息的時間。因此，我選擇后一種方式。

當(dāng)完成上述配置后，重新啟動Linux，然后通過以下命令將內(nèi)核啟動信息輸出到文件：
dmesg -s 131072 > ktime

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

/usr/src/linux-x.xx.xx/scripts/show_delta ktime > dtime
這樣，你就得到了一份關(guān)于Linux啟動時間消耗的詳細報告。

　　(2)然后，我們就來通過這份報告，找出啟動中相對耗時的過程。

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

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

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

以下是我上次裁減后Linux內(nèi)核的啟動分析：

內(nèi)核啟動總時間： 6.188s
關(guān)鍵的耗時部分：
1) 0.652s - Timer,IRQ,Cache,Mem Pages等核心部分的初始化
2) 0.611s - 內(nèi)核與RTC時鐘同步
3) 0.328s - 計算Calibrating Delay(4個CPU核心的總消耗)
4) 0.144s - 校準(zhǔn)APIC時鐘
5) 0.312s - 校準(zhǔn)Migration Cost
6) 3.520s - Intel E1000網(wǎng)卡初始化
下面，將針對上述各部分進行逐一分析和化解。

　　(3)接下來，進行具體的分項優(yōu)化。

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

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

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

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

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

lpj=9600700

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

migration_cost=4000,4000

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

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

ShortIDEDelays - 縮短IDE探測時長(我的應(yīng)用場景中不包含硬盤，所以用不上)
KernelXIP - 直接在ROM或Flash中運行內(nèi)核(考慮到兼容性因素，未采用)
IDENoProbe - 跳過未連接設(shè)備的IDE口
OptimizeRCScripts - 優(yōu)化initrd中的linuxrc腳本(我采用了BusyBox更簡潔的linuxrc)
以及其它一些尚處于設(shè)想階段的優(yōu)化方案，感興趣的朋友可以訪問CELF Developer Wiki了解詳情。

　　(4)優(yōu)化結(jié)果

經(jīng)過上述專項優(yōu)化，以及對inittab、rcS腳本的冗余裁減，整個Linux內(nèi)核的啟動時間從優(yōu)化前的 6.188s 下降到了最終的 2.016s，如果不包含eth0的初始化，則僅需 1.708s(eth0初始化可以和系統(tǒng)中間件及部分應(yīng)用加載并行)，基本達到了既定目標(biāo)。與Kexec配合，可以大大降低軟件故障導(dǎo)致的復(fù)位時間，有效的提升了產(chǎn)品的可靠性。