観察：
私は、AMDデュアルコアCPU（Turion II Neo N40L）を搭載したHPサーバーを使用しており、800〜1500 MHzの周波数をスケーリングできます。周波数スケーリングは、Linuxカーネル3.5を搭載したFreeBSD 9およびUbuntu 12.04で機能します。ただし、Ubuntuの上にあるKVM環境にFreeBSD 9を配置すると、周波数スケーリングが機能しません。ゲスト（したがってFreeBSD）は最小周波数と最大周波数を検出しないため、CPU使用率が高くなっても何もスケーリングしません。ホスト（Ubuntu）では、KVMプロセスはCPUリソースの80〜140％を使用しますが、周波数スケーリングは発生せず、周波数は800 MHzのままですが、同じUbuntuボックスで他のプロセスを実行すると、オンデマンドガバナーはすぐに周波数を1500 MHzにスケーリングします。

懸念と質問：
CPUがどのように仮想化されているのか、適切なスケーリングを実行するのがゲストの責任かどうかはわかりません。これが機能するために、ゲストに公開するいくつかのCPU機能が必要ですか？

Apendix：以下のRed Hatのリリースノートがさえ仮想化環境で動作するようにスケールアウトその周波数を示唆する傾向があるが（章6.2.2および6.2.3を参照）、ノートがどの仮想化技術（KVM、Xenの持つこの作品のアドレスに失敗したと思いました、など？）

詳細については、cpufreq-infoUbuntu での出力は次のとおりです。

$ cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 1.50 GHz
  available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 1.50 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 1.50 GHz:14.79%, 1.30 GHz:1.07%, 1000 MHz:0.71%, 800 MHz:83.43%  (277433)
analyzing CPU 1:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 1.50 GHz
  available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 1.50 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 1.50 GHz:14.56%, 1.30 GHz:1.06%, 1000 MHz:0.79%, 800 MHz:83.59%  (384089)

私がこの機能を機能させたい理由は、エネルギーを節約し、静かに（あまり熱くなく）実行することです。また、単純な好奇心で、これが機能しない理由とその機能を理解するためです。

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.localUbuntuのように、起動時に読み込まれる構成ファイルにそれらを追加する必要があります。

私のゲストVMは、ホストで大量のCPU（80-140％）を消費しているにもかかわらず、両方のコアに負荷を分散していることがわかりました。そのため、95％を超えるコアは1つもなかった800 MHzに留まる。上記のパッチにより、CPUは動的にコアあたりの周波数をはるかに速く変更します。これは私のニーズによりよく適合します。50％が私のゲストの使用量のより良いしきい値であるようで、マイレージは異なる場合があります。

オプションで、HPETを使用しているかどうかを確認します。

タイマーを正しく実装していない該当するアプリケーションがDVFSの影響を受ける可能性があります。これは、ホストやゲスト環境で問題になる可能性がありますが、ホストはこれを最小限に抑えるために複雑なアルゴリズムを使用できます。ただし、最近のCPUには、現在のCPU /コア周波数に依存しない新しいTSC（タイムスタンプカウンター）があります。これらは、定数（constant_tsc）、不変（invariant_tsc）、またはノンストップ（nonstop_tsc）です。TSC 再同期に関するこのChromiumの記事を参照してください。それぞれの詳細については。したがって、CPUにこのTSCの1つが搭載されている場合は、HPETを強制する必要はありません。ホストCPUがそれらをサポートしているかどうかを確認するには、同様のコマンドを使用します（grepパラメーターを対応するCPU機能に変更します。ここでは、定数TSCをテストします）。

$ grep constant_tsc /proc/cpuinfo

この最新のTSCがない場合は、次のいずれかを行う必要があります。

1. アクティブなHPET、これについては後で説明します。
2. Red Hatが推奨するものである正確なタイミングに依存するアプリケーションがVMにある場合は、CPU DVFSを使用しないでください。

安全な解決策は、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以降でサポートしています。最新の9.x以降のFreeBSDで安定したサポート）ただし、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の準仮想化バージョン）である、自動的にエクスポートされるもう1つのクロックが優先されます。一部の人々は、優先クロックの問題を報告し、あなたの走行距離は異なる場合があります。ゲストにHPETを強制する場合は、上記のセクションを参照してください。

VirtualBoxは、デフォルトではHPETクロックをゲストにエクスポートしないため、GUIでエクスポートするオプションはありません。コマンドラインを使用して、VMの電源がオフになっていることを確認する必要があります。コマンドは次のとおりです。

./VBoxManage modifyvm "VM NAME" --hpet on

上記の変更後、ゲストがHPET以外の別のソースを選択し続ける場合は、上記のセクションを参照して、カーネルがHPETクロックをソースとして使用するように強制する方法を参照してください。

高級感を誘発するのはゲストではありません-ホストがこれを行う必要があります。したがって、ホストの対応するトリガーレベルを下げる必要があります。

ホストでは、kvm cpuはプロセスのように見えます。スケーリングメカニズムはプロセスを監視せず、全体的なCPU消費のみを監視します。

VMを実行するときは、一般にCPUスケーリング/スロットリングなどを無効にすることがベストプラクティスです。