# 深入實時 Linux
原創?Linux技術?2017-07-21 22:37

> 實時 Linux 在過去十年中已經走了很長的路。Linutronix 的 Jan Altenberg 提供了對該主題做了概述,并在 ELC Europe 的視頻中提供了新的 RTL 性能基準。 -- Eric Brown
> 本文導航
>
> * -雙內核實時 …… 36%
>
>
> * -睡眠自旋鎖 …… 61%
> 編譯自: https://www.linux.com/news/event/open-source-summit-na/2017/2/inside-real-time-linux
>
> 作者: Eric Brown
>
> 譯者: geekpi
> 實時 Linux 在過去十年中已經走了很長的路。Linutronix 的 Jan Altenberg 提供了對該主題做了概述,并在 ELC Europe 的視頻中提供了新的 RTL 性能基準。
實時 Linux(RTL)是一種啟用 PREEMPT_RT 的主線 Linux,在過去十年中已經走了很長的路。大約 80% 的確定性的 PREEMPT_RT[1] 補丁現在可用于主線內核本身。然而,Linux 上單內核 RTL 的最強大的替代品——雙內核 Xenomai——繼續聲稱在減少延遲上有巨大的優勢。在去年 10 月的 歐洲嵌入式 Linux 會議[2]的演講中,Jan Altenberg 反駁了這些聲明,同時對實時主題做了論述。
德國嵌入式開發公司 Linutronix[3] 的 Altenberg 并不否認 Xenomai 和 RTAI 等雙核方法提供較低的延遲。然而,他揭示了新的 Linutronix 基準,旨在表明差異不如所聲稱的那樣大,特別是在實際使用中。爭議較少的是,他認為 RTL 更易于開發和維護。
在我們深入永恒的 Xenomai 與 RTL 的辯論之前,請注意,2015 年 10 月,開源自動化開發實驗室[4](OSADL)將 RTL 項目的控制權[5]轉移給了管理 Linux.com 的 Linux 基金會。此外,Linutronix 是 RTL 項目的主要貢獻者,并承擔了 x86 的維護者。
RTL 的進步是過去十年中 Linux 從實時操作系統(RTOS)中獲得市場占有率[6]的幾個原因之一。實時操作系統在微控制器上比應用處理器上更頻繁出現,并且在缺乏高級用戶級操作系統(如 Linux)的單用途設備上實現實時很簡單。
Altenberg 通過清除關于實時確定性的內核方案的一些常見的誤解開始他的演講。Altenberg 告訴他的 ELCE 觀眾:“實時不是快速執行,這基本上是決定論和定時保證。實時為你提供保證某些內容將在給定的時間內執行。你不想要盡可能快,但是要盡快指定。”
在給定的執行時間內的遲緩的反應會導致嚴重后果,特別是當它可能導致人們受到傷害時,開發人員往往會使用實時的方式。這就是為什么實時性仍然在很大程度上受到工廠自動化行業的推動,并且越來越多地出現在汽車、火車和飛機上。然而,并不總是生死攸關的情況 - 金融服務公司使用 RTL 進行高頻交易。
Altenberg 說:“實時需求包括確定性的定時行為、搶占、優先級繼承和優先級上限。最重要的要求是高優先級任務總是需要能夠搶占低優先級的任務。”
Altenberg 強烈建議不要使用術語“軟實時”來描述輕量級實時解決方案。“你可以是確定性的或者不是,但兩者之間什么也沒有。”
# 雙內核實時
像 Xenomai 和 RTAI 這樣的雙內核方案部署了一個與單獨的 Linux 內核并行運行的微內核,而像 RTL 這樣的單內核方案使得 Linux 本身能夠實時運行。Altenberg 說:“使用雙內核,當優先級實時程序不在微內核上運行時,Linux 可以獲得一些運行時間。 “問題是人們需要維護微內核并在新的硬件上支持它。這需要巨大的努力,并且它的開發社區不是很大。另外,由于 Linux 不直接在硬件上運行,所以你需要一個硬件抽象層(HAL)。有兩件事要維護,你通常會落后主流內核一步。”
Altenberg說:“RTL 的挑戰以及花了這么久才出現的原因是,要使 Linux 實時,你基本要修改每個內核文件。” 然而,大部分工作已經完成并合并到主線,開發人員并不需要維護一個微內核或 HAL。
Altenberg 繼續解釋了 RTAI 和 Xenomai 之間的差異。“使用 RTAI,你將編寫一個由微內核調度的內核模塊。這就像內核開發 - 真的很難深入,很難調試。”
RTAI 的開發可能會更加復雜,因為工業用戶通常希望包括封閉的源代碼以及 GPL 內核代碼。 Altenberg 說:“你必須決定哪些部分可以進入用戶態,哪些部分可以通過實時的方式進入內核。”
RTAI 與 RTL 想必支持更少的硬件平臺,特別是 x86 之外。雙內核 Xenomai 將 RTAI 作為主要的雙內核方式,比 RTAI 具有更大的操作系統支持。更重要的是,Altenberg 說:“它提供了“在用戶空間中進行實時的合適解決方案。要做到這一點,他們實現了皮膚的概念 - 一個用于不同 RTOS 的 API 的仿真層,比如 POSIX。這使你可以重用一些 RTOS 中的現有代碼的子集。”
然而,使用 Xenomai,你仍然需要維護一個單獨的微內核和 HAL。有限的開發工具是另一個問題。Altenberg說:“與 RTAI 一樣,你不能使用標準的 C 庫。你需要專門的工具和庫。即使對于 POSIX 來說,你也必須鏈接到 POSIX 層,這更復雜。” 他補充說,任何一個平臺,很難將超過 8 到 16 個 CPU 的微內核擴展到金融服務中使用的大型服務器集群。
# 睡眠自旋鎖
主要的單內核解決方案是基于 PREEMPT.RT 的 RTL,它主要由 Thomas Gleixner 和 IngoMolnár 在十多年前開發。PREEMPT.RT 重新生成內核的 “spinlock” 鎖定原語,以最大化 Linux 內核中的可搶占部分。(PREEMPT.RT 最初稱為睡眠自旋鎖補丁)
PREEMPT.RT 不是在硬中斷環境中運行中斷處理程序,而是在內核線程中運行它們。Altenberg 說:“當一個中斷到達時,你不會運行中斷處理程序代碼。你只是喚醒相應的內核線程,它運行處理程序。這有兩個優點:內核線程可以中斷,并且它會顯示在進程列表中,有自己的 PID。所以你可以把低優先級的放在不重要的中斷上,高優先級的放在重要的用戶態任務上。”
由于大約 80% 的 PREEMPT.RT 已經在主線上,任何 Linux 開發人員都可以使用面向 PREEMPT.RT 的內核組件,如定時器、中斷處理程序、跟蹤基礎架構和優先級繼承。Altenberg說:“當他們制作實時 Linux 時,一切都變得可以搶占,所以我們發現了很多競爭條件和鎖定問題。我們修復了這些,并把它們推送到主線,以提高 Linux 的穩定性。”
因為 RTL 主要在 Linux 主線上,Altenberg 說:“PREEMPT.RT 被廣泛接受,擁有龐大的社區。如果你編寫一個實時應用程序,你不需要知道很多關于 PREEMPT.RT 的知識。你不需要任何特殊的庫或 API,只需要標準的 C 庫、Linux 驅動程序和 POSIX 程序。”
你仍然需要運行一個補丁來使用 PREEMPT.RT,它每隔兩個 Linux 版本更新一次。然而,在兩年內,剩下的 20% 的 PREEMPT.RT 應該會進入 Linux,所以你就“不再需要補丁”了。
最后,Altenberg 透露了他的 Xenomai 對 RTL 延遲測試的結果。Altenberg說:“有很多論文聲稱 Xenomai 和 RTAI 的延遲比 PREEMPT.RT 更小。但是我認為大部分時候是 PREEMPT.RT 配置不好的問題。所以我們帶來了一個 Xenomai 專家和一個 PREEMPT.RT 專家,讓他們配置自己的平臺。”
Altenberg 稱,雖然 Xenomai 在大多數測試中表現更好,并且有更少的性能抖動,但是差異不如一些 Xenomai 擁護者聲稱的高達 300% 至 400% 的延遲優勢。當用戶空間任務執行測試時,Altenberg 說這是最現實的、最重要的是測試,最糟糕的情況下 Xenomai和 RTL/PREEMPT.RT 都是 90 到 95 微秒的反應時間。
當他們在雙 Cortex-A9 系統中隔離單個 CPU 來處理中斷時,Altenberg 表示這相當普遍,PREEMPT.RT 執行得更好,大約80微秒。(有關詳細信息,請查看大約第 33 分鐘的視頻。)
Altenberg 承認與 OSADL 的兩到三年測試相比,他的 12 小時測試是最低標準,而且它不是一個“數學證明”。無論如何,考慮到 RTL 更簡單的開發流程,它都值得一試。他總結說:“在我看來,將完整功能的 Linux 系統與微內核進行比較是不公平的。”
* * *
via: https://www.linux.com/news/event/open-source-summit-na/2017/2/inside-real-time-linux
作者:ERIC BROWN[7] 譯者:geekpi 校對:wxy
本文由 LCTT 原創編譯,Linux中國 榮譽推出
* [1]: PREEMPT_RT - https://www.linux.com/blog/intro-real-time-linux-embedded-developers
* [2]: 歐洲嵌入式 Linux 會議 - http://events.linuxfoundation.org/events/archive/2016/embedded-linux-conference-europe
* [3]: Linutronix - https://linutronix.de/
* [4]: 開源自動化開發實驗室 - http://archive.linuxgizmos.com/celebrating-the-open-source-automation-development-labs-first-birthday/
* [5]: 控制權 - http://linuxgizmos.com/real-time-linux-shacks-up-with-the-linux-foundation/
* [6]: 獲得市場占有率 - https://www.linux.com/news/embedded-linux-keeps-growing-amid-iot-disruption-says-study
* [7]: ERIC BROWN - https://www.linux.com/users/ericstephenbrown
* * * * *
本文來源:[深入實時 Linux](http://www.toutiao.com/a6445229605447975182/)
- 開始
- 公益
- 更好的使用看云
- 推薦書單
- 優秀資源整理
- 技術文章寫作規范
- SublimeText - 編碼利器
- PSR-0/PSR-4命名標準
- php的多進程實驗分析
- 高級PHP
- 進程
- 信號
- 事件
- IO模型
- 同步、異步
- socket
- Swoole
- PHP擴展
- Composer
- easyswoole
- php多線程
- 守護程序
- 文件鎖
- s-socket
- aphp
- 隊列&并發
- 隊列
- 講個故事
- 如何最大效率的問題
- 訪問式的web服務(一)
- 訪問式的web服務(二)
- 請求
- 瀏覽器訪問阻塞問題
- Swoole
- 你必須理解的計算機核心概念 - 碼農翻身
- CPU阿甘 - 碼農翻身
- 異步通知,那我要怎么通知你啊?
- 實時操作系統
- 深入實時 Linux
- Redis 實現隊列
- redis與隊列
- 定時-時鐘-阻塞
- 計算機的生命
- 多進程/多線程
- 進程通信
- 拜占庭將軍問題深入探討
- JAVA CAS原理深度分析
- 隊列的思考
- 走進并發的世界
- 鎖
- 事務筆記
- 并發問題帶來的后果
- 為什么說樂觀鎖是安全的
- 內存鎖與內存事務 - 劉小兵2014
- 加鎖還是不加鎖,這是一個問題 - 碼農翻身
- 編程世界的那把鎖 - 碼農翻身
- 如何保證萬無一失
- 傳統事務與柔性事務
- 大白話搞懂什么是同步/異步/阻塞/非阻塞
- redis實現鎖
- 淺談mysql事務
- PHP異常
- php錯誤
- 文件加載
- 路由與偽靜態
- URL模式之分析
- 字符串處理
- 正則表達式
- 數組合并與+
- 文件上傳
- 常用驗證與過濾
- 記錄
- 趣圖
- foreach需要注意的問題
- Discuz!筆記
- 程序設計思維
- 抽象與具體
- 配置
- 關于如何學習的思考
- 編程思維
- 談編程
- 如何安全的修改對象
- 臨時
- 臨時筆記
- 透過問題看本質
- 程序后門
- 邊界檢查
- session
- 安全
- 王垠
- 第三方數據接口
- 驗證碼問題
- 還是少不了虛擬機
- 程序員如何談戀愛
- 程序員為什么要一直改BUG,為什么不能一次性把代碼寫好?
- 碎碎念
- 算法
- 實用代碼
- 相對私密與絕對私密
- 學習目標
- 隨記
- 編程小知識
- foo
- 落盤
- URL編碼的思考
- 字符編碼
- Elasticsearch
- TCP-IP協議
- 碎碎念2
- Grafana
- EFK、ELK
- RPC
- 依賴注入
- 科目一
- 開發筆記
- 經緯度格式轉換
- php時區問題
- 解決本地開發時調用遠程AIP跨域問題
- 后期靜態綁定
- 談tp的跳轉提示頁面
- 無限分類問題
- 生成微縮圖
- MVC名詞
- MVC架構
- 也許模塊不是唯一的答案
- 哈希算法
- 開發后臺
- 軟件設計架構
- mysql表字段設計
- 上傳表如何設計
- 二開心得
- awesomes-tables
- 安全的代碼部署
- 微信開發筆記
- 賬戶授權相關
- 小程序獲取是否關注其公眾號
- 支付相關
- 提交訂單
- 微信支付筆記
- 支付接口筆記
- 支付中心開發
- 下單與支付
- 支付流程設計
- 訂單與支付設計
- 敏感操作驗證
- 排序設計
- 代碼的運行環境
- 搜索關鍵字的顯示處理
- 接口異步更新ip信息
- 圖片處理
- 項目搭建
- 閱讀文檔的新方式
- mysql_insert_id并發問題思考
- 行鎖注意事項
- 細節注意
- 如何處理用戶的輸入
- 不可見的字符
- 抽獎
- 時間處理
- 應用開發實戰
- python 學習記錄
- Scrapy 教程
- Playwright 教程
- stealth.min.js
- Selenium 教程
- requests 教程
- pyautogui 教程
- Flask 教程
- PyInstaller 教程
- 蜘蛛
- python 文檔相似度驗證
- thinkphp5.0數據庫與模型的研究
- workerman進程管理
- workerman網絡分析
- java學習記錄
- docker
- 筆記
- kubernetes
- Kubernetes
- PaddlePaddle
- composer
- oneinstack
- 人工智能 AI
- 京東
- pc_detailpage_wareBusiness
- doc
- 電商網站設計
- iwebshop
- 商品規格分析
- 商品屬性分析
- tpshop
- 商品規格分析
- 商品屬性分析
- 電商表設計
- 設計記錄
- 優惠券
- 生成唯一訂單號
- 購物車技術
- 分類與類型
- 微信登錄與綁定
- 京東到家庫存系統架構設計
- crmeb
- 命名規范
- Nginx https配置
- 關于人工智能
- 從人的思考方式到二叉樹
- 架構
- 今日有感
- 文章保存
- 安全背后: 瀏覽器是如何校驗證書的
- 避不開的分布式事務
- devops自動化運維、部署、測試的最后一公里 —— ApiFox 云時代的接口管理工具
- 找到自己今生要做的事
- 自動化生活
- 開源與漿果
- Apifox: API 接口自動化測試指南