版權聲明：本文為本文為部落客原創文章，轉載請注明出處。如有問題，歡迎指正。部落格位址：https://www.cnblogs.com/wsg1100/
可能大部分人一直好奇VxWorks與xenomai對比，實時性孰優孰劣，正好筆者最近要做一個這方面的對比。聲明：下面資料，僅供個人參考，有不對的地方還請指出。
本文繼上一篇文章【原創】xenomai與VxWorks實時性對比（Jitter對比），主要對比VxWorks與xenomai兩個硬實時作業系統在對各類資源操作時，任務搶占切換的耗時。
一、環境
簡單介紹一下環境：
硬體平台：雙核cortex-A15處理器，CPU頻率1.5GHZ,記憶體2GB。
xenomai：Linux-4.19+xenomai 3.1，具體配置：略;
VxWorks：VxWorks 7，具體配置：略;
注：
- 由于VxWorks benchmark測試包含很多測試項，以下資料為其中包含的幾項，每項測試2萬次；xenomai與其一緻。
- 既然對比，那麼測試方法、資料處理就得和VxWorks一緻，是以xenomai測試用例實作參考VxWorks benchmark測試用例。
- xenomai的資料為使用者态測試，VxWorks資料為核心态測試，測試本身xenomai就處于劣勢，哈哈，有興趣的小夥伴可以将測試用例在xenomai核心态寫一份看看。
- xenomai測試用例使用Alchemy API編寫，Alchemy API是一層posix接口的封裝，是以Alchemy API性能可能弱于POSIX接口。
二、 名額概念
任務切換時間(task switching time)，定義為系統在兩個獨立的、處于就緒态并且具有相同優先級的任務之間切換所需要的時間。
切換所需的時間主要取決于儲存任務上下文所用的資料結構以及作業系統采用的排程算法的效率。産生任務切換的原因可以是資源可得，信号量的擷取等。任務切換是任一多任務系統中基本效率的測量點，它是同步的，非搶占的。影響任務切換的因素有：主機CPU的結構，指令集以及CPU特性等
2.1 單核CPU
即測試相關的任務運作在同一CPU核上，這裡表示單核上的上下文切換。
2.1.1 信号量響應上下文切換時間
信号量響應時間是指從一個任務釋放信号量到另一個等待該信号量的任務被激活的時間延遲。 在RTOS中，通常有許多任務同時競争某一共享資源，基于信号量的互斥通路保證了任一時刻隻有一個任務能夠通路公共資源。信号量響應時間反映了與互斥有關的時間開銷，是以也是衡量RTOS實時性能的一個重要名額。
- bmCtxSempend
① 建立兩個任務：高優先級任務\(Task1\) 和 優先級任務\(Task2\)；
②\(Task1\)先非阻塞擷取信号量，確定信号量為空。
③\(Task1\)記錄目前時間T1，再次擷取信号量導緻挂起；
④ 上下文切換到低優先級任務\(Task2\)運作，\(Task2\)讀取時間T2，再釋放信号量；
⑤\(Task1\)得到信号量恢複運作。計算切換時間\(T = T2 - T1\),反複進行②~⑤操作。
⑥最終統計最大值、最小值、平均值。
- bmCtxSemunpend
②\(Task1\)擷取信号量導緻挂起；
③上下文切換到低優先級任務\(Task2\)運作，\(Task2\)讀取時間\(T_1\)，再釋放信号量；
④ 高優先級\(Task1\)得到信号量恢複運作，讀取時間\(T_2\)。進入下一次循環，反複進行②~⑤操作。
⑤ 最終統計最大值、最小值、平均值。
2.1.2 消息隊列響應上下文切換時間
與信号量響應時間類似，是指從一個任務發送消息隊列到另一個等待該消息隊列的任務被激活的時間延遲。
- bmCtxMsgQPend
② \(Task1\)記錄目前時間T1，擷取讀取消息隊列導緻阻塞挂起；
③ 上下文切換到低優先級任務\(Task2\)運作，\(Task2\)讀取時間T2，再向消息隊列發送Byte資料，發送後阻塞；
④ \(Task1\)消息可用恢複運作。計算切換時間\(T = T2 - T1\),反複進行②~⑤操作。
- bmCtxMsgQunPend
②\(Task1\)接收消息導緻挂起；
③上下文切換到低優先級任務\(Task2\)運作，\(Task2\)讀取時間T1，發送1Byte消息；
④ 高優先級\(Task1\)消息可用恢複運作，讀取時間T2。進入下一次循環，反複進行②~⑤操作。
2.1.3 事件響應上下文切換時間
也就是對于event操作的上下文切換，與上面兩種類似不再說明。
2.1.4 任務上下文切換時間
以上測試中，在資源上任務切換，下面是單純的優先級排程下的任務切換。
需要注意的是：VxWorks中priority數值越高，優先級越低，xenomai相反。
① 優先級為50的任務\(Task1\) 建立更高優先級40的任務\(Task2\)；
② \(Task2\)建立後立即搶占，\(Task2\)運作後立即降低自身優先級為60，比\(Task1\)優先級低
③\(Task1\)此時為最高優先級得到運作，讀取時間T1，提升\(Task2\)優先級為40；
④ \(Task2\)此時為最高優先級搶占運作，發生一次上下文切換；
⑤ \(Task2\)運作後立即降低自身優先級為60；
⑥\(Task1\)此時為最高優先級得到運作，發生一次上下文切換；
測試時間\(T=T_2-T_1\)，包含了1次提升優先級操作耗時\(T_r\)、1次降低優先級操作耗時\(T_l\)、2次任務切換\(T_{sw}\)、2次讀取時間戳耗時\(T_{rt}\)。是以上下文切換時間\(T_{sw}=\frac{T-T_r-T_l-2T_{rt}}{2}\)。
2.1 SMP
實時任務分别運作在不同CPU上，其任務切換在上述的基礎上，還包含了多核間IPI 通信（Interrupt-Procecesorr Interrupt處理器間的中斷）耗時。
以bmCtxSemunpend示例如下，其餘的類似不再贅述。
三、 結果對比
3.1 單核
| Vxworks | avg | min | max |
|---|---|---|---|
| bmCtxSemPend | 1.387 | 0.162 | 5.205 |
| bmCtxSemUnpend | 1.389 | ||
| 1.719 | 0.325 | 6.181 | |
| bmCtxMsgQUnpend | 2.183 | 0.487 | 7.807 |
| bmCtxEventPend | 1.349 | 0.000 | 5.042 |
| bmCtxEventUnpend | 1.466 | 5.367 | |
| bmCtxTaskSwitch | 0.975 | 4.635 |
| Xenomai | |||
|---|---|---|---|
| 3.597 | 3.252 | 6.345 | |
| 3.735 | 3.415 | 7.482 | |
| 4.228 | 3.903 | 6.833 | |
| 5.368 | 8.622 | ||
| - | |||
| 8.365 | 0.326 | 63.522 |
可以看到xenomai
bmCtxTaskSwitch
資料比較差，為什麼什麼會這樣呢？VxWorks測試程式與核心都處于核心态（同一位址空間），而xenomai測試則是在使用者态測試，可以回到2.1.4小節，其中\(T=T_2-T_1\)這段時間内的每一個操作都是必須發起實時系統調用來完成的，其中修改優先級還涉及Linux線程部分，除此之外由于系統調用路徑複雜，每個系統調用時間不是确定的，比如前後兩次修改優先級操作的時間是不等的，這就造成計算出的\(T_{sw}\)失真。通俗的說這個測試方法不适合xenomai使用者态，将該測試放到xenomai核心态才與VxWorks具有可比性。
另外，本測試基于xenomai 3.1。xenomai任務對event資源不會發生阻塞喚醒（非搶占）了，xenomai3.0.8不存在這個問題，是以這兩項沒有測試資料。有興趣的小夥伴可以研究一下，順便還能向社群提個issue或patch，呵呵~~。
3.2 SMP
VxWorks沒有啟用SMP，是以這部分沒有VxWorks的資料，隻有xenomai的。
| CtxSmpAffinitySemUnPend | 3.826 | 3.578 | 8.296 |
| CtxSmpAffinityMsgQUnPend | 5.262 | 4.879 | 8.133 |
| CtxSmpNoAffinitySemUnPend | 3.766 | ||
| CtxSmpNoAffinityMsgQUnPend | 5.322 | 9.597 |
作者：wsg1100
出處：http://www.cnblogs.com/wsg1100/
本文版權歸作者和部落格園共有，歡迎轉載，但必須給出原文連結，并保留此段聲明，否則保留追究法律責任的權利。