SMI は、通常の操作中に確実に発生する可能性があります。私の自宅のデスクトップには、チップセットで有効になっているチップセット主導の SMI が 1 秒半ごとに搭載されています。また、BIOS 駆動の CPU 周波数スケーリング スキームのために、1 秒間に 2 回実行しているサーバーもいくつか見てきました。ただし、一部のシステムでは、SMI が発生せずに長期間動作する可能性があるため、状況によって異なります。
質問 #1:hwlatdetect は、システムで発生する SMI のレイテンシを検出するための 1 つのオプションです。 BIOSBITS は、SMI が発生しているかどうかを識別できるブータブル CD であるもう 1 つのオプションです。ループ内でスピンしてタイムスタンプを取得するカーネル モジュールを作成することで、独自のテストを作成することもできます (RDTSC を使用)。 2 つのタイムスタンプの読み取り値の間に長いギャップがある場合は、CPU MSR 0x34 を参照して、SMI が発生したことを示す SMI カウンターが増加したかどうかを確認できます。
SMI を生成したい場合は、OUT CPU 命令をポート 0xb2 に対して実行するカーネル モジュールを作成できます。このポートに値 0 を書き込みます。 (ポート 0xB2 への書き込みの直前と直後のタイムスタンプを収集して、この SMI の時間を計ることもできます)。
質問 2、SMI は OS の下のレイヤーで動作するため、どの OS を選択しても影響はありません。
質問 #3:BIOSBITS は、SMI レイテンシーを 150 マイクロ秒未満に保つことを推奨しています。
SMI はシステムを SMM (システム管理モード) モードにします。これにより、SMI 処理時間中、カーネルの通常の実行が延期されます。言い換えれば、SMMi は、カーネルの通常の動作で知られているように、リアル モードでもプロテクト モードでもなく、代わりに SMRAM (BIOS ファームウェアに保存されている) に保存されている特別な命令を実行します。レイテンシーを検出するには、SMI をトリガーして (ソフトウェアで生成することもできます)、SMM モードで費やされた合計時間を把握してみてください。これを達成するには、Linux カーネル モジュールを作成します。これは、SMI を発行するための特別な権限が必要になるからです (私はそう思います)。
リアルタイム システムの場合、SMI のようなこの種の割り込みを回避できるとよいと思います。
システム管理割り込み (SMI) が処理されているかどうかは、ターボスタットで確認できます。例:
# turbostat sleep 120
[check column SMI for value greater than 0]
もちろん、そこから SMI 周波数を計算することもできます。
SMI が実際に一定の割合で発生していることを知ることは、重要な情報です。ただし、システム管理モード (SMM) がこれらの割り込みに費やす時間も知りたいと考えています。たとえば、SMI の中断が非常に短い場合は、リアルタイム アプリケーションとは無関係である可能性があります。一方、SMI の中断が長いハードウェアを使用している場合は、おそらくベンダーと話し、ファームウェアを別の方法で構成するか (可能であれば)、SMM の影響が少ない他のハードウェアに切り替える必要があります。
perf ツールには、SMI 中に SMM で費やされたサイクル数を測定するモードがあります (特定の CPU カウンターによって提供される情報を使用)。例:
# perf stat -a -A --smi-cost -- sleep 120
Performance counter stats for 'system wide':
SMI cycles% SMI#
CPU0 0.0% 0
CPU1 0.0% 0
CPU2 0.0% 0
CPU3 0.0% 0
120.002927948 seconds time elapsed
次の方法で生の値を確認することもできます:
# perf stat -a -A --smi-cost --metric-only -- sleep 120
そこから、マシン上で SMI にかかる平均時間を計算できます。 (サイクル差を時間単位あたりのサイクル数で割ります)。
CPU カウンター ベースの結果と経験的な結果を照合することは確かに理にかなっています。
Linux カーネルに統合されている Linux Hardware Latency Detector を使用できます。使用例:
# echo hwlat > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /sys/kernel/debug/tracing/tracing_thresh
# watch -d -n 5 cat /sys/kernel/debug/tracing/tracing_max_latency
# echo "Don't forget to disable it again"
# echo nop > /sys/kernel/debug/tracing/current_tracer
これらのツールは CentOS/RHEL 7 で利用でき、他のディストリビューションでも利用できるはずです。
大まかな数値について:最近、毎分 504 SMI を起動する HP 2011 風の ProLiant Gen8 Xeon サーバーに出会いました。 Perf は SMM で 0.1 % のレートを計算し、カウンター値に基づいて、SMI で費やされる平均時間は数マイクロ秒にもなりますが、Linux hwlat 検出器はそのシステムでそのような高い中断を検出しません。
この SMI レートは、低レイテンシー アプリケーション向けの HPE ProLiant サーバーの構成とチューニングに関する HP のドキュメント (2017 年 10 月) と一致します。
<ブロック引用>プロセッサへのシステム管理割り込みを無効にすると、低遅延環境に最大の利点の 1 つが提供されます。プロセッサの電力と使用率の監視 SMI を無効にすると、1 秒間に 8 回プロセッサ割り込みが生成されるため、最大の効果があります。 G6以降のサーバー。
(私のものを強調してください。そのガイドには、他の SMI ソースも記載されています)
私の Intel Atom C3758 と Intel NUC (i5-4250U) システムを搭載した Supermicro ボードでは、SMI はまったくカウントされません。
Intel i7-6600U ベースの Dell ラップトップでは、システムは 1 分あたり 8 つの SMI を報告しますが、aperf カウンターは (停止されていない) サイクル カウンターよりも低く、これは発生するはずがありません。