syslog サーバーは、プログラムからのログメッセージをネットワーク経由で送信します。送信の頻度が低いほど、保留中のトランザクションが大きくなる可能性があります。トランザクションが非常に大きい場合、I/O スパイクが発生する可能性があります。これを防ぐには、間隔を合理的な範囲で小さい値に維持します。

システムロギングデーモン syslogd は、さまざまなプログラムからメッセージを収集するために使用されます。また、カーネルが報告する情報をカーネルロギングデーモン klogd から収集します。通常、syslogd によりローカルファイルにログが記録されますが、リモートロギングサーバーにネットワーク経由でログを記録するように設定することもできます。

実行中のアプリケーションはすべて、システムリソースを使用します。システムで不要なアプリケーションが実行されないようにすることで、パフォーマンスを大幅に向上させることができます。

taskset ユーティリティーは CPU アフィニティーでのみ機能し、メモリーノードなどの他の NUMA リソースについては認識しません。プロセスバインディングを NUMA と併用する場合は、taskset の代わりに numactl を使用します。

NUMA API の詳細は、Andi Kleen 氏のホワイトペーパー An NUMA API for Linux を参照してください。

debugfs ファイルシステムは、デバッグや、ユーザーへの情報提供を目的として特別に設計されています。RHEL 8 では、これは /sys/kernel/debug/ ディレクトリーに自動的にマウントされます。

InfiniBand は、帯域幅を増やし、サービス品質 (QOS) を向上させ、フェイルオーバーを提供するためによく使用される通信アーキテクチャーの一種です。また、RDMA (Remote Direct Memory Access) メカニズムでのレイテンシー改善にも使用できます。

RHEL for Real Time での InfiniBand のサポートは、Red Hat Enterprise Linux 8 で利用可能なサポートと同じです。詳細は、InfiniBand および RDMA ネットワークの設定 を参照してください。

RoCEE (RDMA over Converged Enhanced Ethernet) は、イーサネットネットワークを介した RDMA (Remote Direct Memory Access) を実装するプロトコルです。これにより、重要なトランザクションに対して決定論ベースの低レイテンシーデータ転送を提供する一方で、データセンターで一貫性のある高速環境を維持できます。

High Performance Networking (HPN) は、RoCEE インターフェイスをカーネルに提供する共有ライブラリーセットです。HPN は、独立したネットワークインフラストラクチャーを経由する代わりに、標準のイーサネットインフラストラクチャーを使用してリモートシステムメモリーにデータを直接配置するため、CPU オーバーヘッドが少なく、インフラストラクチャーコストが削減されます。

RHEL for Real Time の RoCEE および HPN へのサポートは、RHEL 8 で提供されるサポートと同じです。

主要な RHEL カーネルでは、リアルタイムグループスケジューリング機能 CONFIG_RT_GROUP_SCHED がデフォルトで有効になっています。ただし、リアルタイムカーネルの場合、この機能は無効になります。

CONFIG_RT_GROUP_SCHED 機能は、kernel-rt パッケージで使用される PREEMPT_RT パッチセットとは独立して開発され、メインの RHEL カーネル上のリアルタイムプロセスで動作することを目的としています。CONFIG_RT_GROUP_SCHED 機能は、レイテンシーのスパイクを引き起こすことが知られているため、PREEMPT_RT が有効なカーネルでは無効化されています。したがって、メインの RHEL カーネルで実行しているコンテナーでワークロードをテストする場合は、コンテナー内で SCHED_FIFO または SCHED_RR タスクを実行できるように、一部のリアルタイム帯域幅をコンテナーに割り当てる必要があります。

リアルタイムスレッドは標準スレッドよりも優先度が高くなります。ポリシーには、最小値 1 から最大値 99 までの範囲のスケジューリング優先順位値があります。

次のポリシーは、リアルタイムにとって重要です。

各 SCHED_DEADLINE タスクは、period、runtime、および deadline パラメーターによって特徴付けられます。これらのパラメーターの値は、ナノ秒の整数です。

パラメーターを /etc/sysctl.conf ファイルに追加することにより、カーネルチューニングパラメーターに永続的な変更を加えることができます。

従来の UNIX および POSIX シグナルは、特にエラー処理に使用されますが、リアルタイムアプリケーションでのイベント配信メカニズムとしての使用には適していません。その理由は、現在の Linux カーネルシグナル処理コードが、非常に複雑なためです。これは主に、従来の動作と多くの API をサポートする必要があるためです。この複雑さは、シグナルの配信時に使用されるコードパスが常に最適とは限らず、アプリケーションでレイテンシーが長くなる可能性があることを意味します。

UNIX シグナルの本来の目的は、実行の異なるスレッド間で 1 つの制御スレッド (プロセス) を多重化することでした。シグナルはオペレーティングシステムの割り込みのように動作します。つまり、シグナルがアプリケーションに配信されると、アプリケーションのコンテキストが保存され、事前に登録したシグナルハンドラーの実行を開始します。シグナルハンドラーが完了すると、アプリケーションはシグナルの配信時の地点から処理を再開します。この動作は、実際には複雑になる可能性があります。

シグナルは、決定論ベースではないので、リアルタイムアプリケーションでは信頼できません。POSIX スレッド (pthreads) を使用してワークロードを分散し、さまざまなコンポーネント間の通信を行うことが望ましいオプションです。ミューテックスの pthreads メカニズム、条件変数、およびバリアを使用して、スレッドのグループを調整できます。このような比較的新しい構造によるコードパスは、シグナルに対する従来の処理コードよりもはるかにクリーンです。

sched_yield コマンドは、優先度の低いスレッドに実行の機会を与える同期メカニズムです。このタイプの要求は、適切に作成されていないアプリケーション内から発行すると失敗する可能性があります。

優先度が高いスレッドは sched_yield() を呼び出して、他のスレッドに実行の機会を与えることができます。呼び出しプロセスは、その優先度で実行されているプロセスのキューの末尾に移動します。これは、同じ優先度で他のプロセスが実行していない状況で発生すると、呼び出しプロセスの実行は継続されます。プロセスの優先度が高い場合は、ビジーループが発生し、マシンが使用できなくなる可能性があります。

SCHED_DEADLINE タスクが sched_yield() を呼び出すと、設定された CPU が放棄され、残りのランタイムには次の期間まで直ちにスロットリングが適用されます。sched_yield() の動作により、タスクは次の期間の開始時に起動できます。

スケジューラーは、実際に実行する他のスレッドがあるかどうかを判別できます。リアルタイムタスクで sched_yield() は使用しないでください。

