低レイテンシの取引アプリケーションでは、レイテンシの問題を非常に意識しています。アプリケーションを実行しているサーバーが PowerNow の状態を変更すると、アプリケーションのレイテンシが増加する可能性があるという懸念があります。
PowerNow の呼び出しに精通しているカーネル開発者はいますか?操作に使用されるプロセッサ時間とレイテンシ/遅延特性はどのようなものですか?
Intel SpeedStep についても同じ情報が役立ちますが、実際に使用しているのは PowerNow です。
ありがとう！
Linux カーネルは、PowerNow の状態変更操作が完了するまでに 5 分の 1 ミリ秒の上限を想定しているようです。
ただし、状態変更自体のコストよりも大きな懸念は、CPU をダウンクロックするとアプリケーションの実行が遅くなり、ボード全体のレイテンシが増加することです。
レイテンシーがあるとは思えません。PowerNow はコア周波数とコア電圧を下げるだけです。そうするためにCPUを短時間停止し、変更後に処理を再開するかどうかはわかりません。私の知る限り、変更はオンザフライで行われ、そのために処理が中断されることはありません。
したがって、より大きな問題は、特定の速度に依存している可能性があります (たとえば、プロセッサが 1 秒間にそれだけの数の操作を実行できると想定している場合)。ただし、コア周波数が低下すると、CPU は低速の CPU のように動作し (1 秒あたりの操作が少なくなります)、 CPU が 100% アイドル状態ではないという理由だけで、コア周波数が最大にジャンプしません。CPU が現在よりも多くの処理能力が必要であると判断すると、再びジャンプします。
Linux では、Windows で VMWare を実行すると、PowerNow が悪い問題を引き起こす可能性があります。PowerNow が有効であることを検出していないようで (仮想マシン内で実行されているためだと思います)、VMWare for Linux も状況を正しく処理できないため、Windows は内部クロックを正しく更新できません。そのため、PowerNow がアクティブになるとすぐに Windows のクロックが遅れ、VMWare がそれを検出して再びクロックを修正します。ここまでは順調ですが、Windows クロックに依存するアプリケーションでは、この奇妙なジャンプが見られ、かなり奇妙な動作をします (たとえば、私が知っているラジオ ストリーミング ソフトウェアは、MP3 ストリーム内でジャンプし、クロックが再同期されるたびに数ミリ秒スキップします)。
アプリケーションが安定したプログラム フローに大きく依存している場合は、PowerNow 機能を完全に無効にすることができます。インターネット ラジオ ストリーム ソフトウェアでは、それがスキップの問題を解決する唯一の方法でした。