深入實時 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中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive