快速開機實作瓶頸簡記

最近Fast Boot』、『快速開機』、『5 秒開機』、『XPUD』這些關鍵字紅到爆炸經常在快速開機的討論話題中所聽到。自從 EeePC 的推出自豪的標榜 15 秒開機後快速開機的話題越來越熱門,然後 Aspire One 驚人的 11 秒開機,讓開機的速度』一時間變成了各家研究的首要方向。不久前由知名 Penk 所發展的 7 秒開機 XPUD,直到最近 Intel Moblin 所展示的 5 秒開機,都著實讓人感到不可思議

接下來呢?難道 5 秒開機真的已經是極限了嗎?

由於到處打工,也碰到許多與相關的案子,近來更被許多老闆們要求進行加快開機的速度。進行加速的過程中從開始幾秒鐘為單位的計較,到最後連小數位以下的時間都要精精算計,每一次都證明了5 秒鐘似乎真的是極限

一個開機速度所會碰到的瓶頸大致上如下:
  1. Kernel Initializing
  2. Driver Initializing
  3. Filesystem Initializing
  4. I/O
通常 Kernel + Driver + Filesystem 使用 2 秒(經過數不清的調較和修改 kernel 後),Userspace Initializing + Xorg + Desktop Environment 用 2.x 秒,整個估算大概會是 5 到 6 秒鐘。經過測試其實應該有可以再加速的空間

仔細觀察了 KernelSynaptic Touchpad 就吃了 0.5 秒,IDE 的 probe 也吃了 0.6 秒,單是這兩支 driver 就吃掉了近五分之一的開機時間實在是慢的驚人。其中有趣的是,通常在 netbook 上ide1 沒有 Device,但在這部份卻要花上 0.16 秒,讓人很想要 dirty hack 接讓 kernel 閃過 ide1 的 scan。 :P

其實在整個開機流程中,最大的瓶頸在於 I/O,Userspace 的程式都伴隨著大量的 config file、Font、Library,如何提升載入速度是很重要的課題。這部份Moblin 的 Super Readahead 作法的確很暴力利用多引線平行榨乾 I/O,使重要的檔案預先載入。另外由於 SSD 讀取速度極快,一般來說將每個 block 加大,或也是個提升速度的方法,不過這部份還要待測

Xorg 現在很聰明不吃 config file 一樣自己跑得很開心,原因是他將自動偵測的機制放在裡面了,這樣讓 User 們不再需要了解痛苦的 X 設定,但確讓 X 的啟動速度拖慢了,在這部份,雖然已經有人再著手改進,如: Fedora OneSecondX,但目前還是要花點時間啟動 Xorg,想必還是需要再研究看看

在 netbook 上,一般的 Desktop Environment 已經被所謂的 Application Launcher 所慢慢取代,但無論如何,他們都有很多的 *.desktop 和 Icons 需要被載入,如何改進並加入 cache 機制就是一個很重要的方向,與其使用 Readahead 的方式去增進這部份的速度,還不如直接使用 cache 去解決

後記

將最近研究『Fastboot』的筆記大致隨筆了一下,許多想法還待實作,希望有朝一日能做到1 秒開機,不過現在看來真的是天方夜談。(笑!光 Kernel 都跑不完了)

咦!?要是把 Userspace 的東西強行植入 Kernel,會不會是一個可行的方法呢?反正這年頭就是要髒,髒才有錢賺不是嗎?

這個網誌中的熱門文章

Web 技術中的 Session 是什麼?

淺談 USB 通訊架構之定義(一)

淺談 USB 通訊架構之定義(二)

JavaScript 好用的 async 異步函數!

使用 NodeJS + Express 從 GET/POST Request 取值