第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の SCHED_FIFO スレッドは、任意 の SCHED_OTHER スレッドよりも優先度が高くなります)。SCHED_FIFO スレッドとして作成されたスレッドの優先度はどれも固定され、優先度の高いスレッドによってブロックまたはプリエンプションされるまで実行されます。 - SCHED_RR (ラウンドロビン)
- 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上記の結果は、システムクロックソースの連続読み取り中に、15 - 18 us の範囲で 10 回の遅延が発生したことを示しています。hwlatdetect は、原因不明の遅延を検出するためにディテクターとしてトレーサーメカニズムを使用していました。以前のバージョンでは、ftrace トレーサーではなくカーネルモジュールが使用されていました。パラメーターは、遅延と検出の実行方法を報告します。デフォルトのレイテンシーしきい値は 10 マイクロ秒 (10 ミリ秒) で、サンプルウィンドウは 1 秒で、サンプリングウィンドウは 0.5 秒でした。その結果、トレーサーは指定された期間の各秒の半分の間実行されるディテクタースレッドを実行しました。ディテクタースレッドは、次の疑似コードを実行するループを実行します。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 マイクロ秒) を超えないことがチェックされます。外側のループの比較では、ループの下部と上部の間の時間 t1 - t0 をチェックします。タイムスタンプレジスタの連続する読み取りの時間は、数十ナノ秒 (通常はレジスター読み取り、比較ジャンプ、条件付きジャンプ) である必要があります。したがって、連続する読み取り間の他の遅延がファームウェアによって導入されるか、システムコンポーネントの接続方法により行われます。注記hwlatdetector によって内側と外側に出力される値は、最良の場合の最大遅延です。レイテンシー値は、現在のシステムクロックソース(通常はタイムスタンプカウンターまたはTSCレジスターですが、HPETまたはACPI電源管理クロックの可能性もあります) の連続読み取り間の差分と、ハードウェアとファームウェアの組み合わせによって導入される連続読み取り間の遅延です。
適切なハードウェアとファームウェアの組み合わせを見つけたら、次のステップは、負荷がかかった状態でシステムのリアルタイムパフォーマンスをテストすることです。
1.1.2. 負荷によるシステムのリアルタイムパフォーマンスのテスト リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
RHEL-RT は、負荷がかかった状態でシステムのリアルタイムパフォーマンスをテストするための rteval ユーティリティーを提供します。rteval は、
SCHED_OTHER タスクの重いシステム負荷を開始し、各オンライン CPU のリアルタイム応答を測定します。ロードは、ループ内の Linux カーネルツリーと Hackbench 合成ベンチマークの並列 作成 です。
その目的は、システムを、それぞれのコアに常にスケジュールするジョブがある状態にすることです。ジョブは、メモリーの割り当て/解放、ディスク 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 コマンド。