systemd は、システムの起動時に実行するサービスのリアルタイムの優先度を設定します。一部のカーネルスレッドには非常に高い優先度が設定される場合があります。これにより、デフォルトの優先度を Real Time Specification for Java (RTSJ) の要件と適切に統合することができます。RTSJ には 10 から 89 までの優先度の範囲が必要です。

RTSJ が使用されていないデプロイメントでは、アプリケーションが使用できるスケジューリングの優先度が幅広くあります (90 未満)。重要なシステムサービスが実行されなくなる可能性があるので、49 を超える優先度のアプリケーションスレッドのスケジューリングには十分な注意を払ってください。そうしないと、ネットワークトラフィックのブロック、仮想メモリーのページングのブロック、ファイルシステムのジャーナリングのブロックによるデータの破損など、予測できない動作が発生する可能性があります。

アプリケーションスレッドが優先度 89 を超えてスケジュールされている場合は、スレッドが非常に短いコードパスのみを実行するようにしてください。これを行わないと、RHEL for Real Time カーネルの低レイテンシー機能が損なわれます。

リアルタイムアプリケーションの開発時には、プログラムの実行中に決定論ベースではないレイテンシーが発生しないように、システムの起動時にシンボルを解決することを検討してください。システムの起動時にシンボルを解決すると、プログラムの初期化に時間がかかる場合があります。動的リンカー/ローダーである ld.so を使用して LD_BIND_NOW 変数を設定することにより、動的ライブラリーをアプリケーションの起動時に読み込むように指示できます。

たとえば、このスクリプトは LD_BIND_NOW 変数を 1 の値でエクスポートしてから、FIFO のスケジューラーポリシーと 1 の優先度でプログラムを実行します。

#!/bin/sh

LD_BIND_NOW=1
export LD_BIND_NOW

chrt --fifo 1 _/opt/myapp/myapp-server &_

BIOS 電源管理オプションは、システムクロックの周波数を変更したり、CPU をさまざまなスリープ状態の 1 つにすることで、電力を節約できるようにします。このようなアクションは、システムが外部イベントに応答する速度に影響を与える可能性があります。

応答時間を改善するには、BIOS の電源管理オプションをすべて無効にします。

Error Detection and Correction (EDAC) ユニットは、Error Correcting Code (ECC) メモリーから通知されたエラーを検出および修正するためのデバイスです。通常 EDAC には、ECC をチェックしないオプションから、エラーに関するすべてのメモリーノードを定期的にスキャンするオプションまで、さまざまなオプションがあります。EDAC レベルが高いほど、BIOS が使用する時間が長くなります。これにより、重要なイベントの期限を逃す可能性があります。

応答時間を改善するには、EDAC をオフにします。これができない場合は、EDAC を最小機能レベルに設定します。

System Management Interrupts (SMI) は、システムが正常に動作していることを確認するハードウェアベンダーの機能です。BIOS コードは、通常、SMI 割り込みを処理します。SMI は通常、温度管理、リモートコンソール管理 (IPMI)、EDAC チェック、およびその他のハウスキーピングタスクに使用されます。

BIOS に SMI オプションが含まれる場合は、ベンダーおよび関連ドキュメントを確認して、それらを無効にしても安全な範囲を判断してください。

テストは、ハードウェアアーキテクチャー、またはBIOS もしくは EFI ファームウェアに起因する遅延を検出するため、hwlatdetect プログラムの実行中にシステムに負荷を掛ける必要はありません。hwlatdetect のデフォルト値では、毎秒 0.5 秒間ポーリングを行い、時刻を取得する連続した呼び出しの間に 10 マイクロ秒を超えるギャップがあれば、それを報告します。hwlatdetect は、システムで 最大限保証可能な 最大レイテンシーを返します。したがって、10μs 未満の最大レイテンシー値を要求するアプリケーションがある場合、hwlatdetect がギャップの 1 つを 20μs と報告する場合、システムは 20μs のレイテンシーしか保証できません。

ハードウェア遅延検出器 (hwlatdetect) は、トレーサーメカニズムを使用して、ハードウェアアーキテクチャーまたは BIOS/EFI ファームウェアによる遅延を検出します。hwlatdetect によって測定された遅延をチェックすることで、潜在的なハードウェアが RHEL for Real Time カーネルのサポートに適しているかどうかを判断できます。

テスト方法、パラメーター、および結果の表には、hwlatdetect ユーティリティーによって検出されたパラメーターと遅延値が記載されています。

適切なハードウェアとファームウェアの組み合わせを見つけたら、次のステップは、負荷がかかった状態でシステムのリアルタイムパフォーマンスをテストすることです。

rteval ユーティリティーを使用すると、負荷がかかった状態でシステムのリアルタイムパフォーマンスをテストできます。

リアルタイムでは、taskset コマンドは、実行中のプロセスの CPU アフィニティーを設定または取得するのに役立ちます。taskset コマンドは、-p オプションおよび -c オプションを取ります。-p オプションまたは --pid オプションは既存のプロセスを機能させ、新しいタスクを開始しません。-c または --cpu-list は、bitmask の代わりにプロセッサーの数値リストを指定します。リストには、コンマで区切られた複数の項目、およびプロセッサーの範囲を含めることができます。たとえば、0,5,7,9-11 です。

リアルタイム sched_setaffinity() システムコールを使用して、プロセッサーアフィニティーを設定することもできます。

cpusets メカニズムを使用すると、SCHED_DEADLINE タスクに一連の CPU とメモリーノードを割り当てることができます。CPU 使用率の高いタスクと低いタスクが混在するタスクセットにおいて、使用率の高いタスクを実行する CPU を分離し、使用率の低いタスクを異なる CPU セットでスケジューリングすることで、すべてのタスクが与えられた runtime を満たすことが可能になります。

レイテンシーが急増する一般的な原因は、複数の CPU がカーネルタイマーティックハンドラー内の共通のロックで競合することです。競合の原因となるロックは、通常 xtime_lock です。これは時間管理システムと Read-Copy-Update (RCU) 構造のロックによって使用されます。skew_tick=1 を使用すると、CPU ごとのタイマーティックをオフセットして別の時間に開始させ、潜在的なロックの競合を回避できます。

skew_tick カーネルコマンドラインパラメーターは、コア数が多く、レイテンシーの影響を受けやすいワークロードを備えた中規模から大規模のシステムでのレイテンシーの変動を防ぐ可能性があります。

pcscd デーモンは、並列通信 (PC または PCMCIA) およびスマートカード (SC) リーダーへの接続を管理します。通常 pcscd は優先度が低いタスクですが、多くの場合、他のデーモンよりも多くの CPU を使用する場合があります。したがって、背景でさらにノイズが発生することで、リアルタイムのタスクに対してプリエンプションコストが増え、決定論にその他の悪影響を及ぼす可能性があります。

mlock() および mlockall() システムコールは、指定されたメモリー範囲をロックし、このメモリーをページングしません。以下は、mlock() システムコールグループです。

mlock() システムは、addr から始まり、len バイトまで続くアドレス範囲のロックページを呼び出します。呼び出しが正常に戻ると、指定されたアドレス範囲の一部を含むすべてのページは、後でロックが解除されるまでメモリーに残ります。

mlockall() システムコールを使用すると、マップされたすべてのページを指定されたアドレス範囲にロックできます。メモリーロックはスタックしません。いくつかの呼び出しによってロックされたページは、単一の munlock() システム呼び出しで、指定されたアドレス範囲または領域全体のロックを解除します。munlockall() システムコールを使用すると、プログラム空間全体をロック解除できます。

特定の範囲に含まれるページのステータスは、flags 引数の値によって異なります。flags 引数は 0 または MLOCK_ONFAULT です。

メモリーロックは fork によって子プロセスに継承されず、プロセスが終了すると自動的に削除されます。

リアルタイム mlock() システムコールは、addr パラメーターを使用してアドレス範囲の開始を指定し、len を使用してアドレス空間の長さをバイト単位で定義します。この alloc_workbuf() 関数はメモリーバッファーを動的に割り当ててロックします。メモリー割り当ては、posix_memalig() 関数によって行われ、メモリー領域がページに整列されます。free_workbuf() 関数は、メモリー領域のロックを解除します。

mlockall() および munlockall() システムコールを使用してリアルタイムメモリーをロックおよびロック解除するには、flags 引数を 0、もしくは定数 MCL_CURRENT または MCL_FUTURE のいずれかに設定します。MCL_FUTURE を使用すると、ロックされたバイト数が許可された最大数を超えるため、mmap2()、sbrk2()、または malloc3() などの将来のシステムコールが失敗する可能性があります。

リアルタイムシステムで大量のメモリーを割り当てる場合、メモリー割り当て (malloc) メソッドは mmap() システムコールを使用してメモリー空間を見つけます。flags パラメーターに MAP_LOCKED を設定することで、メモリー領域を割り当てて、ロックできます。mmap() はページ単位でメモリーを割り当てるため、同じページで 2 つのロックが行われるのを回避し、二重ロックまたは単一ロック解除の問題を防ぎます。

mlock パラメーターの表で、メモリーロックシステムコールのパラメーターとそれらが実行する機能を一覧にして説明します。

atime 属性を無効にすると、ファイルシステムジャーナルへの書き込み回数が制限されるため、パフォーマンスが向上し、電力使用量が減少します。

デフォルトのカーネルコンソールである teletype (tty) は、入力データをシステムに渡してグラフィックコンソールに出力情報を表示することで、システムとの対話を可能にします。

グラフィックコンソールを設定しないと、グラフィックアダプターにログの記録ができなくなります。これにより、tty0 はシステムで利用できず、グラフィックコンソールでのメッセージの出力を無効にするのに役立ちます。

必要なログレベルを /proc/sys/kernel/printk ファイルに設定すると、グラフィックコンソールに送信される出力メッセージの量を制御できます。

Non-Uniform Memory Access (NUMA) や Symmetric multiprocessing (SMP) などのマルチプロセッサーシステムに見られるクロックソースの複数のインスタンスは、それらの間で相互作用し、CPU 周波数スケーリングまたはエネルギーエコノミーモードへの移行などのシステムイベントへの反応により、それらがリアルタイムカーネルに適したクロックソースであるかどうかを判断します。

推奨されるクロックソースは Time Stamp Counter (TSC) です。TSC が利用できない場合は、High Precision Event Timer (HPET) が 2 番目に最適なオプションとなります。ただし、すべてのシステムに HPET クロックがあるわけではなく、一部の HPET クロックは信頼できない可能性があります。

TSC および HPET がない場合のオプションとして、ACPI Power Management Timer (ACPI_PM)、Programmable Interval Timer (PIT)、Real Time Clock (RTC) などがあります。最後の 2 つのオプションは、読み取るのにコストがかかるか、分解能 (時間粒度) が低いかのどちらかであるため、リアルタイムカーネルでの使用は準最適となります。

システムで利用可能なクロックソースのリストは、/sys/devices/system/clocksource/clocksource0/available_clocksource ファイルにあります。

システムで現在使用されているクロックソースは、/sys/devices/system/clocksource/clocksource0/current_clocksource ファイルに保存されています。

クロックの既知の問題により、システムのメインアプリケーションに最適なクロックが使用されないことがあります。問題のあるすべてのクロックを除外した後、システムに残ったハードウェアクロックが、リアルタイムシステムの最低要件を満たせないことがあります。

重要なアプリケーションの要件は、システムごとに異なります。そのため、各アプリケーション、したがって各システムに適したクロックも異なります。一部のアプリケーションはクロックの分解能に依存し、信頼できるナノ秒の読み取りを提供するクロックの方が適しています。また、クロックを読み取るアプリケーションは、読み取りコスト (読み取り要求と結果の間隔) の小さいクロックからメリットを得ることができます。

これらのケースでは、カーネルが選択したクロックをオーバーライドできます。ただし、このオーバーライドの副次的な影響を理解し、そのハードウェアクロックの既知の欠点をトリガーしない環境を作成できる場合に限ります。

システムのクロックの速度を比較できます。TSC からの読み取りは、プロセッサーからレジスターを読み取ることを意味します。HPET クロックからの読み取りには、メモリーエリアを読み取る必要があります。TSC からの読み取りがより高速です。毎秒大量のメッセージのタイムスタンプ処理を行う場合、パフォーマンスが大幅に向上します。

AMD64 Opteron プロセッサーの現行世代は、大きな gettimeofday スキューの影響を受けやすい可能性があります。このスキューは、cpufreq および Time Stamp Counter (TSC) の両方が使用されている場合に発生します。RHEL for Real Time は、すべてのプロセッサーが同じ頻度に同時に変更することで、このスキューを防ぐ方法を提供します。そのため、1 つのプロセッサーの TSC は、別のプロセッサーの TSC とは異なる速度で増加することはありません。

clock_timing プログラムは、現在のクロックソースを 1,000 万回読み取ります。time ユーティリティーと共に、これを行うために必要な時間を測定します。

