Linux系統啟動時間優化方案
關鍵的耗時部分:
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配合,可以大大降低軟件故障導致的復位時間,有效的提升了產品的可靠性。
linux操作系統文章專題:linux操作系統詳解(linux不再難懂)
評論