sched_setscheduler(2) とその仲間を使用すると、2 つの異なるソフト リアルタイム スケジューラ SCHED_FIFO SCHED_RR を使用できます。これらのスケジューラの下で実行されているプロセスは、通常のプロセスよりも優先順位が高くなります。したがって、これらのプロセスがいくつかあり、それらの間の優先順位を制御している限り、実際には非常に優れたリアルタイムの応答を得ることができます.
コメントでリクエストされたとおり、SCHED_FIFO と SCHED_RR の違いは次のとおりです。
「リアルタイム」スケジューラでは、最大 100 の異なる優先度があります (POSIX は 32 の異なるレベルしか必要としないため、実際の数を取得するには sched_get_priority_min(2) と sched_get_priority_max(2) を使用する必要があります。スケジューラは両方とも、プロセスを横取りすることによって機能します)。優先度の低いスレッドとの違いは、同じ優先度のタスクを処理する方法にあります。
SCHED_FIFO は、先入れ先出しスケジューラ (名前の由来) です。これは、最初に実行キューに到達したタスク、完了するまで実行を許可されたタスク、自発的に実行キューのスペースを放棄したタスク、またはより優先度の高いタスクによってプリエンプトされたタスクを意味します。
SCHED_RR は、ラウンド ロビン スケジューラです。これは、同じ優先度のタスクが特定の時間単位でのみ実行できることを意味します。このタイム クォンタムがなくなったときにタスクがまだ実行されている場合、タスクはプリエンプトされ、実行キュー内の次のタスク (同じ優先度を持つ) は、そのタイム クォンタムまで実行できます。 SCHED_FIFO と同様に、優先度の高いタスクは優先度の低いタスクを先取りしますが、優先度の高いタスクによって横取りされたタスクが再度実行を許可されると、そのクォンタムに残っている時間だけ実行が許可されます。タスクのタイム クォンタムを設定する方法については、sched_rr_get_interval(2) の Noes セクションを参照してください。
MRG
RT 以外のカーネルでサブミリ秒を保証するのは難しいでしょう。ここ数年で多くの非常に優れた作業が行われたことは知っていますが (たとえば、大きなカーネル ロックはなくなりました)、それだけではまだ十分ではありません。
CERN と Fermilab のフレンドリーな原子論者から Scientific Linux を見てもらうことができます。これにより、MRG をインストールすることができ (私のリンクを参照)、PREEMPT_RT パッチのプレパック セットアップが提供されます。
または、お金があれば、Redhat MRG を入手できます。これは、PREEMPT-RT パッチが組み込まれた完全にサポートされた Linux ディストリビューションであるため、問題が発生しやすいカーネルのパッチが不要になります。
つまり、Redhat はたくさん請求します。 そのために（インストールごとに年間3000ドル）。最大の顧客の 1 つは高速取引の投資家であり、まだたくさんのお金を持っているので、年間 3,000 ドル/箱がドアから出て行くことに気付かないことに、彼らは転落したと思います.
MRG との付き合い方
私は MRG で (上記の両方を使用して) かなりの作業を行いましたが、これはかなり優れています。ストックカーネルの割り込みサービスルーチンをスレッドに置き換えて、割り込みを処理します。つまり、IRQ スレッドよりも高い優先順位でソフトウェアを実行できるということです! 保証に近づきたい場合は、このようなことを行う必要があります。 アプリケーションでミリ秒未満のレイテンシを実現します。
MRG がメインライン カーネルに徐々に移行しているように見えますが、これは良いことだと思います。いつかそれが主流になる日が来るかもしれません.
その他の落とし穴
最新の CPU の熱管理は、本当に頭の痛い問題です。 CPU が少しウォームアップしたという理由だけで、システム管理割り込みが (OS ではなく BIOS によって) サービスされている間、0.3 秒間ロックアップするシステムがありました。これを参照してください。そのため、基盤となるハードウェアの機能に注意する必要があります。一般に、最新の PC の管理された冷却をやめることについて心配し始め、常に高速で回転する大きなファンに戻る必要があります。
Linux では、他のプロセスからリアルタイム プロセスへの「障害」を取り除くことで、かなり遠くまで行くことができます。私は Windows で同じことを試しましたが、これは正しく理解するのがはるかに困難ですが、方向性を示しています。一種のチェックリスト:
- 最も重要な (奇妙だが真実):ハードウェア。ラップトップには行かないでください。これは、SMM 割り込み中に奇妙なことを行うように最適化されます。あなたにできることは何もありません。
- ドライバー:Linux (および Windows) には、悪いドライバーと良いドライバーがあります。ハードウェア関連。それを知る唯一の方法はベンチマークです。
システムの残りの部分から分離し、すべての共有を無効にします:
- 1 つの CPU を分離 (
man cpuset）。通常のプロセス用とリアルタイム プロセス用の 2 つの CPU セットを作成します。 - コードのリアルタイム部分を最小限に抑えます。システムの他の部分と大きなバッファで通信します。 IO を最小限に減らします (IO の保証が不十分であるため)。
- プロセスのリアルタイム優先度を最高 (ソフト) にします。
- ハイパースレッディングを無効にする (共有したくない場合)
- 必要なメモリを事前に割り当て、メモリを mlock() します。
- 使用するデバイスを隔離します。専用の IRQ をデバイスに割り当てることから始めます (他のデバイスを別の IRQ に移動するか、他のデバイス/ドライバーを削除します)。
- 使用する IO を分離します。
システムの残りのアクティビティを減らします:
- 本当に必要なプロセスだけを開始する
- ディスクやその他のハードウェアなど、不要なハードウェアを削除します。
- スワッピングを無効にする
- Linux カーネル モジュールを使用したり、事前にロードしたりしないでください。モジュールの初期化は予測できません。
- できればユーザーも削除してください:)
安定して再現可能にする:
- すべての省エネルギーを無効にします。常に同じパフォーマンスが必要です。
- すべての BIOS 設定を確認し、「イベント」と「共有」をすべて削除します。そのため、派手なスピードステップや熱管理などはありません。低レイテンシを選択し、名前に「バースト」が含まれるものは選択しないでください。一般に、パフォーマンスが低下する代わりにスループットが犠牲になるためです。
- Linux ドライバの設定を確認し、待ち時間を短縮します (該当する場合)。
- 毎日リアルタイム カーネルのように見える最近のカーネルを使用します。
次に、ストレステストを使用してベンチマークを行い、最大を記録しながら何日もマシンをオンのままにします。
だから:頑張ってください:)