最新のプロセッサーは、低い省電力状態から高い省電力状態 (C-state) にアクティブに移行します。ただし、高い省電力状態から稼働状態に戻ると、リアルタイムアプリケーションの理想よりも多くの時間を消費してしまいます。アプリケーションは Power Management Quality of Service (PM QoS) インターフェイスを使用して、これらの移行を防ぐことができます。

PM QoS インターフェイスを使用すると、システムは idle=poll および processor.max_cstate=1 パラメーターの動作をエミュレートできますが、省電力の状態をより詳細に制御できます。idle=poll は、プロセッサーが idle 状態になることを防ぎます。processor.max_cstate=1 は、プロセッサーがより深い C-state (省電力モード) に入ることを阻止します。

アプリケーションが /dev/cpu_dma_latency ファイルを開いたままにすると、PM QoS インターフェイスはプロセッサーが深いスリープ状態に入ることを阻止します。これにより、終了する際に予期せぬレイテンシーが発生します。ファイルが閉じられると、システムは省電力状態に戻ります。

次のいずれかの方法で電源管理の状態を設定することで、電源管理の移行を制御できます。

割り込み (IRQ) をさまざまな専用 CPU 上のユーザープロセスから分離することで、リアルタイム環境でのレイテンシーを最小限に抑えるか、なくすことができます。

通常、割り込みは CPU 間で均等に共有されます。これにより、CPU が新しいデータおよび命令キャッシュを書き込む必要があるときに、割り込み処理が遅延する場合があります。これらの割り込みの遅延は、同じ CPU で実行されている他の処理との競合を引き起こす可能性があります。

タイムクリティカルな割り込みおよびプロセスを特定の CPU (または CPU の範囲) に割り当てることができます。これにより、この割り込みを処理するコードおよびデータ構造がプロセッサーおよび命令キャッシュにある可能性が非常に高くなります。その結果、専用のプロセスはできるだけ迅速に実行でき、他のすべてのタイムクリティカルでないプロセスは他の CPU で実行されます。これは、関連する速度がメモリーおよび使用可能なペリフェラルバス帯域幅の限界に近いか限界に達している場合に、特に重要になる可能性があります。メモリーがプロセッサーキャッシュにフェッチされるのを待つと、全体的な処理時間と決定論は著しく影響を受けます。

実際には、最適なパフォーマンスはアプリケーションによってまったく異なります。たとえば、同様の機能を持つアプリケーションを異なる企業向けにチューニングする場合、全く異なる最適なパフォーマンスチューニングが必要になります。

irqbalance デーモンはデフォルトで有効になっており、複数の CPU に対して定期的に割り込みの均等な処理を強制します。ただし、リアルタイムのデプロイメントでは、アプリケーションは通常特定の CPU にバインドされているため、irqbalance は必要ありません。

IRQ バランシングサービスを使用して、割り込み (IRQ) バランシングを考慮する際に除外する CPU を指定できます。/etc/sysconfig/irqbalance 設定ファイルの IRQBALANCE_BANNED_CPUS パラメーターは、この設定を制御します。パラメーターの値は 64 ビットの 16 進数ビットマスクで、マスクの各ビットは CPU コアを表します。

CPU アフィニティーを割り当てると、指定した CPU または CPU の範囲にプロセスとスレッドをバインドおよびバインド解除できます。これにより、キャッシュの問題を減らすことができます。

taskset ユーティリティーは、タスクのプロセス ID (PID) を使用して、その CPU アフィニティーを表示または設定します。このユーティリティーを使用して、選択した CPU アフィニティーでコマンドを実行できます。

アフィニティーを設定するには、CPU マスクを 10 進数または 16 進数にする必要があります。mask 引数は、変更されるコマンドまたは PID に対して有効な CPU コアを指定する bitmask です。

/proc/sys/vm/panic_on_oom ファイルには、Out of Memory (OOM) の動作を制御するスイッチである値が含まれます。ファイルに 1 が含まれる場合、カーネルは OOM でパニックになり、期待どおりに機能しなくなります。

デフォルト値は 0 で、システムが OOM 状態の場合に oom_killer() 関数を呼び出すようカーネルに指示します。通常、oom_killer() は不要なプロセスを終了します。これにより、システムの存続が可能になります。

/proc/sys/vm/panic_on_oom の値を変更できます。

oom_killer() 関数で終了するプロセスに優先順位を付けることができます。これにより、優先順位の高いプロセスが OOM 状態の間も実行され続けることが保証されます。各プロセスには /proc/PID ディレクトリーがあります。各ディレクトリーには、以下のファイルが含まれます。

メモリー不足の状態では、oom_killer() 関数は oom_score が最も高いプロセスを終了します。

プロセスの oom_adj ファイルを編集して、終了するプロセスに優先順位を付けることができます。

プロセスの oom_killer() 関数を無効にするには、oom_adj を -17 の予約値に設定します。これにより、OOM 状態でもプロセスが存続します。

tuna コマンドラインインターフェイス (CLI) は、システムのチューニング変更を行うためのツールです。

tuna ツールは実行中のシステムで使用するように設計されており、変更がすぐに反映されます。これにより、アプリケーション固有の測定ツールは、変更が加えられた直後にシステムパフォーマンスを確認および分析できます。

tuna CLI には、アクションオプションと修飾子オプションの両方があります。修飾子オプションは、変更するアクションの前にコマンドラインで指定する必要があります。すべての修飾子オプションは、修飾子オプションがオーバーライドされるまで続くアクションに適用されます。

tuna CLI を使用して、割り込み (IRQ) をさまざまな専用 CPU 上のユーザープロセスから分離し、リアルタイム環境でのレイテンシーを最小限に抑えることができます。CPU の分離に関する詳細は、割り込みおよびプロセスバインディング を参照してください。

tuna CLI を使用して、割り込み (IRQ) を専用の CPU に移動し、リアルタイム環境でのレイテンシーを最小限に抑えるか、なくすことができます。IRQ の移動に関する詳細は、割り込みおよびプロセスバインディング を参照してください。

tuna CLI を使用して、プロセススケジューリングポリシーおよび優先順位を変更できます。

# *tuna --threads=rngd --show_threads*
                      thread       ctxt_switches
    pid SCHED_ rtpri affinity voluntary nonvoluntary           cmd
  3571   FIFO     1  0,1,2,3    167697          134            rngd

