観察する：
800MHzから1500MHzまで拡張可能なAMDデュアルコアCPU（Turion II Neo N40L）を搭載したHPサーバーがあります。周波数スケーリングは、Linuxカーネル3.5がインストールされているFreeBSD 9およびUbuntu 12.04で利用できます。しかし、Ubuntuの上にKVM環境にFreeBSD 9をインストールしたところ、周波数スケーリングが機能しませんでした。ゲストシステム（FreeBSDなど）は最小周波数と最大周波数を検出しないため、CPU使用率が高くても調整は行われません。ホストシステム（Ubuntuなど）では、KVMプロセスはCPUリソースの80％〜140％を使用しますが、周波数スケーリングは発生せず、同じUbuntuシステムで別のプロセスを実行しても周波数は800MHzに維持されます。オンデマンドスケーリングスピードコントローラはすぐに周波数を1500MHzに拡張する予定です！
懸念と質問：
CPUがどのように仮想化されるのか、ゲストが適切なスケーリングを行うのか理解できません。正しく機能するためにゲストに公開する必要がある特定のCPU機能はありますか？
付録：
これNext 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 [email protected], 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)
この機能がうまくいく理由は、省エネ、より静かな動作（あまり熱くない）、この機能が機能しない理由と操作方法をよりよく理解したいという単純な好奇心によるものです。
答え1
教えてくれたヒントのおかげで解決策を見つけましたナイルそして良い記事。
調整オンデマンドCPU DVFS ガバナー
需要レギュレータには、動的周波数スケーリング（または動的電圧および周波数スケーリング用のDVFS）の開始時に制御できる一連のパラメータがあります。これらのパラメータはsysfsツリーの下にあります。/sys/devices/system/cpu/cpufreq/ondemand/
パラメータの1つup_thresholdは、名前が示すように、オンデマンドガバナーが起動して周波数変更を開始するしきい値です（CPUのパーセンテージとして表示されますが、これがコアあたりか結合コアかまだ把握していません）。動的に。
たとえば、50％に変更するのはsudoを使って簡単です。
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"
ルートであれば、より簡単なコマンドを使用できます。
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
注：これらの変更は、次回ホストを再起動すると失われます。/etc/init.d/rc.localUbuntuと同様に、起動時に読み取る設定ファイルにそれを追加する必要があります。
ホストで多くのCPU（80〜140％）を消費するゲストVMが、2つのコアに負荷を分割し、どのコアも95％を超えないことを発見しました。だから迷惑なことに、CPUは800MHzに維持されていました。 。これで、上記のパッチを使用すると、CPUは各コアの周波数をより速く動的に変更できるため、私の要件に適しています。ゲスト使用量については、50％がより良いしきい値であるようです。マイレージは異なる場合があります。
(オプション)HPETを使用していることを確認する
タイマーを誤って実装する一部のアプリケーションは、DVFSの影響を受ける可能性があります。ホストには、この問題を最小限に抑えるための洗練されたアルゴリズムがあるかもしれませんが、これはホストおよび/またはゲスト環境で問題になる可能性があります。ただし、最新のCPUには、現在のCPU /コア周波数とは無関係の最新のタイムスタンプカウンタ（TSC）があります。つまり、定数（constant_tsc）、不変（invariant_tsc）、またはノンストップ（nonstop_tsc）です。このChromiumの記事を参照してください。TSCの再同期それぞれに関する追加情報。したがって、CPUにこれらのTSCのいずれかが取り付けられている場合は、HPETを強制する必要はありません。ホストCPUがそれをサポートしていることを確認するには、同様のコマンドを使用します（grepパラメータを対応するCPU機能に変更します。ここでは定数TSCをテストします）。
$ grep constant_tsc /proc/cpuinfo
この最新のTSCがない場合は、以下を実行する必要があります。
- 以下に記載される活性ＨＰＥＴ。
- 正確なタイミングに依存する仮想マシンにアプリケーションがある場合は、CPU DVFSを使用しないでください。レッドハットにおすすめ。
安全な解決策はHPETタイマーを有効にすることです（詳細は以下を参照）。 TSCタイマーよりもクエリが遅く（TSCはCPUにあり、HPETはマザーボードにあります）、正確ではない可能性があります（HPET> 10MHz、TSCは通常最大CPUクロック）、特に各コアは異なる周波数を持つことができますDVFS構成でより安定しています。 Linuxは、利用可能な最高のタイマーを使用するのと同じくらいスマートです。まず、TSCに頼っても信頼できないと判断した場合は、HPETを使用します。これはホスト（ベアメタル）システムでうまく機能しますが、ハイパーバイザーがすべての情報を正しくエクスポートしないため、ゲストVMが正しく機能していないTSCを検出するのがより困難です。ゲストがクロックソースを使用できるようにするにはハイパーバイザーが必要ですが、秘密はゲストがHPETを強制的に使用することです。
以下では、LinuxとFreeBSDでHPETを設定および/または有効にする方法を確認できます。
Linux HPETの構成
HPET（High Precision Event Timer）は、2005年以降、ほとんどの商用PCで見つけることができるハードウェアタイマーです。最新のオペレーティングシステムはこのタイマーを効果的に使用できます（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をサポートするときに自動的にHPETをエクスポートするようです。ただし、Linuxゲストの場合は、自動的にエクスポートされる別のクロックkvm-clock（ホストTSCの半仮想化バージョン）を好みます。一部の人は、好みの時計に問題があると報告しており、マイレージが異なる場合があります。ゲストでHPETを強制するには、上記のセクションを参照してください。
デフォルトでは、VirtualBoxはHPETウォッチをゲストにエクスポートせず、GUIにはそうするオプションはありません。コマンドラインを使用して、仮想マシンがシャットダウンされていることを確認する必要があります。コマンドは次のとおりです。
./VBoxManage modifyvm "VM NAME" --hpet on
上記の変更後もゲストがHPET以外のクロックソースを選択し続ける場合は、カーネルがHPETクロックをクロックソースとして使用するように強制する方法についての上記のセクションを参照してください。
答え2
高度化を促すことは、ゲストではなくホストが行う必要があります。したがって、ホストコンピュータで対応するトリガレベルを下げる必要があります。
答え3
ホストでは、kvm CPUはプロセスのように見えます。拡張メカニズムはプロセスを観察するのではなく、CPU全体の消費量のみを観察します。
一般に、ベストプラクティスは、VMを実行するときにCPUの拡張/制限などを無効にすることです。