深入實時 Linux

實時 Linux 在過去十年中已經走了很長的路。Linutronix 的 Jan Altenberg 提供了對該主題做了概述，並在 ELC Europe 的影片中提供了新的 RTL 效能基準。

實時 Linux（RTL）是一種啟用 PREEMPT_RT 的主線 Linux，在過去十年中已經走了很長的路。大約 80％ 的確定性的 PREEMPT_RT 補丁現在可用於主線核心本身。然而，Linux 上單核心 RTL 的最強大的替代品——雙核心 Xenomai——繼續聲稱在減少延遲上有巨大的優勢。在去年 10 月的 歐洲嵌入式 Linux 會議的演講中，Jan Altenberg 反駁了這些宣告，同時對實時主題做了論述。

德國嵌入式開發公司 Linutronix 的 Altenberg 並不否認 Xenomai 和 RTAI 等雙核方法提供較低的延遲。然而，他揭示了新的 Linutronix 基準，旨在表明差異不如所聲稱的那樣大，特別是在實際使用中。爭議較少的是，他認為 RTL 更易於開發和維護。

在我們深入永恆的 Xenomai 與 RTL 的辯論之前，請注意，2015 年 10 月，開源自動化開發實驗室（OSADL）將 RTL 專案的控制權轉移給了管理 Linux.com 的 Linux 基金會。此外，Linutronix 是 RTL 專案的主要貢獻者，並承擔了 x86 的維護者。

RTL 的進步是過去十年中 Linux 從實時作業系統（RTOS）中獲得市場佔有率的幾個原因之一。實時作業系統在微控制器上比應用處理器上更頻繁出現，並且在缺乏高階使用者級作業系統（如 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 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出