スレッドの優先度は、0 (最低優先度) から 99 (最高優先度) まで、一連のレベルを使用して設定されます。systemd サービスマネージャーは、カーネルの起動後に、スレッドのデフォルトの優先度を変更するのに使用できます。

systemd を使用すると、システムの起動時に起動するサービスのリアルタイムの優先度を設定できます。

ユニット設定ディレクティブを使用して、起動プロセス時のサービスの優先度を変更します。ブートプロセスの優先度の変更は、/etc/systemd/system/ service .service.d/priority.conf のservice セクションにある以下のディレクティブを使用して行います。

systemd を使用して、サービスを実行できる CPU を指定できます。

スケジューラーの優先順位はグループで定義され、一部のグループは特定のカーネル機能の専用となります。

スループットが最優先である大容量のデータを転送するシステムでは、結合のデフォルト値を使用するか値を増やすと、スループットを高め、CPU にアクセスする割り込みの数を減らすことができます。高速なネットワーク応答が必要なシステムでは、結合の値 を減らすか、無効にすることが推奨されます。

割り込みの数を減らすには、パケットを収集します。パケットの集合に対して、1 回の割り込みが生成されます。

# ethtool -c tun0
Coalesce parameters for tun0:
Adaptive RX: n/a  TX: n/a
stats-block-usecs: n/a
sample-interval: n/a
pkt-rate-low: n/a
pkt-rate-high: n/a

rx-usecs: n/a
rx-frames: 0
rx-usecs-irq: n/a
rx-frames-irq: n/a

tx-usecs: n/a
tx-frames: n/a
tx-usecs-irq: n/a
tx-frames-irq: n/a

rx-usecs-low: n/a
rx-frame-low: n/a
tx-usecs-low: n/a
tx-frame-low: n/a

rx-usecs-high: n/a
rx-frame-high: n/a
tx-usecs-high: n/a
tx-frame-high: n/a

CQE mode RX: n/a  TX: n/a

多くの場合、I/O スイッチは、フルバッファーの結果としてネットワークデータが山積みになるバックプレッシャーの状態になることがあります。pause パラメーターを変更して、ネットワークの輻輳を回避できます。

# ethtool -a enp0s31f6
Pause parameters for enp0s31f6:
Autonegotiate:	on
RX:		on
TX:		on

netstat は、ネットワークトラフィックの監視に使用できます。

$ netstat -s
Ip:
    Forwarding: 1
    30817508 total packets received
    2927 forwarded
    0 incoming packets discarded
    30813320 incoming packets delivered
    19184491 requests sent out
    181 outgoing packets dropped
    2628 dropped because of missing route
Icmp
    29450 ICMP messages received
    213 input ICMP message failed
    ICMP input histogram:
        destination unreachable: 29431
        echo requests: 19
    10141 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 10122
        echo replies: 19
IcmpMsg:
        InType3: 29431
        InType8: 19
        OutType0: 19
        OutType3: 10122
Tcp:
    162638 active connection openings
    89 passive connection openings
    38908 failed connection attempts
    17869 connection resets received
    48 connections established
    8456952 segments received
    9323882 segments sent out
    69885 segments retransmitted
    1143 bad segments received
    56209 resets sent
Udp:
    21929780 packets received
    1319 packets to unknown port received
    712919 packet receive errors
    10134989 packets sent
    712919 receive buffer errors
    180 send buffer errors
    IgnoredMulti: 39231

trace-cmd ユーティリティーは、ftrace ユーティリティーのフロントエンドを提供します。

trace-cmd ユーティリティーを使用して、すべての ftrace 機能にアクセスできます。

以下のコマンド例で、trace-cmd ユーティリティーを使用してカーネル機能をトレースする方法を示します。

分離する CPU を選択する際は、システムの CPU トポロジーを慎重に考慮する必要があります。ユースケースごとに異なる設定が必要です。

hwloc パッケージは、lstopo-no-graphics および numactl などの CPU に関する情報を取得する際に便利なユーティリティーを提供します。

CPU を分離する最初のメカニズムは、カーネルブートコマンドラインでブートパラメーターの isolcpus=cpulist を指定することです。RHEL for Real Time での推奨の方法は、TuneD デーモンとその tuned-profiles-realtime を使用することです。

nohz パラメーターおよび nohz_full パラメーターは、指定された CPU の動作を変更します。このようなカーネルブートパラメーターを有効にするには、realtime-virtual-host、realtime-virtual-guest、または cpu-partitioning のいずれかのプロファイルをチューニングする必要があります。

SCHED_OTHER タスクが他の多数のタスクを生成する場合、それらはすべて同じ CPU 上で実行されます。migration タスクまたは softirq は、アイドル状態の CPU で実行できるように、これらのタスクのバランスをとろうとします。

sched_nr_migrate は、一度に移動するタスクの数を指定するように調整できます。リアルタイムタスクの移行方法は異なるため、この影響を直接受けることはありません。ただし、softirq がタスクを移動すると、実行キューのスピンロックが有効になり、割り込みが無効になります。

移行が必要なタスクが多数存在すると、そのタスクは割り込みが無効になっている間に発生するため、タイマーイベントやウェイクアップは同時には行われません。これにより、sched_nr_migrate を大きい値に設定した場合に、リアルタイムタスクで深刻なレイテンシーが発生する可能性があります。

sched_nr_migrate 変数の値を大きくすると、リアルタイムレイテンシーを犠牲にして、多くのタスクを起動する SCHED_OTHER スレッドから高パフォーマンスが得られます。

SCHED_OTHER タスクのパフォーマンスを犠牲にしてリアルタイムのタスクレイテンシーを低くするには、値を小さくする必要があります。デフォルト値は 8 です。

TCP タイムスタンプを無効にすると、TCP パフォーマンスの急激な変化を低減できます。

タイムスタンプを生成すると、TCP パフォーマンスのスパイクが発生する可能性があります。TCP タイムスタンプを無効にすることで、TCP パフォーマンスのスパイクを低減できます。TCP タイムスタンプを生成しても TCP パフォーマンスのスパイクが発生しない場合は、タイムスタンプを有効にできます。

TCP タイムスタンプの生成ステータスを表示できます。

rcu_nocbs および rcu_nocb_poll カーネルパラメーターを使用して、RCU コールバックをオフロードできます。

ハウスキーピング CPU を割り当てて、すべての RCU コールバックスレッドを処理できます。これには、tuna コマンドを使用して、すべての RCU コールバックをハウスキーピング CPU に移動します。

このアクションにより、CPU X 以外のすべての CPU が RCU コールバックスレッドを処理しなくなります。

