web-dev-qa-db-ja.com

KVMゲストが必要とする場合、ホストCPUは周波数をスケーリングしません

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

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

付録：
以下のRed Hatリリースノート は、仮想化環境（6.2.2および6.2.3を参照）でも周波数スケールアウトが機能することを示唆する傾向があり、ノートは対処できないと考えましたこれが機能する仮想化テクノロジー（kvm、xenなど）

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

$ 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)

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

linuxfreebsdkvmcpu-frequencyclock
8
Huygens

Nils と Nice記事 によって与えられたヒントのおかげで解決策を見つけました。

ondemandCPU 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

注：これらの変更は、次回のホストの再起動後に失われます。これらは、Ubuntuの/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）です。このChromiumの記事を参照してください- TSC再同期 それぞれの詳細情報。したがって、CPUにこのTSCのいずれかが搭載されている場合は、HPETを強制する必要はありません。ホストCPUがそれらをサポートしているかどうかを確認するには、同様のコマンドを使用します（grepパラメーターを対応するCPU機能に変更します。ここでは、定数TSCをテストします）。

$ grep constant_tsc /proc/cpuinfo

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

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

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

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

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

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

10
Huygens

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

4
Nils

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

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

2
dyasny