第1章 Red Hat Enterprise Linux for Real Time システムのチューニングを開始する前に
Red Hat Enterprise Linux for Real Time は、非常に高い決定論要件を持つアプリケーション向けに、適切にチューニングされたシステムでの使用を目的としています。カーネルシステムのチューニングにより、決定論の改善が大きくなります。たとえば、多くのワークロードでシステム全体のチューニングにより、約 90 % 程度で結果の一貫性が向上します。これは、Red Hat Enterprise Linux for Real Time を使用する前に、お客様が最初に標準の Red Hat Enterprise Linux の 2章一般的なシステムチューニング を実行することが推奨されます。
Red Hat Enterprise Linux for Real Time カーネルの調整を行うに当たり重要なこと
- お待ちください。リアルタイムチューニングは反復的なプロセスで、いくつかの変数を微調整することはあまりできず、変更が最適であることに気がつくことはありません。システムに最適なチューニングセットを絞り込むためには、数日または数週間かかると思ってください。また、常に長いテストを実行します。チューニングパラメーターの一部を変更してから 5 分のテストの実行は、チューニングのセットの検証に適していません。テストの長さを調整可能にし、数分以上実行してください。テストが数時間実行した複数の異なるチューニングセットに絞り込みを試み、一度に数時間または数日間これらのセットを実行して、最大レイテンシーまたはリソース消費の隅をキャッチします。
- 正確にお願いします。アプリケーションに測定メカニズムを構築し、特定のチューニング変更がどのようにアプリケーションのパフォーマンスに与える影響を正確に測定できるようにします。「マウスの方がスムーズに移動する」という内容は正しくないことがほとんどで、人によって異なります。ハード測定を行い、後で分析するためにそれらを記録します。
- 順序だった手順を心がけるテストの実行間で変数のチューニングに複数の変更を加えがちです。ただし、これを実行することは、テスト結果に影響を及ぼすチューニングを絞り込むことができないことを意味します。テスト間のチューニング変更は、可能な限り小さく実行されるようにします。
- 保守的にまた、チューニング時に大きな変更を行うことを希望していますが、ほとんどの場合、増分変更を行う方が適切です。優先度の値が最小値から最大値に達すると、長期的に考えて結果がよくなることがわかります。
- 賢く利用可能なツールを使用します。Tuna グラフィカルチューニングツールを使用すると、スレッドと割り込み、スレッドの優先度、アプリケーションが使用するプロセッサーを分離できるプロセッサーを簡単に変更できます。
taskset
およびchrt
コマンドラインユーティリティーを使用すると、Tuna の機能のほとんどを行えます。パフォーマンスの問題が発生した場合、ftrace
およびperf
ユーティリティーはレイテンシーの問題の特定に役立ちます。 - 柔軟性にアプリケーションで値をハードコーディングするのではなく、外部ツールを使用してポリシー、優先度、アフィニティーを変更します。これにより、さまざまな組み合わせを試し、論理を簡素化できます。適切な結果を提供する設定が見つかったら、アプリケーションをアプリケーションに追加したり、アプリケーションの起動時に設定を実装する起動ロジックを設定できます。
スケジューリングポリシー
Linux では、以下の 3 つの主要なスケジューリングポリシーが使用されます。
SCHED_OTHER
(時折SCHED_NORMAL
と呼ばれる)- これはデフォルトのスレッドポリシーで、カーネルが制御する動的な優先度を持ちます。優先度はスレッドアクティビティーに基づいて変更されます。このポリシーを持つスレッドは、リアルタイム優先度が 0 と見なされます。
SCHED_FIFO
(先入先出法)- 優先度が 1 から 99 までのリアルタイムポリシーでは、1 が最低でから 99 が最高になります。
SCHED_FIFO
スレッドは常にSCHED_OTHER
スレッドよりも優先度が高くなります (たとえば、1
の優先度が 1 のSCHED_FIFO
スレッドの場合は、任意のSCHED_OTHER
スレッドよりも優先度が高くなります)。SCHED_FIFO
スレッドとして作成されたスレッドの優先度は固定され、優先度の高いスレッドによってブロックまたはプリエンプションされるまで実行されます。 SCHED_RR
ラウンドロビン (Round-Robin)SCHED_RR
はSCHED_FIFO
の変更です。同じ優先度のスレッド、同じ優先度SCHED_RR
スレッド間でスケジュールされるラウンドロビンです。このポリシーはほとんど使用されません。
1.1. レイテンシーテストの実行および結果を解釈
潜在的なハードウェアプラットフォームがリアルタイム操作に適していることを確認するには、リアルタイムカーネルでレイテンシーテストおよびパフォーマンステストを実行する必要があります。このテストは、負荷がかかった可能性のある BIOS またはシステムのチューニング (パーティションを含む) の問題を強調表示することができます。
1.1.1. 主なステップ
手順1.1 システムをテストし、結果を解釈するには、以下を行います。
- 低レイテンシー操作に必要なチューニング手順については、ベンダーのドキュメントを参照してください。この手順は、システムを System Management Mode (SMM) に変換する System Management Interrupts を減らしたり、削除したりします。システムが SMM を使用している場合は、ファームウェアが実行されており、オペレーティングシステムコードを実行していません。つまり、SMM 内で期限切れになるタイマーは、システムが通常の動作に移行するまで待機する必要があります。これにより、SMI が Linux によってブロックされず、実際に SMI を実行したことがベンダー固有のパフォーマンスカウンターレジスターで確認されるため、説明できないレイテンシーが発生する可能性があります。
警告
ハードウェア障害が発生する可能性があるため、Red Hat は SMI を完全に無効にしないことを強く推奨します。 - RHEL-RT および
rt-tests
パッケージがインストールされていることを確認します。この手順では、システムを適切に調整したことを確認します。 hwlatdetect
プログラムを実行します。hwlatdetect
クロックソースをポーリングして説明のないギャップを探して、ハードウェアが生成したレイテンシーを探します。プログラムは、ハードウェアアーキテクチャーまたは BIOS/EFI ファームウェアにより生じるレイテンシーを探すため、通常、hwlatdetect
の実行中にシステムで負荷を実行する必要はありません。hwlatdetect
の通常の出力は以下のようになります。#
hwlatdetect --duration=60s hwlatdetect: test duration 60 seconds detector: tracer parameters: Latency threshold: 10us Sample window: 1000000us Sample width: 500000us Non-sampling period: 500000us Output File: None Starting test test finished Max Latency: Below threshold Samples recorded: 0 Samples exceeding threshold: 0上記の結果は、ファームウェアからのシステム中断を最小限に抑えるために調整されたシステムです。ただし、以下に示すように、システム中断を最小限に抑えるためにすべてのシステムを調整することはできません。#
hwlatdetect --duration=10s hwlatdetect: test duration 10 seconds detector: tracer parameters: Latency threshold: 10us Sample window: 1000000us Sample width: 500000us Non-sampling period: 500000us Output File: None Starting test test finished Max Latency: 18us Samples recorded: 10 Samples exceeding threshold: 10 SMIs during run: 0 ts: 1519674281.220664736, inner:17, outer:15 ts: 1519674282.721666674, inner:18, outer:17 ts: 1519674283.722667966, inner:16, outer:17 ts: 1519674284.723669259, inner:17, outer:18 ts: 1519674285.724670551, inner:16, outer:17 ts: 1519674286.725671843, inner:17, outer:17 ts: 1519674287.726673136, inner:17, outer:16 ts: 1519674288.727674428, inner:16, outer:18 ts: 1519674289.728675721, inner:17, outer:17 ts: 1519674290.729677013, inner:18, outer:17上記の結果はclocksource
、システムの読み取りの連続中に 15-18 us の範囲で表示される遅延が 10 個あることを表しています。hwlatdetect
は、tracer
メカニズムをdetector
として説明していない遅延の場合に使用していました。以前のバージョンの場合は、ftrace tracer
ではなくカーネルモジュールを使用していました。parameters
は、レイテンシーと検出の実行方法を報告します。デフォルトのレイテンシーしきい値は 10 マイクロ秒 (10 ミリ秒) で、サンプルウィンドウは 1 秒で、サンプリングウィンドウは 0.5 秒でした。そのため、tracer
は、指定した期間の各秒の半分で実行されるdetector
スレッドを実行しました。detector
スレッドは、以下の擬似コードを実行するループを実行します。t1 = timestamp() loop: t0 = timestamp() if (t0 - t1) > threshold outer = (t0 - t1) t1 = timestamp if (t1 - t0) > threshold inner = (t1 - t0) if inner or outer: print if t1 > duration: goto out goto loop out:
内部ループ比較は、t0 - t1
が指定したしきい値 (10 us デフォルト) を超えないことを確認します。外部のループ比較では、ループの下部と上位のt1 - t0
間の時間をチェックします。タイムスタンプレジスタの連続する読み取りの時間は、数十ナノ秒 (通常はレジスター読み取り、比較ジャンプ、条件付きジャンプ) である必要があります。したがって、連続する読み取り間の他の遅延がファームウェアによって導入されるか、システムコンポーネントの接続方法により行われます。注記
inner
およびouter
のhwlatdetector
によって用に出力される値は、最善のケースで最大レイテンシーになります。レイテンシーの値は、現在のシステムclocksource
の連続する読み取り (通常はTime Stamp Counter
またはTSC
レジスターですが、HPET
またはACPI
電源管理クロックの可能性もあります) と、ハードウェアとファームウェアの組み合わせにより生じる連続する読み取り間の遅延の間の差分です。
適切なハードウェアファームウェアの組み合わせを見つけた後、次のステップは、負荷がかかった間にシステムのリアルタイムパフォーマンスをテストすることです。
1.1.2. 負荷によるシステムのリアルタイムパフォーマンスのテスト
RHEL RT は、負荷がかかった状態でシステムのリアルタイムパフォーマンスをテストする
rteval
ユーティリティーを提供します。rteval
は、システムが高負荷の SCHED_OTHER
で始まり、オンライン CPU ごとにリアルタイムの応答が測定されます。負荷は、ループと hackbench
合成ベンチマークにおける Linux カーネルツリーの並行 make
です。
この目的は、システムを状態にすることにあります。それぞれのコアには、常にスケジュールするジョブがあります。ジョブは、メモリーの割り当て/解放、ディスク I/O、計算タスク、メモリーコピーなどのさまざまなタスクを実行します。
読み込みが開始されると、
rteval
は、cyclictest
測定プログラムを起動します。このプログラムは、オンラインコアごとに SCHED_FIFO
リアルタイムスレッドを開始し、リアルタイムスケジューリングの応答時間を測定します。各測定スレッドはタイムスタンプを取り、間隔でスリープした後、ウェイク後に別のタイムスタンプを取ります。測定されたレイテンシーは、t1 - (t0 + i)
です。これは、実際のウェイクアップ時間 t1
、最初のタイムスタンプ t0
の理論的なウェイクアップ時間、そしてスリープ間隔 i
の相違点です。
rteval
実行の詳細は、システムの起動ログとともに XML
ファイルに書き込まれます。次に、rteval-<date>-N.tar.bz2
ファイルが生成されます。N
は <date>
における第 N 番目の実行のカウンターです。以下と同様、XML
ファイルから生成されたレポートが画面に出力されます。
System: Statistics: Samples: 1440463955 Mean: 4.40624790712us Median: 0.0us Mode: 4us Range: 54us Min: 2us Max: 56us Mean Absolute Dev: 1.0776661507us Std.dev: 1.81821060672us CPU core 0 Priority: 95 Statistics: Samples: 36011847 Mean: 5.46434910711us Median: 4us Mode: 4us Range: 38us Min: 2us Max: 40us Mean Absolute Dev: 2.13785341159us Std.dev: 3.50155558554us
上記のレポートでは、ハードウェアの詳細、実行の長さ、使用されるオプション、およびタイミング結果 (CPU ごとおよびシステム全体) の詳細が表示されます。
#
rteval --summarize rteval-<date>-n.tar.bz2
コマンドを実行してレポートを再生成できます。