RCU オフロードスレッドは別の CPU の RCU コールバックを実行できますが、各 CPU は対応する RCU オフロードスレッド起動を処理する必要があります。この処理を CPU で行わないようにすることができます。

ftrace ユーティリティーを使用して、レイテンシーを追跡できます。

/sys/kernel/debug/tracing/ ディレクトリーの主なファイルを以下に示します。

カーネルの設定方法によっては、指定のカーネルですべてのトレーサーが利用できるとは限りません。RHEL for Real Time カーネルの場合、トレースカーネルおよびデバッグカーネルには、実稼働カーネルとは異なるトレーサーがあります。これは、トレーサーの一部にトレーサーがカーネルに設定され、アクティブではない場合に大きなオーバーヘッドが発生するためです。このトレーサーは、trace および debug カーネルに対してのみ有効になります。

以下では、トレースする関数のフィルター処理を変更する例を多数説明します。単語の先頭と末尾の両方に * ワイルドカードを使用できます。たとえば、*irq\* は、名前に irq を含むすべての関数を選択します。ただし、ワイルドカードは単語内で使用できません。

検索用語とワイルドカード文字を二重引用符で囲むと、シェルが検索を現在の作業ディレクトリーに拡張しないようにします。

POSIX は、タイムソースを実装して表すための標準です。システム内のその他のアプリケーションに影響を及ぼさずに、POSIX クロックをアプリケーションに割り当てることができます。これは、カーネルによって選択され、システム全体に実装されるハードウェアクロックとは対照的です。

指定の POSIX クロックを読み取るために使用される関数は <time.h> で定義される clock_gettime() です。clock_gettime() に相当するカーネルはシステムコールです。ユーザープロセスが clock_gettime() を呼び出すと、以下が行われます。

ただし、このコンテキストはユーザーアプリケーションからカーネルへの切り替えには CPU コストがかかります。このコストは非常に低くなりますが、操作が数千回繰り返し行われると、累積されたコストはアプリケーション全体のパフォーマンスに影響を及ぼす可能性があります。カーネルへのコンテキストの切り替えを回避し、クロックの読み出しを速くするために、VDSO (Virtual Dynamic Shared Object) ライブラリー機能の形式で CLOCK_MONOTONIC_COARSE クロックおよび CLOCK_REALTIME_COARSE POSIX クロックのサポートが追加されました。

_COARSE クロックバリアントのいずれかを使用して clock_gettime() が実行する時間測定は、カーネルの介入を必要とせず、ユーザー空間全体で実行されます。これにより、パフォーマンスが大幅に向上します。_COARSE クロックの時間読み取りの分解能はミリ秒 (ms) です。つまり、1ms 未満の時間間隔は記録されません。POSIX クロックの _COARSE バリアントは、ミリ秒のクロック分解能に対応できるアプリケーションに適しています。

このコード出力例は、CLOCK_MONOTONIC_COARSE POSIX クロックで clock_gettime 関数を使用することを示しています。

#include <time.h>

main()
{
	int rc;
	long i;
	struct timespec ts;

	for(i=0; i<10000000; i++) {
		rc = clock_gettime(CLOCK_MONOTONIC_COARSE, &ts);
	}
}

上記の例を改善するには、より多くの文字列を使用して clock_gettime() の戻りコードを確認したり、rc 変数の値を確認したり、ts 構造のコンテンツが信頼できるようにしたりします。

送信されるすべてのパケットでレイテンシーを低く保つ必要のあるアプリケーションは、TCP_NODELAY オプションを有効化しているソケットで実行する必要があります。イベントが発生するとすぐに、カーネルにバッファー書き込みを送信します。

論理に関連し、1 つのパケットとして送信する必要があるバッファーがアプリケーションに複数ある場合は、パフォーマンスの低下を回避するために、以下の回避策のいずれかを適用します。

アプリケーションのさまざまなコンポーネントにより、論理パケットがカーネルに構築されている場合は、ソケットのコルクを解除する必要があります。これにより、TCP が、累積した論理パケットをすぐに送信できるようになります。

イベントが発生すると、TCP_NODELAY オプションは遅滞なくバッファー書き込みをカーネルに送信します。setsockopt() 関数を使用して TCP_NODELAY を有効にします。

TCP_CORK オプションは、ソケットが "uncorked" になるまで TCP がパケットを送信しないようにします。

相互除外 (ミューテックス) アルゴリズムは、プロセスが共通のリソースを同時に使用するのを防ぐために使用されます。高速ユーザー空間ミューテックス (futex) は、ミューテックスが別のスレッドによって保持されていない場合に、カーネル領域にコンテキストスイッチを要求せずにユーザー空間スレッドがミューテックスを要求することを可能にするツールです。

標準属性で pthread_mutex_t オブジェクトを初期化すると、プライベートで再帰的ではなく、堅牢ではない優先度継承対応ではないミューテックスが作成されます。このオブジェクトには、pthreads API および RHEL for Real Time カーネルで提供される利点はありません。

pthreads API および RHEL for Real Time カーネルの利点を活用するには、pthread_mutexattr_t オブジェクトを作成します。このオブジェクトは、futex に定義した属性を保存します。

mutex に追加の機能を定義するには、pthread_mutexattr_t オブジェクトを作成します。このオブジェクトは、futex に定義した属性を保存します。これは基本的な安全手順で、常に実行する必要があります。

拡張ミューテックス属性の詳細は、拡張ミューテックス属性 を参照してください。

標準属性で pthread_mutex_t オブジェクトを初期化すると、プライベートで再帰的ではなく、堅牢ではない優先度継承対応ではないミューテックスが作成されます。

以下の拡張ミューテックス属性は、ミューテックス属性オブジェクトに格納できます。

ミューテックス属性オブジェクトを使用してミューテックスを作成した後に、属性オブジェクトを保持して同じタイプのミューテックスをさらに初期化することや、削除することができます。ミューテックスはいずれの場合も影響を受けません。

perf record コマンドは、システム全体の統計を収集するために使用されます。すべてのプロセッサーで使用できます。

perf archive を使用すると、他のシステムでの perf の結果を分析できます。以下の場合は必要ありません。

perf record 機能によるデータを、perf report コマンドを使用して直接調査できるようになりました。

ハードウェアトレースポイントアクティビティーを取得するために利用可能なオプションは複数あります。

perf stat を使用すると、特定のイベントを表示できます。

浮動小数点ユニットは、浮動小数点算術演算を実行するプロセッサーの機能部分です。浮動小数点ユニットは算術演算を処理し、浮動小数点数または小数の計算を簡単にします。

