Nils からのヒントとすばらしい記事のおかげで、解決策を見つけました。
オンデマンドのチューニング CPU DVFS ガバナー
オンデマンド ガバナーには、動的周波数スケーリング (または動的電圧および周波数スケーリングの場合は DVFS) を開始するときに制御する一連のパラメーターがあります。これらのパラメータは sysfs ツリーの下にあります:/sys/devices/system/cpu/cpufreq/ondemand/
このパラメータの 1 つは up_threshold です 名前が示唆するように、これはしきい値です (単位は CPU の % ですが、これがコアごとなのか、マージされたコアごとなのかはわかりません)。それを超えると、オンデマンド ガバナーが作動し、周波数を動的に変更し始めます。
sudo を使用して (たとえば) 50% に変更するのは簡単です。
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"
root の場合は、さらに簡単なコマンドを実行できます。
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
注:これらの変更は、次回のホストの再起動後に失われます。 /etc/init.d/rc.local のように、起動時に読み込まれる構成ファイルにそれらを追加する必要があります。
私のゲスト VM は、ホスト上で多くの CPU (80-140%) を消費しているにもかかわらず、両方のコアに負荷を分散していたので、単一のコアが 95% を超えていなかったことがわかりました。 800 MHz のままです。上記のパッチを適用すると、CPU はコアあたりの周波数をはるかに高速に動的に変更します。これは私のニーズにより適しています。50% が私のゲストの使用率のより良いしきい値のようです。マイレージは異なる場合があります。
必要に応じて、HPET を使用しているかどうかを確認してください
タイマーを正しく実装していない該当するものは、DVFS の影響を受ける可能性があります。これは、ホストおよび/またはゲスト環境で問題になる可能性がありますが、ホストにはこれを最小限に抑えるための複雑なアルゴリズムが含まれている場合があります。ただし、最新の CPU には、現在の CPU/コア周波数に依存しない新しい TSC (タイム スタンプ カウンター) があります。これらは、一定 (constant_tsc)、不変 (invariant_tsc)、またはノンストップ (nonstop_tsc) です。TSC の再同期に関するこの Chromium の記事を参照してください。それぞれの詳細については。したがって、CPU にこの TSC のいずれかが装備されている場合、HPET を強制する必要はありません。ホスト CPU がそれらをサポートしているかどうかを確認するには、同様のコマンドを使用します (grep パラメーターを対応する CPU 機能に変更します。ここでは定数 TSC をテストします)。
$ grep constant_tsc /proc/cpuinfo
この最新の TSC をお持ちでない場合は、次のいずれかを行う必要があります:
<オール>安全な解決策は、HPET タイマーを有効にすることです (詳細については以下を参照してください)。TSC タイマーよりもクエリが遅く (TSC は CPU にありますが、HPET はマザーボードにあります)、おそらく正確ではありません (HPET>10MHz; TSC多くの場合、最大 CPU クロック)、特に各コアが異なる周波数を持つ可能性がある DVFS 構成では、はるかに信頼性が高くなります。 Linux は、利用可能な最適なタイマーを使用するほど賢く、まず TSC に依存しますが、信頼性が低すぎる場合は HPET を使用します。これはホスト (ベア メタル) システムでは適切に機能しますが、ハイパーバイザーによってすべての情報が適切にエクスポートされるわけではないため、ゲスト VM が動作の悪い TSC を検出するのはより困難になります。ゲストがこのクロック ソースを利用できるようにするには、ハイパーバイザーが必要ですが、ゲストで HPET を強制的に使用するのが秘訣です!
以下に、Linux および FreeBSD で HPET を構成および/または有効にする方法を示します。
Linux HPET 構成
HPET (高精度イベント タイマー) は、2005 年以降、ほとんどの一般的な PC に搭載されているハードウェア タイマーです。このタイマーは、最新の OS で効率的に使用できます (Linux カーネルは 2.6 以降でサポートされており、FreeBSD では最新の 9.x 以降で安定してサポートされています)。 6.3 で導入されました) は、CPU の電源管理に常に一貫したタイミングを提供します。ティックレス スケジューラの実装を簡単に構築することもできます。
基本的に、HPET は、ホストで DVFS がアクティブであっても、ホストとゲストのタイミング イベントへの影響が少ない安全バリアのようなものです。
HPET の有効化に関する IBM の優れた記事があり、カーネルが使用しているハードウェア タイマーと使用可能なタイマーを確認する方法が説明されています。ここに簡単な要約を示します:
利用可能なハードウェア タイマーの確認:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
現在アクティブなタイマーの確認:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
利用可能な場合に HPET の使用を強制する簡単な方法は、ブートローダーを変更して有効にするように要求することです (カーネル 2.6.16 以降)。この構成はディストリビューションに依存するため、適切に設定するには、独自のディストリビューションのドキュメントを参照してください。 hpet=enable を有効にする必要があります または clocksource=hpet カーネルのブート行 (これもカーネルのバージョンまたはディストリビューションに依存します。首尾一貫した情報は見つかりませんでした)。
これにより、ゲストが HPET タイマーを使用していることを確認します。
注:私のカーネル 3.5 では、Linux が自動的に hpet タイマーを取得しているようです。
FreeBSD ゲスト HPET 構成
FreeBSD では、次のコマンドを実行して利用可能なタイマーを確認できます。
sysctl kern.timecounter.choice
現在選択されているタイマーは、次の方法で確認できます。
sysctl kern.timecounter.hardware
FreeBSD 9.1 は、他のタイマー プロバイダーよりも自動的に HPET を優先するようです。
Todo:FreeBSD で HPET を強制する方法
ハイパーバイザー HPET エクスポート
KVM は、ホストがサポートしている場合、HPET を自動的にエクスポートするようです。ただし、Linux ゲストの場合、kvm-clock (ホスト TSC の準仮想化バージョン) である他の自動的にエクスポートされたクロックが優先されます。好みのクロックに問題があると報告する人もいますが、走行距離は異なる場合があります。ゲストで HPET を強制する場合は、上記のセクションを参照してください。
VirtualBox は、デフォルトでは HPET クロックをゲストにエクスポートしません。また、GUI にエクスポートするオプションはありません。コマンド ラインを使用して、VM の電源がオフになっていることを確認する必要があります。コマンドは次のとおりです:
./VBoxManage modifyvm "VM NAME" --hpet on
上記の変更後もゲストが HPET 以外の別のソースを選択し続ける場合は、上記のセクションを参照して、カーネルに HPET クロックをソースとして使用させる方法を参照してください。
アップスケールをトリガーするのはゲストではなく、ホストがこれを行う必要があります。そのため、ホストで対応するトリガー レベルを下げる必要があります。
ホストでは、kvm CPU はプロセスのように見えます。スケーリング メカニズムはプロセスを監視せず、全体的な CPU 消費のみを監視します。
また、VM の実行中は CPU のスケーリング/スロットリングなどを無効にすることが一般的にベスト プラクティスです