リアルタイム優先順位（chrt -f 99）でプロセスを実行すると欠点がありますか？
私の仮説は、これが好みと組み合わされ、私のプロセスのプリエンプションが最小化され、ジッタ（特にネットワーク待ち時間）が最小限に抑えられることです。これは全体の待ち時間には役立ちませんが、今はもっと心配です。ジッタ関連。
（カーネル：2.6.16/3.0）
ベストアンサー1
リアルタイムプロセス実行の最も即時の欠点は、プロセスがシステム内の他のすべてのプロセスを簡単に中断できることです。ユーザーの観点からは、リアルタイムプロセスがCPUを使用している限り、コンピュータはキーボード、マウス、またはネットワークにまったく反応しなくなります。問題が発生し、プロセスが無限ループに陥ったり、プロセスが定期的に入力を待たずに長期実行計算を開始した場合でも、これが発生する可能性があります。 （たとえば、リアルタイム優先順位でSETI @ homeを実行しないでください。）
マルチコアCPUの別々のシングルスレッドプロセスでは、優先順位の低いプロセスが他のコアを使用できるため、この問題が発生する可能性はほとんどありません。ただし、プロセスが子プロセスを作成すると同じリアルタイム優先順位が継承されるため、注意しないと状況が制御されない可能性があります。
これsched_setscheduler(2)マニュアルページには良いアドバイスがあります。
SCHED_FIFOまたはSCHED_RRに予約されているプロセスの非ブロック無限ループは、優先順位の低いすべてのプロセスを永久にブロックするため、ソフトウェア開発者は常にコンソールをテスト対象アプリケーションよりも高い静的優先順位に維持する必要があります。予約済みのシェルを使用できます。これにより、期待どおりにブロックまたはシャットダウンされないテスト済みのライブアプリケーションを緊急シャットダウンできます。 getrlimit(2) の RLIMIT_RTTIME リソース制限の説明も参照してください。
それは皮でなければなりませんコンソールから- すべてのXにリアルタイムの優先順位を付けたい場合を除き、Xtermでは使用できません。