--matrix-method オプションを使用すると、CPU 浮動小数点演算とプロセッサーデータキャッシュのストレステストを行うことができます。

stress-ng ツールは、複数のストレステストを実行します。デフォルトモードでは、指定されたストレッサーメカニズムを並行して実行します。

CPU の発熱量を測定するために、指定されたストレッサーが短時間高温を発生させ、最大発熱量でのシステムの冷却の信頼性と安定性をテストします。--matrix-size オプションを使用すると、短時間で CPU 温度を摂氏単位で測定できます。

stress-ng ツールは、1 秒あたりの bogo 操作を測定することにより、ストレステストのスループットを測定できます。bogo 操作のサイズは、実行されているストレッサーによって異なります。テスト結果は正確ではありませんが、概略のパフォーマンスを提供します。

この測定値を正確なベンチマークメトリックとして使用しないでください。これらの見積もりは、stress-ng のビルドに使用されるさまざまなカーネルバージョンまたはさまざまなコンパイラーバージョンでのシステムパフォーマンスの変化を理解するのに役立ちます。--metrics-brief オプションを使用して、マシンで利用可能な bogo 操作の合計とマトリックスストレッサーのパフォーマンスを表示します。

メモリーが不足すると、カーネルはページをスワップに書き込み始めます。--page-in オプションを使用して、非常駐ページを強制的に仮想メモリーにスワップバックすることにより、仮想メモリーに負荷をかけることができます。これにより、仮想マシンが高負荷で実行されます。--page-in オプションを使用すると、bigheap、mmap、および仮想マシン (vm) ストレッサーに対してこのモードを有効にできます。--page-in オプションは、コアにない割り当てられたページをタッチして、強制的にページインさせます。

タイマーを高頻度で実行すると、大きな割り込み負荷が発生する可能性があります。適切に選択されたタイマー周波数を持つ –timer ストレッサーは、1 秒あたり多くの割り込みを強制する可能性があります。

stress-ng を使用すると、メモリーに読み込まれていないページで深刻なページ障害を生成することにより、ページ障害率をテストおよび分析できます。新しいカーネルバージョンでは、userfaultfd メカニズムは、プロセスの仮想メモリーレイアウトのページ障害について、障害検出スレッドに通知します。

CPU ストレステストには、CPU を使用するメソッドが含まれています。which オプションを使用して出力を印刷し、すべてのメソッドを表示できます。

テスト方法を指定しない場合、デフォルトでは、ストレッサーはすべてのストレッサーをラウンドロビン方式でチェックして、各ストレッサーで CPU をテストします。

verify モードは、テストがアクティブなときに結果を検証します。テスト実行からメモリーの内容の健全性チェックを行い、予期しない障害があれば報告します。

すべてのストレッサーには verify モードがなく、このモードを有効にすると、このモードで実行される追加の検証ステップのために、bogo 操作の統計が減少します。

以下のオプションはすべて、リアルタイムカーネルとメインの RHEL カーネルの両方で使用できます。kernel-rt パッケージにより潜在的な決定論が改善され、通常のトラブルシューティングが可能となります。

Dockerfile でビルドしたコンテナーを実行できます。

この例は、必須のリアルタイム固有のオプションを指定した podman run コマンドを示しています。以下に例を示します。

chrt ユーティリティーは、スケジューラーポリシーおよび優先度を確認して調整します。希望するプロパティーで新しいプロセスを開始するか、実行中のプロセスのプロパティーを変更できます。

指定したプロセスの現在のスケジューリングポリシーおよびスケジューリング優先度を表示できます。

リアルタイムプロセスでは、一連の関数を使用してポリシーと優先順位を制御します。sched_getscheduler() 関数を使用して、指定したプロセスのスケジューラーポリシーを表示できます。

sched_get_priority_min() 関数および sched_get_priority_max() 関数を使用して、特定のスケジューラーポリシーの有効な優先順位の範囲を確認できます。

これで sched_get プログラムの準備が整い、保存先のディレクトリーから実行できるようになりました。

SCHED_RR (ラウンドロビン) ポリシーは、SCHED_FIFO (先入れ先出し) ポリシーとは少し異なります。SCHED_RR は、ラウンドロビンローテーションで同じ優先度を持つ並行プロセスを割り当てます。このようにして、各プロセスにタイムスライスが割り当てられます。sched_rr_get_interval() 関数は、各プロセスに割り当てられたタイムスライスを報告します。

タイムスライス情報は timespec として返されます。これは、1970 年 1 月 1 日のグリニッジ標準時 00:00:00 の基準時間からの秒数およびナノ秒数です。

struct timespec {
  time_t tv_sec;  /* seconds / long tv_nsec; / nanoseconds */
};

sched_getattr() 関数は、PID で識別される、指定されたプロセスに現在適用されているスケジューリングポリシーを照会します。PID がゼロに等しい場合は、呼び出しプロセスのポリシーが取得されます。

size 引数は、ユーザースペースに認識されている sched_attr 構造体のサイズを反映する必要があります。カーネルは、sched_attr::size をその sched_attr 構造体のサイズに入力します。

入力構造体が小さい場合、カーネルは指定されたスペースの外側の値を返します。その結果、システムコールが E2BIG エラーで失敗します。他の sched_attr フィールドは、The sched_attr structure で説明されているように入力されます。

sched_attr 構造体には、指定されたスレッドのスケジューリングポリシーとそれに関連する属性が含まれるか、それらを定義します。sched_attr 構造体の形式は次のとおりです。

    struct sched_attr {
     u32 size;
     u32 sched_policy
     u64 sched_flags
     s32 sched_nice
     u32 sched_priority

     /* SCHED_DEADLINE fields */
               u64 sched_runtime
               u64 sched_deadline
               u64 sched_period
           };

SCHED_DEADLINE フィールドは、期限スケジューリングの場合にのみ指定する必要があります。

プロセスは、完了したか、イベント (ディスクからのデータ、キー操作、またはネットワークパケットなど) を待機しているため、CPU に 自主的に優先度を譲ることがあります。

また、プロセスは不本意に CPU に優先度を譲ることもあります。これはプリエンプションと呼ばれ、優先度の高いプロセスが CPU を使用する場合に発生します。

プリエンプションはシステムパフォーマンスに重大な影響を及ぼす可能性があります。また、継続的なプリエンプションにより、スロットリングと呼ばれる状態が発生する可能性があります。この問題は、プロセスが常にプリエンプションされ、プロセスの実行が完了しない場合に発生します。

