Linux之RTOS學習
RTOS: Real time operating system
系統選型
可選方案
- RTLinux - FSMLabs, WindRiver Systems - http://www.rtlinux.org/
- ChronOS - Systems Software Research Group - http://chronoslinux.org
- OSADLinux - Open Source Automation Development Lab - https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html
特性分析
RTLinux | ChronOS | OSADL | |
---|---|---|---|
Open Source | No | Yes | Yes |
License | GPL-2.0 | GPLv2 | / |
Kernel Version | 4.8.12 | 3.4.82 | 4.11.12 |
Platform | Linux | Linux | Linux |
Architecture | x86[1] | x86/Arm | x86/Arm |
File System | full[2] | full | full |
Device Drivers | inherit | inherit | inherit |
C/C++ Library | inherit | inherit | inherit |
Networking | inherit | inherit | inherit |
Flash Support | inherit | inherit | inherit |
USB Support | inherit | inherit | inherit |
Graphics Support | inherit | inherit | inherit |
GPU Support | inherit | inherit | inherit |
- Additional
- RTLinux
- 官方文檔齊全
- 付費訂閱后可以獲得支持
- ChronOS
- O(1)算法復雜度的實時調度算法
- OSADL
- 和Linux內核社區結合很緊密,同步最新的內核版本
- Patch是直接放在kernel.org,說明了其地位
- 部分特性已經合在Linux內核的mainline上,說明了其貢獻
- RTLinux
注:inherit代表原生linux內核支持,上述三個系統均基於原生內核,原則上支持上述特性,暫無官方文檔說明,文件系統上支持RTOS的preempt_rt特性的會有所不同
選擇結果
根據上述的對比,我覺得選擇OSADL作為本次詳細調研的對象會比較好。理由有三:
- OSADL在Real Time Operating System上作為kernel.org的首選,有其優越的地方
- OSADL背后有Open Source Automation Development Lab長期支持,遇到特別難的問題可以發mail issue尋求解決方案
- OSADL的內核版本較新,且持續更新中,自動駕駛是一個5年到10年的發展期,選擇有未來的項目會更好,比如致命的內核錯誤通過更新內核能解決也能保證自動駕駛的安全
下文的內容均基於OSADL展開
文檔閱讀
OSADL Recommended Reading
功能分析
PREEMPT_RT的特性:
- Preemptible critical sections
- Preemptible interrupt handlers
- Preemptible "interrupt disable" code sequences
- Priority inheritance for in-kernel spinlocks and semaphores
- Deferred operations
- Latency-reduction measures
信號量臨界區原理:
嚴格來說,搶占原本不能發生在一個非可搶占的內核。但是,由於訪問用戶數據的時候會發生類似頁錯誤的事情可以顯式地訪問調度器,則搶占功能可以在這里加入。
優先級繼承原理:(writer和多個reader之間)
實現了一個reader-writer lock, writer和reader共享,這個lock的狀態可以被reader訪問,但無法被reader訪問write-acquire方法。多reader優先級繼承花費的時間會影響到調度延遲上。
事件機制不適用優先級繼承原理:
引入事件機制,任何的任務都有可能調用down()方法,這樣會導致高優先級的任務被喚醒(有可能在休眠狀態)
注意事項
Warning : raw_spinlock_t和raw_rwlock_t的非正確使用都會破壞PREEMPT_RT的實時機制,請注意
實時任務使用上的編碼注意事項,可以通過spinlock_t等非raw形式訪問,或根據需求封裝raw,盡量避免原生使用raw_lock。
編譯和安裝
源碼編譯
# Download linux souce code
wget https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.11.12.tar.xz
xz -cd linux-4.11.12.tar.xz | tar xvf -
cd linux-4.11.12
# patch rt to kernel
xzcat ../patch-4.11.12-rt10.patch.xz | patch -p1
make defconfig # default is x86_64_config
make
至此,新的kernel編譯成功
安裝內核
sudo make modules_install install
remove the GRUB_HIDDEN_TIMEOUT_QUIET line from /etc/default/grub
increase the GRUB_DEFAULT timeout from 0 to 15 seconds
sudo update-grub2
虛擬機安裝測試
虛擬機硬盤配置:
- 處理器 i7-6700K中的2個核心處理器
- 內存 3G
- 硬盤 50G
系統配置:
- Ubuntu14.04
啟動配置:
- GRUB,多內核選擇啟動
- 4.4.0-31-generic
- 4.4.79-rt92
運行和測試
測試場景思考
方案一:Kernel.org上的Realtime測試方法
在kernel.org上的官方測試方法,Thomas Gleixner撰寫了一個測試負載系統的實時能力的工具cyclictest。對於每一個CPU邏輯核心,都跑一個單獨的線程,每個線程都在一個獨立的進程當中,測試內核的線程調度能力。
注意,cyclictest需要運行持續一段時間,等待調度算法穩定后的結果才能說明當前系統的調度時延,短時間內的調度快慢不足以說明系統的實時性,非RT系統有可能在短時間內恰好快於RT系統。
方案二:opersys.com/lrtbf/上的Linux RT Benchmarking Framework
該實驗需要三台機器
- Target機器:測試不同的kernel的運行情況
- Logger機器:發送/接收/記錄來自Target機器的數據,最后生成報表
- Host機器:主控制機器,存儲發送的數據和Ping Flood的發送源,壓力測試的來源
可生成的報表內容包括
數據積累的實現消耗,中斷的響應時間
由於該實驗需要三台機器來進行,目前條件下不可進行,且結果預估也是RT系統比非RT系統性能更好,所以暫時決定先不進行該實驗,如有需要,后續再進行實驗測試。
通用測試腳本
方案一:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git
cd rt-tests
sudo apt-get install libnuma-dev # acquired
make
測試腳本運行
方案一
#################### non-RT OS ####################
>> sudo ./cyclictest -a -t -n -p99
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.25 0.11 0.04 1/299 1856
T: 0 (1853) P:99 I:1000 C: 20832 Min: 5 Act: 232 Avg: 425 Max: 23436
T: 1 (1854) P:99 I:1500 C: 13988 Min: 9 Act: 297 Avg: 427 Max: 25291
#################### RT OS ####################
>> sudo ./cyclictest -a -t -n -p99
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.18 0.19 0.18 1/353 9062
T: 0 (9061) P:99 I:1000 C: 9087 Min: 7 Act: 328 Avg: 406 Max: 4636
T: 1 (9062) P:99 I:1500 C: 6118 Min: 10 Act: 367 Avg: 410 Max: 1366
最右邊的那一列代表着最重要的測試結果,最大值比平均值重要,評價實時系統的最重要指標。
常用平台對比
上述測試是在常用的平台Ubuntu14.04下進行的,兩個內核分別是官方內核4.4.0-31-generic和實時內核4.4.79-rt92
最大值對比:
CPU0 | CPU1 | |
---|---|---|
4.4.0-31-generic | 23436 | 25291 |
4.4.79-rt92 | 4636 | 1366 |
從上述結果的最差情況分析,官方內核跑出來的成績是25.291毫秒,而實時內核跑出來的成績達到了4.636毫秒,是前者的1/4的時間延遲。
平均值對比:
CPU0 | CPU1 | |
---|---|---|
4.4.0-31-generic | 425 | 427 |
4.4.79-rt92 | 406 | 410 |
從上述結果的平均值情況分析,官方內核跑出來的成績是0.426毫秒,而實時內核跑出來的成績達到了0.408毫秒,兩者之間的區別相差不大。原因是測試平台基本都處於空閑的狀態中,多次運行結果都在空閑狀態所以平均值相差不大,評價實時系統的關鍵參數依然是最大值。
結論分析
RTOS的實現原理是給線程增加了一個priority參數,允許搶占式優先調度該線程,以達到調度時延最低。
上述實驗結果中,可以很明顯的看出,RTOS的實時性比原生的OS有明顯的性能體現,最大時延上是原生的1/4時間。
在調研的過程中發現百度的Apollo內核中,也是使用了這個RT patch,並百度優化了以太網的驅動和解決了Nvidia驅動的bug。[3] 之后可以使用Apollo調整過的內核。