リアルタイム事前阻止の最終目標

Linuxリアルタイムプリエンプション対応の到達点

• Linuxにリアルタイム対応を追加する作業は2004年から始まり、現在は仕上げ段階に入っている。
• リアルタイムプリエンプションの目的は、最高優先度のプロセスが最小限の遅延で実行できるようにすることであり、そのためカーネルを可能な限り多くの状況でプリエンプト可能にしている。
• この作業はカーネルの中核部分の書き直しにつながり、リアルタイム用途を超える恩恵ももたらしている。

printk()問題の解決

• カーネルでシステムコンソールやログにメッセージを送る際に使われるprintk()関数は同期的に動作し、設定されたすべての宛先にメッセージが送信されるまで返らない。
• リアルタイム開発者たちはprintk()出力を別スレッドへ移して非同期化したが、これは一時的な解決策にすぎなかった。
• 2018年から本格的に進められてきたprintk()問題は、およそ300件のパッチを通じて解決に向かっており、なお解決すべき複雑な問題がいくつか残っている。

リアルタイムプリエンプションコードのメインライン統合の見通し

• リアルタイムプリエンプションコードの残りの部分が、2024年末の20周年を迎える前にメインラインへ統合されることへの期待が示された。
• printk()コード自体に最近大きな変更はなかったが、コンソールドライバを1つずつ更新できるようにハンドオーバーコードが変更された。
• 重要なメッセージは最初の行が出力される前にメッセージバッファへ完全にコピーされるようコードが変更され、問題のあるコンソールドライバによるシステムダウンを防ぐため、安全なコンソールに先にメッセージを記録する。

GN⁺の意見

• Linuxカーネルにリアルタイムプリエンプション対応を追加する作業はほぼ完了段階にあり、これはリアルタイム処理を必要とするシステムに大きな恩恵をもたらす。
• printk()関数の非同期化はシステムの応答性を向上させ、リアルタイムプリエンプションの目標達成に重要な役割を果たす。
• この記事はLinuxカーネル開発における重要な前進を示しており、カーネル開発に関心のある人々にとって興味深い内容を提供している。

[GN⁺]

Hacker Newsの意見

• QNXマイクロカーネルの利点

  • QNXマイクロカーネルは数十年前から、あらゆる処理に上限を設けることで信頼性を保証している。
  • マイクロカーネルのコードは数万行しかなく、メモリ割り当て、CPUディスパッチ、プロセス間メッセージ受け渡しのみを担当する。
  • ドライバーやロガーを含むその他すべての機能はユーザー空間にあり、高優先度スレッドによってプリエンプト可能である。
  • QNXカーネルは文字列処理を一切行わないため、文字列のパース、フォーマット、メッセージ受け渡しで発生する問題がない。

• Linuxのリアルタイム処理の問題

  • Linuxはリアルタイム処理に適さない構造で、カーネルコードが数百万行に達し、すべてのコードをプリエンプト可能にしなければならない。
  • リアルタイムアーキテクチャとして不向きであるため、これを修正するのに数十年かかった。
  • カーネルの問題だけに焦点を当てるのは、CPUレベルの問題を見落としている可能性がある。

• カーネルのロギング機能と実際のユースケース

  • システムがダウンする状況でもログメッセージを出力するためにカーネルがどれほど努力しているかという例が、実際のデプロイでどのように活用されているかを説明している。

• リアルタイムなハードウェア／ソフトウェア組み合わせの代替可能性

  • リアルタイム処理が必要なハードウェア／ソフトウェアの組み合わせが、安価で低消費電力・高クロックのARMおよびx86チップに置き換えられるのかという疑問を提起している。
  • クロック速度が上がるにつれて、完全なリアルタイム処理の重要性が低下する可能性があると述べている。

• 「ハード」対「ソフト」リアルタイムアプリケーションの区別

  • 「ハード」リアルタイムアプリケーションでは、Linuxのような汎用OSを使わないほうが望ましい。
  • 「ソフト」リアルタイムアプリケーション（例: ビデオ会議、音声再生）では、多少の遅延やフレーム欠落は大きな問題にならない。
  • LinuxをリアルタイムOSにしようという議論は、すでに実現可能な「ソフト」リアルタイムのユースケースに焦点を当てている。
  • カーネルを完全にプリエンプト可能にし、スケジューリングの制御を高めることは、リアルタイムOSやベアメタルコードを置き換えることよりも、システムの健全な管理にとって意味が大きい。

• Linuxカーネルのリアルタイム処理とハードウェアの限界

  • Linuxカーネルがリアルタイム処理をサポートしても、キャッシュやCPU内部の複雑な機能のために、ハードウェアがリアルタイムをサポートできない可能性がある。
  • 真のリアルタイム処理には、複雑なハードウェアよりも単純なCPUアーキテクチャが好まれる。

• 同期ロギングの問題点

  • GLOG（Googleのロギングライブラリ）のような同期ロギングが、ディスクI/Oでブロックされてサービス遅延を引き起こす問題を経験した。

• 特定プロセスの応答性を保証する方法

  • 特定プロセスの応答性を重視するなら、そのプロセスに専用のCPUコアと連続したメモリ領域を割り当て、OSの残り部分から分離されたネットワークカードに直接アクセスできるようにすべきである。

• Linuxのリアルタイムプリエンプト機能と過去の経験

  • 過去にLinuxカーネルへRT_PREEMPTパッチを適用して科学機器に使った経験と、それによって改善したレイテンシおよびジッターへの印象を共有している。

• 一般ユーザーへの影響

  • リアルタイム処理機能が一般ユーザーにとって何を意味するのか、特定の状況でのみ有効化するのか、あるいは一般的なシステムの応答性向上にも役立つのかという疑問を提起している。