リアルタイムの優先順位で実行中のプロセスの欠点？

リアルタイムの優先順位（chrt -f 99）でプロセスを実行することの欠点はありますか？

私の仮説では、これをアフィニティと組み合わせると、プロセスのプリエンプションが最小限に抑えられ、ジッター（特にネットワークレイテンシ）が最小限に抑えられます。これは全体的なレイテンシには役立ちませんが、現時点ではジッタに関係しています。

（カーネル：2.6.16 / 3.0）

リアルタイムプロセスを実行することの最も直接的な欠点は、プロセスがシステム上の他のすべてのプロセスを簡単に枯渇させる可能性があることです。あなたの視点からの結果は、リアルタイムプロセスがCPUを使用している限り、コンピュータがキーボード、マウス、そしておそらくネットワークに完全に応答しないということです。これは、何か問題が発生してプロセスが無限ループに入った場合や、プロセスが定期的に入力を待たずに長時間の計算を開始した場合に発生する可能性があります。（したがって、たとえば、リアルタイムの優先順位でSETI @ homeを実行しないでください。）

優先度の低いプロセスが使用できるコアが他にもあるため、マルチコアCPU上の単一のシングルスレッドプロセスがこの問題を引き起こす可能性は低くなります。ただし、そのプロセスが子プロセスを作成する場合、それらは同じリアルタイムの優先順位を継承するため、注意しないと事態が制御不能になる可能性があります。

sched_setscheduler(2)manページには、良いアドバイスがあります：

SCHED_FIFOまたはSCHED_RRでスケジュールされたプロセスの非ブロッキング無限ループは、優先度の低いすべてのプロセスを永久にブロックするため、ソフトウェア開発者は、テストされたアプリケーションよりも高い静的優先度でスケジュールされたシェルを常にコンソールで利用できるようにする必要があります。これにより、期待どおりにブロックまたは終了しない、テスト済みのリアルタイムアプリケーションを緊急停止できます。getrlimit（2）のRLIMIT_RTTIMEリソース制限の説明も参照してください。

Xリアルタイムの優先順位もすべて与えたいのでない限り、Xtermの下ではなく、コンソール上のシェルでなければなりません。