基於Preempt-RT實時SMP Linux系統0：開篇

04-12

大概在10年前，我有幸基於Preempt-RT構建了一個實時的SMP Linux系統，這個系統被大規模應用到數碼相機，單反及錄像機，支撐了幾千萬的出貨量，甚至上億。半年多前轉行到自動駕駛行業，發現很多同行也在探索Linux系統的實時性問題，於是產生了把我以前的經歷記錄下來的想法。當時做這個系統，經歷了1年的原型開發，1年的產品化過程，很多當時遇到的技術挑戰或許不會再遇到，但相信還是有借鑒意義。

背景

數碼相機從2000年到2010年是一個黃金髮展時期，在經歷了像素牽引的階段後，更多的附加功能，比如人機交互/網路，被放了進去。不管是像素的提升，還是更豐富的人機交互，都需要更多的處理能力，另一方面，待機時間也是一個永恆的話題，提升處理器主頻不是一個好的選擇。

ARM也是看到了這個趨勢，在05年首個支持SMP（對稱多處理器）的ARM11 MPCore，即通過多個核心來提升能效比。2007年公司非常有遠見的把支持SMP的ARM11MPCore應用到了產品上，但是軟體上沒使能，為後續的架構升級埋下了伏筆。

SMP之前的數碼產品系統架構

AMP（非對稱多處理器）架構是數碼產品裡面非常常見的，而在我司的數碼相機裡面，一個CPU作為ISP，一個CPU負責編解碼，一個CPU負責人機交互，前兩個子系統運行RTOS，後一個運行Linux。這應該說是一個非常合理的架構，ISP/編解碼功能相對單一，對實時性要求比較高，適合用RTOS。而人機交互/網路功能越來越複雜，大量的開源組件都是Linux。但是當這個三個子系統對硬體性能都有要求的時候，每個都上SMP從成本/功耗角度就不合適了。另外從功能成熟度看，支持SMP的RTOS並不多，不想Linux在伺服器/PC上久經考驗。

從一個原型開始

07年面向部門內部的技術展，我開發了一個原型，這個原型做了一個事情：把RTOS子系統跑在Linux上面，可以實現照片預覽。當時市面上有不少公司賣這種hybrid方案，但是都是把Linux跑在RTOS裡面，為什麼我反其道而行之呢？因為考慮上SMP Linux，這樣才能充分發揮硬體的能力。這個原型我和另外一個中途進來幫忙的同事大概搞了一個月，為什麼這麼快？除了我們天賦異稟之外，得益於所使用的叫做iTron的RTOS有一個非常規範的API界面，我們只要把這些API映射到Linux的API即可。當時做了一個非常正確的技術決定，把RTOS子系統作為一個內核模塊，這樣做的幾個好處：

可以方便直接和硬體交互，userspace要做好中斷處理是非常困難的
性能

缺點也是有的，大家知道在內核空間，庫是比較欠缺的，沒有完整的c庫，也不支持c++，這個我們在後來也找到了一個比較好的解決辦法，先賣個關子。

一個完整的原型

上面的原型在技術展取得了比較好的效果，得到了大boss的首肯，有了更多的資源可以投入到上面，下一個目標就是把一個完整的數碼相機跑在SMP Linux上，大概半年多，我全職搞這個事情，加上兄弟團隊的技術支持：

1，把SMP Linux在ARM11 MPCore上面穩定的跑起來。07年當時的Linux對ARM SMP的支持還是beta狀態，記得我在realview評估板上面甚至還碰到過CPU的cache同步bug
2，在Ingo Monlar的Preempt-RT補丁群的基礎上優化實時性，在一個主頻100MHz的CPU上做到100us的worst case中斷響應
3，跑完整的RTOS子系統，集成調試

第2，3步經歷了很長時間。大家可能直覺上都認為實時系統性能很好，其實剛好相反，實時性好，並不意味著一般意義上的性能好，比如IO，平均調度延遲等等，尤其在Linux的兩個核心子系統上：

Scheduler調度器，linux的調度器雖然支持SCHED_FIFO，但並不適合有大量實時線程的場景
RCU，RCU在當時的Preempt RT上性能簡直慘不忍睹

實時性方面的挑戰則有

ARM11 MPCore的ASID/TLB同步等特性的支持
Scheduler的各種corner case

產品化

基於上面的原型的彙報取得了巨大的成功，因為幾乎分辨不出非SMP和SMP版本的區別，而它所帶來的高度靈活性及可擴展性是顯而易見的。大老闆一聲令下，很快的走向了產品化的過程。

後面我將分次把相關的我印象里比較深刻的一些技術點分享出來，希望能給大家參考。