Linux之RTOS學習

時間 2019-12-08

標籤 linux rtos 學習欄目 Linux 简体版

原文原文鏈接

Linux之RTOS學習

RTOS: Real time operating systemhtml

系統選型

可選方案

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¹	x86/Arm	x86/Arm
File System	full²	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上，說明了其貢獻

注：inherit表明原生linux內核支持，上述三個系統均基於原生內核，原則上支持上述特性，暫無官方文檔說明，文件系統上支持RTOS的preempt_rt特性的會有所不一樣linux

選擇結果

根據上述的對比，我以爲選擇OSADL做爲本次詳細調研的對象會比較好。理由有三：git

OSADL在Real Time Operating System上做爲kernel.org的首選，有其優越的地方
OSADL背後有Open Source Automation Development Lab長期支持，遇到特別難的問題能夠發mail issue尋求解決方案
OSADL的內核版本較新，且持續更新中，自動駕駛是一個5年到10年的發展期，選擇有將來的項目會更好，好比致命的內核錯誤經過更新內核能解決也能保證自動駕駛的安全

下文的內容均基於OSADL展開github

文檔閱讀

OSADL Recommended Reading算法

A realtime preemption overview安全

SMP and Embedded Real Timebash

功能分析

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。³ 以後可使用Apollo調整過的內核。

RTLinux Supported Machines, refer to here ↩
RTLinux Combinations of File System and Kernel Feature Profiles, refer to here ↩
apollo kernel, refer to here ↩

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。