タスクの優先度を変更すると、自発的なプリエンプションを減らすことができます。

指定されたプロセスの自発的および非自発的なプリエンプションステータスを確認できます。ステータスは /proc/PID/status に保存されます。

chrt ユーティリティーは、スケジューラーポリシーおよび優先度を確認して調整します。希望するプロパティーで新しいプロセスを開始するか、実行中のプロセスのプロパティーを変更できます。

chrt ユーティリティーのオプションには、コマンドオプションと、コマンドのプロセスと優先度を指定するパラメーターが含まれます。

リアルタイムプロセスは、異なる一連のライブラリー呼び出しを使用して、ポリシーおよび優先度を制御します。次のライブラリー呼び出しは、非リアルタイムプロセスの優先度を設定するのに使用されます。

これらの関数は、非リアルタイムプロセスの nice 値を調整します。nice 値は、プロセッサー上で実行可能な非リアルタイムプロセスのリストにどのように優先度を設定するかをスケジューラーに提案します。リストの上位にあるプロセスは、リスト上で下位のプロセスより先に実行されます。

スケジューラーポリシーおよびその他のパラメーターは、sched_setscheduler() 関数を使用して設定できます。現在、リアルタイムポリシーには、sched_priority というパラメーターがあります。このパラメーターは、プロセスの優先度を調整するために使用されます。

sched_setscheduler() 関数には、sched_setscheduler(pid_t pid, int policy, const struct sched_param *sp); 形式の 3 つのパラメーターが必要です。

プロセス ID がゼロの場合、sched_setscheduler() 関数は呼び出し元のプロセスに作用します。

次のコードの抜粋は、現在のプロセスのスケジューラーポリシーを SCHED_FIFO スケジューラーポリシーに設定し、優先度を 50 に設定します。

struct sched_param sp = { .sched_priority = 50 };
int ret;

ret = sched_setscheduler(0, SCHED_FIFO, &sp);
if (ret == -1) {
  perror("sched_setscheduler");
  return 1;
}

sched_setparam() 関数は、特定プロセスのスケジューリングパラメーターを設定するために使用されます。その後、sched_getparam() 関数を使用して確認できます。

スケジューリングポリシーのみを返す sched_getscheduler() 関数とは異なり、sched_getparam() 関数は指定のプロセスのすべてのスケジューリングパラメーターを返します。

struct sched_param sp;
int ret;

ret = sched_getparam(0, &sp);
sp.sched_priority += 2;
ret = sched_setparam(0, &sp);

このコードを実際のアプリケーションで使用する場合は、関数からの戻り値を確認し、エラーを適切に処理する必要があります。

sched_setattr() 関数は、PID で指定されたインスタンス ID のスケジューリングポリシーとそれに関連する属性を設定します。pid=0 の場合、sched_setattr() は呼び出し元のスレッドのプロセスおよび属性に作用します。

リアルタイムスケジューリングポリシーには、共通した大きな特徴が 1 つあります。それは、より優先度の高いスレッドがスレッドに割り込むか、スレッドがスリープまたは I/O の実行によって待機状態になるまで、リアルタイムスケジューリングポリシーは実行を続けるという点です。

SCHED_RR の場合、オペレーティングシステムは、実行中のスレッドに割り込み、同じ SCHED_RR 優先度を持つ別のスレッドを実行可能にします。このようないずれの場合も、優先度の低いスレッドが CPU 時間を取得できるようにするポリシーを定義する POSIX 仕様によりプロビジョニングが行われることはありません。リアルタイムスレッドのこの特性は、特定の CPU の 100% を独占するアプリケーションの作成が非常に簡単であることを意味します。ただし、これにより、オペレーティングシステムに問題が発生します。たとえば、オペレーティングシステムは、システム全体のリソースと CPU ごとのリソースの両方を管理し、これらのリソースを記述するデータ構造を定期的に調べて、それらのハウスキーピングアクティビティーを実行する必要があります。しかし、コアが SCHED_FIFO スレッドによって独占されていると、そのコアはハウスキーピングタスクを実行できません。最終的にシステム全体が不安定になり、クラッシュする可能性があります。

RHEL for Real Time カーネルでは、割り込みハンドラーは優先度が SCHED_FIFO のスレッドとして実行されます。デフォルトの優先度は 50 です。割り込みハンドラースレッドよりも高い SCHED_FIFO ポリシーまたは SCHED_RR ポリシーが割り当てられた cpu-hog スレッドでは、割り込みハンドラーの実行を防ぐことができます。これにより、これらの割り込みによるシグナルのデータを待機しているプログラムが枯渇し、エラーが発生します。

リアルタイムカーネルには、リアルタイムタスクで使用する帯域幅の割り当てを可能にする保護メカニズムが搭載されています。この保護メカニズムは、リアルタイムスケジューラーのスロットルと呼ばれています。

リアルタイムスロットリングメカニズムのデフォルト値は、リアルタイムタスクで CPU 時間の 95% を使用できるように定義します。残りの 5% はリアルタイム以外のタスク (SCHED_OTHER および同様のスケジューリングポリシーで実行されるタスク) に割り当てられます。1 つのリアルタイムタスクが CPU タイムスロットの 95% を占有している場合、その CPU 上の残りのリアルタイムタスクは実行されないことに注意してください。残りの 5% の CPU 時間は、リアルタイム以外のタスクでのみ使用されます。デフォルト値は、次のようなパフォーマンスの影響を与える可能性があります。

リアルタイムスケジューラーのスロットリングは、/proc ファイルシステム内の次のパラメーターによって制御されます。

スレッドスタベーションは、スレッドがスタベーションしきい値よりも長く CPU 実行キューにあり、進行しない場合に発生します。スレッドスターベーションの一般的な原因は、CPU にバインドされた SCHED_FIFO や SCHED_RR など、固定優先度のポーリングアプリケーションを実行することです。ポーリングアプリケーションは I/O をブロックしないため、kworkers などの他のスレッドがその CPU で実行されなくなる可能性があります。

スレッドスタベーションを減らすための初期の試みは、リアルタイムスロットリングと呼ばれます。リアルタイムスロットリングでは、各 CPU に非リアルタイムタスク専用の実行時間の一部があります。スロットリングのデフォルト設定はオンであり、CPU の 95% がリアルタイムタスク用に割り当てられ、5% がリアルタイム以外のタスク用に予約されます。これは、1 つのリアルタイムタスクが原因でスタベーションが発生している場合には機能しますが、CPU に複数のリアルタイムタスクが割り当てられている場合には機能しません。以下を使用して問題を回避できます。