仮想ＣＰＵベースの、周波数、及び電圧制御
【課題】仮想環境の各々の仮想プロセッサのために実行される周波数、及び電圧制御を統合して、性能を犠牲にせずにパワーセービングを達成する。
【解決手段】各々の仮想プロセッサによって実行されるワークロードの特徴は、動的にプロファイルが作られ、かつ制御アルゴリズム１４０ａ〜１４０ｎは、前記プロファイルが作られた特徴の関数として、その仮想プロセッサのための制御ファクタを決定する。プロファイルが作られた特徴は、実行されている前記ワークロードに関連づけられた、仮想化イベントを含んでもよく、加えて、特定の制御アルゴリズム、及びプロファイリング技術は、どの仮想プロセッサが現在動作しているかに基づいて選択されてもよい。
【解決手段】各々の仮想プロセッサによって実行されるワークロードの特徴は、動的にプロファイルが作られ、かつ制御アルゴリズム１４０ａ〜１４０ｎは、前記プロファイルが作られた特徴の関数として、その仮想プロセッサのための制御ファクタを決定する。プロファイルが作られた特徴は、実行されている前記ワークロードに関連づけられた、仮想化イベントを含んでもよく、加えて、特定の制御アルゴリズム、及びプロファイリング技術は、どの仮想プロセッサが現在動作しているかに基づいて選択されてもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想ＣＰＵベースの、周波数、及び電圧制御に関する。
【背景技術】
【０００２】
マイクロプロセッサ、及びコンピュータシステムが発展するにつれて、多くのソフトウエアが単一のプラットフォームで実行されるようになってきた。異なるプラットフォーム、及びオペレーティングシステム（ＯＳ）用に記述された異なるソフトウエアに対応するために、仮想化技術が開発された。仮想化は、リソースを共有し、かつ単一のハードウェアプラットホーム上で、並行して実行する複数のＯＳ、及びアプリケーションを使用可能にする。今日、仮想化は、小型のサーバから複数の・カスタマーに同時に計算サービスを提供する大規模なデータセンターまで、多様な種類のコンピューティング環境に、利用されるようになってきている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
仮想化は、バーチャルマシーンモニタ（ＶＭＭ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）と称するソフトウェア・エンティティを使用して、一般にインプリメントされる。ＶＭＭは各々のＯＳに仮想資源を提供し、一つ以上の仮想プロセッサ、仮想メモリ、及び仮想入出力（Ｉ／Ｏ）リソースを含む仮想マシン（ＶＭ）を備える。そして、ＯＳは完全に、かつ直接的にこれを制御する。ＶＭＭは、仮想化ポリシー（例えばＶＭの中の物理的資源の共有及び／又は割当）をインプリメントするためのシステム環境を確保する。ホスト又はホスト・ソフトウェア、例えばＶＭＭは、仮想環境の外で動作するソフトウエアであるのに対して、各々のＯＳ、及びその他のソフトウエアは、ＶＭ上で動作するゲストあるいはゲストソフトウェアと称する。したがって、仮想化技術は、複数のゲストソフトウェアが単一のホスト又は物理的なプラットフォーム上で同時に動作することを可能とする。システム上で動作しているゲストは、仮想ＣＰＵ（ＶＣＰＵ）を認識している。これは、ちょうど、物理ＣＰＵ又はこれのサブセットとしての物理ＣＰＵ（ＰＣＰＵ）の特長を有する。仮想化技術が単一の物理的な計算機に多くの多様なワークロードを統合することができるため、仮想化は物理的資源の効率的利用を実現し、したがって、一つの環境にやさしい（又はグリーン）技術として認識されうる。特にエネルギー消費が増加の傾向にある中で、これは仮想化技術の普及を促進させている。しかしながら、単に単一のプラットフォーム上にＯＳを統合することだけでは、効率化の要求を満たすには十分ではない。この目的のために、仮想化技術は、より高度化されたパワーマネージメント（又はパワーセービング）の能力が、まず、クライアントデバイスに、そして現在においては、ハイエンドサーバにも普及し始めている。しかしながら、ＣＰＵの仮想化、及び物理的資源の連続共有、及び再割当は、複雑化を将来する。物理マシン上のＯＳによってインプリメントされる従来のパワーマネージメント技術を仮想環境に移行させることを難しくする。
【課題を解決するための手段】
【０００４】
本発明の目的を実現するために、本発明は、複数の仮想処理デバイスの各々によって実行されるワークロードの特徴のプロファイルを作るステップと；
前記仮想処理デバイスのそれぞれのプロファイルが作られた特徴の関数として、各々の仮想処理デバイスのためのクロック周波数を決定するステップと；
を有する方法を提供する。
【図面の簡単な説明】
【０００５】
【図１】本発明の一実施例のシステムのブロック図である。
【図２】本発明の一実施例に従う方法のフローチャートである。
【図３】本発明の一実施例に従う例示的な仮想マシンモニタのブロック図である。
【発明を実施するための形態】
【０００６】
各種実施形態において、周波数制御（ｆｒｅｑｕｅｎｃｙ ｓｃａｌｉｎｇ）、及び電圧制御（ｖｏｌｔａｇｅ ｓｃａｌｉｎｇ）を含むパワーセービング能力が仮想化技術と効率的に一体化され得る。現在の仮想システムは、あらゆるタイプの制御技術を行わないか（すなわちパワーセービングを行わないか）、あるいは、物理マシンのＯＳにより実装されるアルゴリズムと同じものを実行するかのいずれかである。しかしながら、物理的な環境のために用いられる制御アルゴリズムは、仮想環境に十分役立つとは言えない。物理マシンにおいてインプリメントされる一般の制御技術の１つの例として、動的な電圧、及び周波数制御（ＤＶＦＳ：ｖｏｌｔａｇｅ ａｎｄ ｆｒｅｑｕｅｎｃｙ ｓｃａｌｉｎｇ）と呼ばれるものがある。チップセット（例えばプロセッサ又はＣＰＵ）のパワーの浪費は、そのチップセットのスタティックＣＭＯＳゲートに加えられる電圧及び周波数によるものである。ＤＶＦＳ技術によって、電源消費は、環境変化に基づいて、ＣＰＵに適用される信号の電圧、及び周波数を変えることによって、能率的に減少する。ＤＶＦＳ技術をインプリメントしているシステムにおいては、パフォーマンスに対して最小の影響しか及ぼさないように、制御アルゴリズムが、電圧、及び周波数を制御することが適切な時期をインテリジェントに決定する。この一つの方法は、ＣＰＵの利用に基づいて、制御を決定することである。
【０００７】
しかしながら、物理プロセッサ（すなわちＰＣＰＵ）の利用に基づくパワーセービングアルゴリズムは、仮想マシンにおいてインプリメントされる多様な種類のワークロード（例えばメモリ利用のワークロード、レイテンシに敏感なワークロード、その他）に対して、ほとんど関知しない。仮想化は、並行して実行する一つの物理マシンに、様々なワークロードを統合するための物理プロセッサの利用に基づく制御アルゴリズムであり、現在スケジュールされているワークロードに対して対応が遅く、しかも密接に関係することができない場合がある。さらに、単に物理マシンによって使用されるアルゴリズムを用いることは、仮想ＣＰＵ上で動作しているワークロード特徴を示す仮想化イベントを発見する機会を逃してしまう。この種のインジケータは、ほとんど考慮されることはない。なぜなら、このインジケータを検知することが複雑であるためと、コストが高いためである。ＶＭＭソフトウエアは、仮想資源（例えばＣＰＵ、メモリ、Ｉ／Ｏ）をゲストに提供する必要があるため、これらのインジケータは仮想環境において、利用可能な状態にあるのである。
【実施例】
【０００８】
したがって、本発明の一部の実施例では、周波数、及び電圧を制御する技術は、物理ＣＰＵではなく、各々の仮想ＣＰＵに関連付けられる。例えば、各々の仮想ＣＰＵは、制御をその特定のＶＣＰＵ用に修正し指示するために、それ自身のワークロード・プロファイリング・チャネル及び／又はそれ自身の制御アルゴリズムによって配給される。加えて、さまざまなＶＣＰＵで実行される多様なワークロードに対し、動的にかつ、より知的に反応するために、一部の実施例のプロファイル・ワークロードの特徴は、仮想化イベントの連続モニタリングに基づいている。このような実施例では、複数の異なる制御アルゴリズムは、現在実行しているワークロードの実際の特徴の関数として、選択的に利用できてもよい。このように、周波数、及び電圧制御は急速に変化する統合されたワークロード・パターンに反応することができ、パフォーマンスを犠牲にせずにパワーセービングが達成される。
【０００９】
周波数、及び電圧制御アルゴリズムは、ＰＣＰＵの要求、及び利用に関する一般的な経過情報（ｈｉｓｔｏｒｉｃａｌ ｉｎｆｏｒｍａｔｉｏｎ）に基づく。例えば、一部のＯＳのインプリメンテーションは、定期的に、例えば、２０ミリ秒の（ｍｓ）間隔で、ＰＣＰＵの利用をサンプリングする。ＰＣＰＵの利用のその過去のパターンに基づいて、適切なクロック周波数（又は制御ファクタ）が、次の２０ｍｓの間隔のＣＰＵに対して決定されてもよい。例えば、ＣＰＵの利用度が高い場合、高い周波数が選択される。同様に、利用度が低い場合、低い周波数が選択されてもよい。ＯＳシステム・スケジューラが通常は短い間隔（例えば１ｍｓ）で動作するので、この技術は物理システムにおいて一般に十分である。したがって、一般に２０ｍｓのウィンドウにおいて監視されるワークロード・パターンは、単一のＰＣＰＵ上の平均ワークロード・パターンの正確な指示を提供するのに十分である。
【００１０】
しかしながら、ＶＭＭスケジューラは、そのＰＣＰＵ上で動作しているＶＣＰＵのために、ＰＣＰＵを時分割する必要があり、異なる振る舞いを見せる。短い間隔で動作するよりはむしろ、ＶＭＭスケジューラは、一般には、各々の新しく導入された仮想化レイヤーによる高いコンテクストスイッチのオーバーヘッドを回避するために、タスクのスケジューリングを、より大きい間隔で緩慢にさせる。例えば、ＶＭＭは、通常は３０ｍｓのオーダ以上のスケジューリング間隔を有してもよい。この時間量（例えば３０ｍｓ）は、長ささとしては、ＰＣＰＵ制御アルゴリズムの周波数制御間隔（例えば２０ｍｓ）に比較的近いので、前にスケジュールアウトされた（scheduled-out）ＶＣＰＵのパターンが次にスケジュールインされた（scheduled-in）ＶＣＰＵのための周波数制御を決定するために使用されるという可能性が高い。スケジュールアウトされたＶＣＰＵ、及びスケジュールインされたＶＣＰＵは、非常に異なる種類のワークロードで実行されうるため、スケジュールインされたＶＣＰＵのために選択される周波数は、現在実行されている動作に十分に適しているとは限らない。この課題は、「誤った制御（ｆａｌｓｅ ｓｃａｌｉｎｇ）」と称する一つの課題である。この場合誤った制御の課題を回避する一つの方策は、単純に、制御間隔を拡張することである（例えば、２００ｍｓ以上）。しかしながら、長い制御間隔は、逆に、動作中のワークロードの急速な変化に反応することができず、かつ、制御アルゴリズムがリソースを共有することに対する公正さに問題を生じさせることになってしまうことがある。各ＶＣＰＵに対して自身のプロファイリング・チャネルを与えることによって、この誤った制御を回避する。このため、各ＶＣＰＵの特長を個別的にモニタし、分析することを可能とする。したがって、制御の決定は、実際のＶＣＰＵで実行されているワークロードの特徴に基づくことができる。
【００１１】
上述したように、制御の決定は、通常はＣＰＵの利用の関数であってもよい。しかしながら、ＣＰＵの利用は必ずしも特定のワークロードに対する最適周波数のための精密なインジケータでない。そして、それはまた、誤った制御の状況に結果としてなることがある。例えば、メモリの集中的なワークロードは、ＣＰＵをサチュレートさせ得る。また、多くのストールサイクルを発生させる。したがって、ＣＰＵの利用において、高周波が選択されなければならないことを示す場合であっても、実際には、パフォーマンスの低下を伴わずに、低い周波数が選択され得る。本発明の一部の実施例は、ＣＰＵの利用に基づかないワークロード・パターンを認識し、ワークロード特徴プロファイリング・チャネルを適応させ、この種の誤った制御の課題に対処する。
【００１２】
いくつかの実施例では、ＶＣＰＵベースの制御は、また、各々のＶＣＰＵのための異なる制御アルゴリズムを使用することにより、更なる効果を提供してもよい。さらに他の、複数の制御アルゴリズムが、いかなるＶＣＰＵ用に利用されてもよい。例えば、１つの制御アルゴリズムはＣＰＵの利用に基づいて周波数を選択することに適していてもよい。他の制御アルゴリズムはパフォーマンスの考慮に基づいて周波数を選択するように構成されてもよい。また、他の制御アルゴリズムはパワーセービング等にその決定の基礎をおいてもよい。このような実施例では、特定の制御アルゴリズムは、プロファイリング・チャネルによって提供される現在のワークロードの特徴に基づいて、動的に選択されてもよい。現在のワークロードの特徴に変化が合った場合、現在選択された制御アルゴリズムは、他の制御アルゴリズムと交換されてもよい。以下に更に詳細に述べるが、例えば、Ｉ／Ｏに集中した（ｉｎｔｅｎｓｉｖｅ）ワークロード、メモリに集中したワークロード、及びレイテンシに集中したワークロードは、それらのワークロードの特徴の現実を考慮に入れた異なる制御アルゴリズムの使用によって、軽減されうる。
【００１３】
各々のＶＣＰＵのために用意された改善された制御能力を提供することに加えて、ＶＣＰＵベースの制御は、更に正確に、コンピューティングサービスとそのカスタマーとの間のサービスレベル契約を遵守することの判断の機会を提供する。例えば、この種の契約は、物理的な処理リソースの利用、及び速度に基づく特定の条項を含みうる。したがって、各々のＶＣＰＵが動作している周波数は、サービスレベル契約要件に対して考慮に入れてもよいファクタである。ＰＣＰＵベースの制御が使用される場合、正確に周波数の要件を遵守することが可能でないこともあろう。したがって、この種の要件に従うＶＣＰＵが、ＰＣＰＵ上で動作している限り、ＰＣＰＵベースの制御アルゴリズムはディスエーブルしなければならないかもしれない。ＶＣＰＵベースの制御は、各々のカスタマーのワークロードのためのシステムの処理リソースの利用を、より正確に測定及び課金することを容易にすることができる。
【００１４】
図１は、本発明の一実施例に従った仮想環境のＶＣＰＵベースの制御をインプリメントするための例示的なフレームワーク１００である。図１は、仮想化フレームワーク１００の実施例を示すが、実施例は、また、仮想化技術が使用される特定の用途に従って、他のフレームワーク、アーキテクチュア、システム、プラットフォーム又は環境においてインプリメントされてもよいことは言うまでもない。図１に示すように、仮想化フレームワーク１００は、ＯＳ又はＶＭＭソフトウエアを実行することができるコンピュータシステムのいずれにも対応し得る、基本的なハードウェアプラットホーム１０２を備える。例えば、基本的なハードウェアプラットホームは、パソコン、メインフレームコンピュータ、ポータブルコンピュータ、ハンドヘルド・コンピュータ、セットトップボックス、サーバ又はその他のコンピューティング・システムであってもよい。図１に示すように、基本的なハードウェアプラットホーム１０２は、物理プロセッサ（又はＰＣＰＵ）１０４、メモリ１０６、Ｉ／Ｏリソース１０７、及びプラットフォーム１０２（例えばＰＣＰＵ１０４）の各種要素用の周波数を有するクロック信号、及び電圧を生成するためのクロック生成／制御回路１０８を有する。
【００１５】
ＰＣＰＵ１０４は、任意のタイプのプロセッサであってもよい。例えば、多目的マイクロプロセッサ（例えばマルチコアプロセッサ、マイクロコントローラ又はプログラマブル・ロジック）を含む。図１は、１つのＰＣＰＵ１０４だけを示すが、基本的なハードウェアプラットホーム１０２がマルチプロセッサを含んでもよいことは言うまでもない。そして、各々がいかなる数の実行コアをも有するいかなる数のマルチコアプロセッサ、及び、各々がいかなる数のスレッドをも有するいかなる数のマルチスレッドのプロセッサを含む。
【００１６】
図１において示されるメモリ１０６は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）又は他のメモリ例えばスタティックランダムアクセスメモリを含んでもよい。基本的なプラットフォームハードウエア１０２は、いかなる数の補助装置又は接続を含んでもよい。例えば、データ、アプリケーション、ソフトウエアの命令等を保存する様々な記憶装置が挙げられる。
【００１７】
基本的なハードウェアプラットホーム１０２に加えて、図１のシステム１００は、ＶＭＭ１１０、及びＶＣＰＵｓ１１２ａ、１１２ｂ、１１２ｎ、ゲストＯＳ１２２、及び１２４、及びゲストアプリケーション１２６、１２８、１３０、及び１３４を含むＶＭ１１８、及び１２０を有する。図示するように、ゲストＯＳ１２２、及びゲストアプリケーション１２６、及び１２８は、ＶＣＰＵｓ１１２ａ、及び１１２ｂによって実行されるために、ＶＭ１１８にインストールされる。ゲストＯＳ１２４、及びゲストアプリケーション１３０、及び１３２は、ＶＣＰＵ１１２ｎによって実行されるために、ＶＭ１２０にインストールされる。しかしながら、システム１００は、いかなる数のＶＭ、ゲスト、及びＶＣＰＵｓを含んでもよく、また、ＶＭは、他の仮想資源（例えば仮想メモリ、仮想Ｉ／Ｏリソース、その他）を含んでもよい。なお、発明の範囲は、この点に関して制限されない。
ＶＭＭ１１０は、ゲストにＶＭ（すなわち基本プラットフォームハードウエア１０２の抽象化）を提供するために、又はＶＭを生成し管理し仮想化ポリシーをインプリメントするために、基本プラットフォームハードウエア１０２にインストールされあるいはアクセスできる、いかなるソフトウエア、ファームウェア又はハードウェア・ホストであってもよい。その他の実施例では、ホストは、いかなるＶＭＭ、ハイパーバイザ、ＯＳ又は他のソフトウエア、ファームウェア又は基本的なプラットフォームでハードウエア１０２が制御可能なハードウエアであってもよい。ゲストはいかなるＯＳ、いかなるＶＭＭでもあってもよい。そして、ＶＭＭ１１０の他のインスタンス、いかなるハイパーバイザ、いかなるアプリケーション、又は他のソフトウエアをも含む。
【００１８】
図１を参照すると、ＶＭＭ１１０は、仮想ベースの周波数、及び電圧制御（ＶＢＦＶＳ）センタ１３４、及び複数のＶＢＦＶＳインスタンス（ｉｎｓｔａｎｃｅ）１３６ａ−ｎを含む。各々のＶＢＦＶＳインスタンス１３６ａ−ｎは、ＶＣＰＵ１１２ａ−ｎに割り当てられる。各々のＶＢＦＶＳインスタンス１３６ａ−ｎは、また、プロファイルの関数としてのＶＣＰＵのワークロードの特徴を規定するプロファイリング・チャネル１３８ａ−ｎに拘束され、かつプロファイルを作ることによって提供されたプロファイルの関数として適切に制御された周波数及び／又は電圧（又は制御ファクタ）を決定する制御アルゴリズム１４０ａ−ｎに拘束される。いくつかの実施例では、特定の制御アルゴリズム１４０に対する拘束は、動的に実行されてもよい。例えば、プロファイリングデータは、ＶＣＰＵにかかるワークロードに対して、現在拘束されているアルゴリズム１４０ａよりも、制御アルゴリズム１４０ｂが、より適していることを示してもよい。この種の場合、ＶＢＦＶＳインスタンス１３６は、アルゴリズム１４０ａから制御アルゴリズム１４０ｂに動的に切り替えてもよい。
【００１９】
図１を再度参照する。また、システム１００は、各々のＶＣＰＵｓ１１２ａ−ｎをスケジュールするためのＶＭＭスケジューラ１４２を含む。スケジューラ１４２が新規なＶＣＰＵ（例えばＶＣＰＵ１１２ｂ）のスケジュールをするとき、スケジューラ１４２はコンテクストスイッチ・イベントをＶＢＦＶＳセンター１３４に送信する。ＶＢＦＶＳセンター１３４がコンテクストスイッチ・イベントを受け入れると、スケジュールインされたＶＣＰＵ１１２ｂに割り当てるために、ＶＢＦＶＳセンター１３４は、ＶＢＦＶＳインスタンス（例えばインスタンス１３６ｂ）を選択する。ＶＢＦＶＳインスタンス１３６ｂに関連づけられたプロファイリング・チャネル（例えば、１３８ｂチャネル）が開始され、適切に制御された周波数及び／又は電圧を決定するために、インスタンス１３６ｂに拘束される制御アルゴリズム（例えばアルゴリズム１４０ｂ）に情報を提供する。ＶＢＦＶＳセンター１３４は、ＰＣＰＵ１０４のためのクロック信号を生成するクロック生成回路１０８に新しい周波数の指示を通信することによって、周波数を制御する。いくつかの実施例では、制御は、ＶＣＰＵ１１２ｂがスケジュールインされている全ての期間の間、繰り返し実行される。実施例において、各々のＶＢＦＶＳインスタンス１３６は、また、アカウント及びバジェットモジュール（ＡＢＭ：Ａｃｃｏｕｎｔｉｎｇ ａｎｄ Ｂｕｄｇｅｔｉｎｇ Ｍｏｄｕｌｅ）１４４に関連づけられた、あるＶＣＰＵレベルでパワー、及びエネルギーのきめ細かい計算を提供する。図２は、システム１００でインプリメントされ得る周波数及び／又は電圧制御を決定するための例示的なフローチャートである。本発明は、示されるステップの特定のステップ又は特定の順番に限られないことが、理解されなければならない。他の実施例は、より少ないステップを含んでもよく、あるいは、順番を変えてもよい。
【００２０】
図２において、ブロック２０２で、ＶＭＭスケジューラ１４２は、新規なＶＣＰＵ（例えばＶＣＰＵ１１２ｂ）をスケジュールインする。ブロック２０４で、ＶＭＭスケジューラ１４２は、コンテクストスイッチ・イベントをＶＢＦＶＳセンター１３４に送信する。ＶＢＦＶＳセンター１３４は、スケジュールインされたＶＣＰＵ１１２（ブロック２０６）のためのＶＢＦＶＳインスタンス１３６を選択する。いくつかの実施例では、ＶＢＦＶＳセンター１３４は、また、制御統計をスケジューラ１４２に送信してもよい。例えば、ＶＢＦＶＳセンター１３４は、スケジュールアウトされたＶＣＰＵによってプロファイリング・チャネル及び制御アルゴリズムが最後に使用されたかを記憶してもよい。そして、ワークロード特徴、及びＶＣＰＵ使用に関する統計を更新してもよい。ＶＢＦＶＳセンター１３４は、また、スケジュールアウトされたＶＣＰＵ用に決定された最後の周波数を記録してもよい。ＶＢＦＶＳセンター１３４は、また、統計をスケジューラ１４２に送信してもよい。更に、ＶＢＦＶＳセンター１３４は、スケジュールインされたＶＣＰＵ１１２のための前に記録された最後の周波数を回復してもよく、かつ現在のスケジュールインされたＶＣＰＵ１１２によって最後に使用されたプロファイリングメカニズム、及び制御アルゴリズムを解凍してもよい。その他の実施例では、ＶＢＦＶＳセンター１３４は、スケジュールインされたＶＣＰＵに最初に適用するために、どの周波数、プロファイリングメカニズム、及び制御アルゴリズムを決定する他の技術を用いてもよい。例えば、デフォルトの開始パラメータ等が挙げられる。プロファイリングメカニズム、制御アルゴリズム、及び周波数／電圧が、スケジュールインされたＶＣＰＵのために最初に選択される態様にかかわらず、選択されたプロファイリング・チャネル１３８が、作動して、かつ、スケジュールインされたＶＣＰＵ１１２の現在の実行のワークロードの特徴のプロファイルを作成するためにデータを収集し始める（ブロック２０８、及び２１０）。プロファイルとして収集された情報は、選択された制御アルゴリズム１４０に提供される。ブロック２１２で、アルゴリズム１４０は、適切な周波数／電圧（又は制御ファクタ）を決定し、かつ、ＶＢＦＶＳセンター１３４にそれを通信する。ＶＢＦＶＳセンター１３４は、クロック生成回路１０８のクロック周波数／電圧を制御する。プロファイリング・チャネル１３８はデータを収集し、かつ制御アルゴリズム１４０を送信し続け、かつ新規なＶＣＰＵがスケジュールインされるまで、制御アルゴリズム１４０はデータに応答して周波数及び／又は電圧を制御し続ける。
【００２１】
上記したように、様々な形の制御アルゴリズムが使用されてもよい。そして、事実、複数の異なる種類の制御アルゴリズムが、現在のスケジュールインされたＶＣＰＵのために選択的に利用されてもよい。したがって、実施例によって、図２において示される制御・技術は、新規な制御アルゴリズム１４０に変更するか、プロファイルとして収集されたワークロードに基づいて、これを選択するステップを有する（ブロック２１４）。例えば、本発明の１つの例示的実施態様で、選択的に利用できる１タイプの制御アルゴリズムは、ＣＰＵ要求ベース（ＣＰＵ ｄｅｍａｎｄ−ｂａｓｅｄ）（ＣＰＵ−ＤＢＳ）のアルゴリズムである。通常、物理ＣＰＵの利用は、以下によって算出されてもよい：
（Ｔｅｌａｐｓｅｄ−Ｔｉｄｌｅ）／Ｔｅｌａｐｓｅｄ （式１）
ここで、Ｔｅｌａｐｓｅｄは、利用が最後にサンプリングされてからの経過時間である。そして、Ｔｉｄｌｅは経過時間の段階の間のＣＰＵアイドルタイムである。
【００２２】
ＶＣＰＵに基づく制御・フレームワークに対して、この要求ベースの式は、ＶＣＰＵに密接に関わるようにし、その結果、誤った制御の発生を減らすように変更することができる。例えば、いくつかの新しい要因が、仮想環境を考慮に入れたプロファイリング・チャネル１３８にもたらされてもよい。例えば、仮想マシンで、ＶＭＭスケジューラ１４２は、一般に一部のタイムクオンタム（例えば３０ｍｓ）を各々のスケジュールインされたＶＣＰＵ１１２に割り当てる。しかしながら、スケジュールインされたＶＣＰＵ１１２が、１つのタイムスライスで、それに付与されたクオンタムの全てを消費してもよいというわけでない、幾つかの状況が存在する。ＶＣＰＵ１１２自体が動作を停止したためにアイドル状態に入ったときが、その一例である。この状態では、仮想化イベントがＶＣＰＵ１１２をウエイクアップさせるまで、ＶＭＭスケジューラ１４２は、ＶＣＰＵ１１２をブロック状態（ｂｌｏｃｋｅｄ ｓｔａｔｅ）としてもよい。ＶＣＰＵの利用を特定するために、ＶＣＰＵ１１２がブロック状態のままである時間を、Ｔｂｌｏｃｋｅｄと称してもよい。したがって、スケジューラ１４２は、ワークロードの特長をプロファイルとすることに利用するために、与えられたクオンタム及びブロックされたパラメータをプロファイリング・チャネル１３８に伝えてもよい。
【００２３】
ＶＣＰＵ１１２が単一のタイムスライスのその全てのクオンタムを消費してはならない他の状況は、ＶＣＰＵ１１２よりも、他の上位の優先するＶＣＰＵｓ１１２が優先されるときに発生しうる。この場合に、優先されていない（ｐｒｅｅｍｐｔｅｄ）ＶＣＰＵ１１２は、まだ作動できる状態（ｒｕｎａｂｌｅ）であるが、動作のキュー（ｒｕｎ ｑｕｅｕｅ）に止まっており、かつ、実際に継続中の意味あるジョブを持っている。また、ＶＣＰＵ１１２利用を特定するために、この優先されてしまった時間（ｐｒｅｅｍｐｔｅｄ ｔｉｍｅ）は、Ｔｓｔｏｌｅｎと称してもよい。そして、スケジューラ１４２は、横取りされた時間パラメータ（ｓｔｏｌｅｎ ｔｉｍｅ ｐａｒａｍｅｔｅｒ）をプロファイリング・チャネル１３８に転送してもよい。
【００２４】
これらの新しい要素を踏まえ、プロファイリング・チャネル１３８は、以下の通りにＶＣＰＵ１１２の利用を算出してもよい：
（Ｔｑｕａｎｔｕｍ−Ｔｓｔｏｌｅｎ−Ｔｂｌｏｃｋｅｄ）／（Ｔｑｕａｎｔｕｍ−Ｔｓｔｏｌｅｎ） （式２）
ＶＣＰＵ１１２の利用を決定する式（２）を用いることによって、ネイティブＯＳ環境のための周知の要求周波数制御アルゴリズムが利用されてもよい。ここでの差異は、（ＰＣＰＵ１０４利用の代わりに）ＶＣＰＵ１１２の利用は、ＤＢＳベースのアルゴリズム１４０の入力として提供されることである。ＶＣＰＵの利用を入力として、ＣＰＵ−ＤＢＳアルゴリズムは、低い利用度に対しては低い周波数をアウトプットし、またその逆も成り立つ。
【００２５】
ＣＰＵ−ＤＢＳアルゴリズムは、パフォーマンス、及びパワーセービングの間の最適バランスを提供しない場合がある。いくつかの場合では、より良好なバランスを担保するためには、現在のワークロードの特徴に関して、付加的な、あるいは異なる情報（ＶＣＰＵ１１２利用以外）のプロファイルを作ることによって達成されてもよい。仮想環境においては、仮想化の間、ワークロード特徴が推論され得る多くのヒントが生成される。より詳しくは、単一の物理マシン上の複数のＶＭを統合するために、ＶＭＭは、各々のＶＭから様々な形のセンシティブなアクションをインターセプトし、所望の挙動をエミュレートし、かつ非同期仮想割り込みを導入することを必要とする。この新規な仮想化レイヤーは、基本的なハードウェアプラットホーム上の動作と比較して、オーバーヘッドを仮想マシンに加える。しかしながら、この必然的なオーバーヘッドによって提供される豊富なヒントは、ワークロード特徴の推測を補助するために使用されてもよい。
【００２６】
例えば、入出力（Ｉ／Ｏ）の集中した特徴を有するワークロードは、エミュレートされた入出力デバイス上の入出力要求の頻度に基づいて、直ちに識別され得る。入出力デバイスがドライバ・レベルで、並列に仮想化（ｐａｒａ−ｖｉｒｔｕａｌｉｚｅｄ）されている場合、高度なドライバは、Ｉ／Ｏの集中したワークロードを示す統計を率先して提供することができる。別の例として、メモリ仮想化イベントは、メモリの集中したワークロードのインジケータであってもよい。例えば、ＶＭＭは、通常は、シャドウページテーブルを維持する。シャドウページテーブルは、ゲスト・ページテーブルから生成され、後者が変更されると後者と同期する。これは、ゲスト・ページテーブルがＰＣＰＵによって直接理解することができない仮想メモリアドレスを含むためである。ＶＭＭはゲスト・ページテーブルを読取り専用にマークしてもよい。ゲストがその現在のページテーブルを修正することを試みると、同期するＶＭＭのためにページフォルトが発生する。ＶＣＰＵがしばしばメモリを割り当てて、かつ開放する場合、この種のワークロードはこの種のページフォルトを示す統計に識別されてもよい。レイテンシに敏感なワークロードは、また、直ちに識別されてもよい。通常は、レイテンシに敏感なパターンは、複数の・タイマー、及び割り込みによって特徴づけられる。タイマー、及び割り込みのソースがＶＭＭによって仮想化されるので、ＶＭＭはレイテンシに敏感なワークロードを識別するためにそれらのイベントをトラッキングすることができる。
【００２７】
上で述べた仮想化イベントは、例示的なものであることが、理解されなければならない。そして、その他方式、及びイベント又はインジケータの組合せが、プロファイルの収集に使用されてもよく、そして、適切な制御アルゴリズムを選択するために、ワークロードの特徴を推論してもよい。さらに、ワークロード特徴のプロファイルを作ること、および推論することは、ＶＭＭの特定のインプリメンテーション、ハードウエア仮想化の特徴等の基本的な特長などに従い変化してもよい。ワークロード特徴を識別する特定の方法に関係なく、本発明の実施例は、図１において示されるＶＣＰＵに基づく制御・フレームワークに、それらの特徴を導入してもよい。これらのワークロードの特徴を使用することにより、そのワークロードを持つＶＣＰＵに割り当てられるＶＣＰＵインスタンスを拘束するために、特定の制御アルゴリズムが選択されてもよい。
【００２８】
以下の実施例は、ワークロード特徴に基づいて、制御アルゴリズムの複数の・タイプの選択ができることによって達成され得る利点を例示する。第１の実施例として、メモリの集中したワークロードは通常は多くのストールサイクルを有する。このように、この種のワークロードはパフォーマンスを失うことのない、より低い周波数クロックによって動作することができ、同時に、より低い周波数オペレーションはパワーセービングとなりうる。こうした状況では、ＣＰＵ−ＤＢＳアルゴリズムは良好な候補ではない。なぜなら、ＶＣＰＵがメモリの集中したワークロードの下で完全にサチュレートしており、そのため、ＣＰＵ−ＤＢＳアルゴリズムは高い周波数を計算する。その代わりに、メモリの集中したワークロードは、より低い周波数で動作させることができるという認識に基づいて、パワーセービングベースの制御アルゴリズムが選択されうる。したがって、チャネルプロファイリルを作ることによって収集されるデータが、メモリの集中したワークロードのヒントを示す場合、より低い周波数オペレーションとなるよう、電力セーブ・アルゴリズムが選択されてもよい。
【００２９】
別の例として、レイテンシに敏感なワークロードに対しては、ＶＣＰＵの低い利用を行ってもよい。したがって、ＣＰＵ−ＤＢＳアルゴリズムは、結果として低い周波数の選択となる。しかしながら、ＶＣＰＵがレイテンシに敏感なワークロードで動作するときは、それはすばやく入力イベントに反応することが可能でなければならない。低い周波数がレイテンシ（待ち時間）を増加させるため、ＣＰＵ−ＤＢＳアルゴリズムは適切でない。その代わりに、レイテンシに敏感なワークロードが、プロファイルが作られたインジケータから推論される場合、高い周波での動作を確実にするパフォーマンスベースの制御アルゴリズムが選択され得る。
【００３０】
ＣＰＵ−ＤＢＳアルゴリズムは、多くの適用範囲を更に有する。例えば、ほとんど仮想化イベントが検出されない場合、ＶＣＰＵの利用は、周波数の制御に対する適切な指標であり得る。
【００３１】
図３の例示的実施形態に示すように、各々のＶＢＦＶＳインスタンス１３６のためのチャネルプロファイル１３８は、さまざまな仮想化イベントソース（例えば仮想デバイス１４６のモデル、仮想マシン１４８間の通信、仮想割込コントローラ１５０、メモリに関連する仮想化イベントソース１５２、その他）からの情報を収集することによって、仮想化イベントのプロファイルを作る。加えて、プロファイリング・チャネル１３８は、ＶＣＰＵの割当クオンタム、失われた時間（ｓｔｏｌｅｎ ｔｉｍｅ）、ブロック化された時間、などを含むＶＣＰＵの利用に関し、スケジューラ１４２から情報を受信する。これらのさまざまなソースからの情報は、ＶＣＰＵ１１２がスケジュールインされたＶＣＰＵであるクオンタムの間、連続的に分析される。これによって、情報から認識されるワークロード特徴パターンに基づいて、ＶＦＢＶＳインスタンス１３６がそれ自体を特定の制御アルゴリズム１４０ａ−ｃに動的に拘束することができる。図３に示すように、利用できる制御アルゴリズムは、ＣＰＵ−ＤＢＳアルゴリズム１４０ａ、電力セーブ・アルゴリズム１４０ｂ、及びパフォーマンスベースのアルゴリズム１４０ｃ、等である。
【００３２】
ＶＣＰＵベースの制御は、本願明細書において記載されている具体例に限定されない。例えば、本発明の一実施例において、ＶＣＰＵベースの制御は、単にプロファイリング情報としてＶＣＰＵ周波数変動要求を使用し、ＶＢＦＶＳセンターに要求を渡すためのパススルー制御アルゴリズム、又は、要求を直接ＶＢＦＶＳセンターにルーティングすることを選択することによって、インプリメントされてもよい。実施例は、ソフトウェアコード（ＶＭＭ１１０、及びそのコンポーネントのいずれかを含む）でインプリメントされてもよく、かつ、システムが命令を実行するようにプログラムするために使用できる命令を記憶する記憶媒体に記憶されてもよい。記憶媒体は、ディスクを含むフロッピー（登録商標）ディスク、光ディスク、固体ドライブ、コンパクトディスク読取り専用メモリ、コンパクトディスク書き換え可能メモリ、及び光磁気ディスク、半導体デバイス例えば、読取り専用メモリ、ランダムアクセスメモリ、例えばダイナミック・ランダム・アクセス・メモリ、スタティックランダムアクセスメモリ、消去可能なプログラマブル・リードオンリーメモリ、フラッシュメモリ、電気的に消去可能なリードオンリーメモリ、磁気あるいは光学カード、その他、電子的命令を記憶することに適するあらゆるタイプのメディアが含まれる。もちろん、これらに限定されるものではない。ソフトウエアの命令は、プロセッサ（例えば図１のＰＣＰＵ１０４）での実行のためにロードされてもよい。
【００３３】
本発明が限定された数の実施例に関して記載されているが、当業者はそこから多数の修正変更を理解する。添付の請求項は、本発明の精神及び本発明の範囲に該当する全ての実施例およびバリエーションを含む
【符号の説明】
【００３４】
１００ 仮想化フレームワーク
１０２ ハードウェアプラットホーム
１１０ ＶＭＭ
１１８ ＶＭ
１２０ ＶＭ
【技術分野】
【０００１】
本発明は、仮想ＣＰＵベースの、周波数、及び電圧制御に関する。
【背景技術】
【０００２】
マイクロプロセッサ、及びコンピュータシステムが発展するにつれて、多くのソフトウエアが単一のプラットフォームで実行されるようになってきた。異なるプラットフォーム、及びオペレーティングシステム（ＯＳ）用に記述された異なるソフトウエアに対応するために、仮想化技術が開発された。仮想化は、リソースを共有し、かつ単一のハードウェアプラットホーム上で、並行して実行する複数のＯＳ、及びアプリケーションを使用可能にする。今日、仮想化は、小型のサーバから複数の・カスタマーに同時に計算サービスを提供する大規模なデータセンターまで、多様な種類のコンピューティング環境に、利用されるようになってきている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
仮想化は、バーチャルマシーンモニタ（ＶＭＭ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）と称するソフトウェア・エンティティを使用して、一般にインプリメントされる。ＶＭＭは各々のＯＳに仮想資源を提供し、一つ以上の仮想プロセッサ、仮想メモリ、及び仮想入出力（Ｉ／Ｏ）リソースを含む仮想マシン（ＶＭ）を備える。そして、ＯＳは完全に、かつ直接的にこれを制御する。ＶＭＭは、仮想化ポリシー（例えばＶＭの中の物理的資源の共有及び／又は割当）をインプリメントするためのシステム環境を確保する。ホスト又はホスト・ソフトウェア、例えばＶＭＭは、仮想環境の外で動作するソフトウエアであるのに対して、各々のＯＳ、及びその他のソフトウエアは、ＶＭ上で動作するゲストあるいはゲストソフトウェアと称する。したがって、仮想化技術は、複数のゲストソフトウェアが単一のホスト又は物理的なプラットフォーム上で同時に動作することを可能とする。システム上で動作しているゲストは、仮想ＣＰＵ（ＶＣＰＵ）を認識している。これは、ちょうど、物理ＣＰＵ又はこれのサブセットとしての物理ＣＰＵ（ＰＣＰＵ）の特長を有する。仮想化技術が単一の物理的な計算機に多くの多様なワークロードを統合することができるため、仮想化は物理的資源の効率的利用を実現し、したがって、一つの環境にやさしい（又はグリーン）技術として認識されうる。特にエネルギー消費が増加の傾向にある中で、これは仮想化技術の普及を促進させている。しかしながら、単に単一のプラットフォーム上にＯＳを統合することだけでは、効率化の要求を満たすには十分ではない。この目的のために、仮想化技術は、より高度化されたパワーマネージメント（又はパワーセービング）の能力が、まず、クライアントデバイスに、そして現在においては、ハイエンドサーバにも普及し始めている。しかしながら、ＣＰＵの仮想化、及び物理的資源の連続共有、及び再割当は、複雑化を将来する。物理マシン上のＯＳによってインプリメントされる従来のパワーマネージメント技術を仮想環境に移行させることを難しくする。
【課題を解決するための手段】
【０００４】
本発明の目的を実現するために、本発明は、複数の仮想処理デバイスの各々によって実行されるワークロードの特徴のプロファイルを作るステップと；
前記仮想処理デバイスのそれぞれのプロファイルが作られた特徴の関数として、各々の仮想処理デバイスのためのクロック周波数を決定するステップと；
を有する方法を提供する。
【図面の簡単な説明】
【０００５】
【図１】本発明の一実施例のシステムのブロック図である。
【図２】本発明の一実施例に従う方法のフローチャートである。
【図３】本発明の一実施例に従う例示的な仮想マシンモニタのブロック図である。
【発明を実施するための形態】
【０００６】
各種実施形態において、周波数制御（ｆｒｅｑｕｅｎｃｙ ｓｃａｌｉｎｇ）、及び電圧制御（ｖｏｌｔａｇｅ ｓｃａｌｉｎｇ）を含むパワーセービング能力が仮想化技術と効率的に一体化され得る。現在の仮想システムは、あらゆるタイプの制御技術を行わないか（すなわちパワーセービングを行わないか）、あるいは、物理マシンのＯＳにより実装されるアルゴリズムと同じものを実行するかのいずれかである。しかしながら、物理的な環境のために用いられる制御アルゴリズムは、仮想環境に十分役立つとは言えない。物理マシンにおいてインプリメントされる一般の制御技術の１つの例として、動的な電圧、及び周波数制御（ＤＶＦＳ：ｖｏｌｔａｇｅ ａｎｄ ｆｒｅｑｕｅｎｃｙ ｓｃａｌｉｎｇ）と呼ばれるものがある。チップセット（例えばプロセッサ又はＣＰＵ）のパワーの浪費は、そのチップセットのスタティックＣＭＯＳゲートに加えられる電圧及び周波数によるものである。ＤＶＦＳ技術によって、電源消費は、環境変化に基づいて、ＣＰＵに適用される信号の電圧、及び周波数を変えることによって、能率的に減少する。ＤＶＦＳ技術をインプリメントしているシステムにおいては、パフォーマンスに対して最小の影響しか及ぼさないように、制御アルゴリズムが、電圧、及び周波数を制御することが適切な時期をインテリジェントに決定する。この一つの方法は、ＣＰＵの利用に基づいて、制御を決定することである。
【０００７】
しかしながら、物理プロセッサ（すなわちＰＣＰＵ）の利用に基づくパワーセービングアルゴリズムは、仮想マシンにおいてインプリメントされる多様な種類のワークロード（例えばメモリ利用のワークロード、レイテンシに敏感なワークロード、その他）に対して、ほとんど関知しない。仮想化は、並行して実行する一つの物理マシンに、様々なワークロードを統合するための物理プロセッサの利用に基づく制御アルゴリズムであり、現在スケジュールされているワークロードに対して対応が遅く、しかも密接に関係することができない場合がある。さらに、単に物理マシンによって使用されるアルゴリズムを用いることは、仮想ＣＰＵ上で動作しているワークロード特徴を示す仮想化イベントを発見する機会を逃してしまう。この種のインジケータは、ほとんど考慮されることはない。なぜなら、このインジケータを検知することが複雑であるためと、コストが高いためである。ＶＭＭソフトウエアは、仮想資源（例えばＣＰＵ、メモリ、Ｉ／Ｏ）をゲストに提供する必要があるため、これらのインジケータは仮想環境において、利用可能な状態にあるのである。
【実施例】
【０００８】
したがって、本発明の一部の実施例では、周波数、及び電圧を制御する技術は、物理ＣＰＵではなく、各々の仮想ＣＰＵに関連付けられる。例えば、各々の仮想ＣＰＵは、制御をその特定のＶＣＰＵ用に修正し指示するために、それ自身のワークロード・プロファイリング・チャネル及び／又はそれ自身の制御アルゴリズムによって配給される。加えて、さまざまなＶＣＰＵで実行される多様なワークロードに対し、動的にかつ、より知的に反応するために、一部の実施例のプロファイル・ワークロードの特徴は、仮想化イベントの連続モニタリングに基づいている。このような実施例では、複数の異なる制御アルゴリズムは、現在実行しているワークロードの実際の特徴の関数として、選択的に利用できてもよい。このように、周波数、及び電圧制御は急速に変化する統合されたワークロード・パターンに反応することができ、パフォーマンスを犠牲にせずにパワーセービングが達成される。
【０００９】
周波数、及び電圧制御アルゴリズムは、ＰＣＰＵの要求、及び利用に関する一般的な経過情報（ｈｉｓｔｏｒｉｃａｌ ｉｎｆｏｒｍａｔｉｏｎ）に基づく。例えば、一部のＯＳのインプリメンテーションは、定期的に、例えば、２０ミリ秒の（ｍｓ）間隔で、ＰＣＰＵの利用をサンプリングする。ＰＣＰＵの利用のその過去のパターンに基づいて、適切なクロック周波数（又は制御ファクタ）が、次の２０ｍｓの間隔のＣＰＵに対して決定されてもよい。例えば、ＣＰＵの利用度が高い場合、高い周波数が選択される。同様に、利用度が低い場合、低い周波数が選択されてもよい。ＯＳシステム・スケジューラが通常は短い間隔（例えば１ｍｓ）で動作するので、この技術は物理システムにおいて一般に十分である。したがって、一般に２０ｍｓのウィンドウにおいて監視されるワークロード・パターンは、単一のＰＣＰＵ上の平均ワークロード・パターンの正確な指示を提供するのに十分である。
【００１０】
しかしながら、ＶＭＭスケジューラは、そのＰＣＰＵ上で動作しているＶＣＰＵのために、ＰＣＰＵを時分割する必要があり、異なる振る舞いを見せる。短い間隔で動作するよりはむしろ、ＶＭＭスケジューラは、一般には、各々の新しく導入された仮想化レイヤーによる高いコンテクストスイッチのオーバーヘッドを回避するために、タスクのスケジューリングを、より大きい間隔で緩慢にさせる。例えば、ＶＭＭは、通常は３０ｍｓのオーダ以上のスケジューリング間隔を有してもよい。この時間量（例えば３０ｍｓ）は、長ささとしては、ＰＣＰＵ制御アルゴリズムの周波数制御間隔（例えば２０ｍｓ）に比較的近いので、前にスケジュールアウトされた（scheduled-out）ＶＣＰＵのパターンが次にスケジュールインされた（scheduled-in）ＶＣＰＵのための周波数制御を決定するために使用されるという可能性が高い。スケジュールアウトされたＶＣＰＵ、及びスケジュールインされたＶＣＰＵは、非常に異なる種類のワークロードで実行されうるため、スケジュールインされたＶＣＰＵのために選択される周波数は、現在実行されている動作に十分に適しているとは限らない。この課題は、「誤った制御（ｆａｌｓｅ ｓｃａｌｉｎｇ）」と称する一つの課題である。この場合誤った制御の課題を回避する一つの方策は、単純に、制御間隔を拡張することである（例えば、２００ｍｓ以上）。しかしながら、長い制御間隔は、逆に、動作中のワークロードの急速な変化に反応することができず、かつ、制御アルゴリズムがリソースを共有することに対する公正さに問題を生じさせることになってしまうことがある。各ＶＣＰＵに対して自身のプロファイリング・チャネルを与えることによって、この誤った制御を回避する。このため、各ＶＣＰＵの特長を個別的にモニタし、分析することを可能とする。したがって、制御の決定は、実際のＶＣＰＵで実行されているワークロードの特徴に基づくことができる。
【００１１】
上述したように、制御の決定は、通常はＣＰＵの利用の関数であってもよい。しかしながら、ＣＰＵの利用は必ずしも特定のワークロードに対する最適周波数のための精密なインジケータでない。そして、それはまた、誤った制御の状況に結果としてなることがある。例えば、メモリの集中的なワークロードは、ＣＰＵをサチュレートさせ得る。また、多くのストールサイクルを発生させる。したがって、ＣＰＵの利用において、高周波が選択されなければならないことを示す場合であっても、実際には、パフォーマンスの低下を伴わずに、低い周波数が選択され得る。本発明の一部の実施例は、ＣＰＵの利用に基づかないワークロード・パターンを認識し、ワークロード特徴プロファイリング・チャネルを適応させ、この種の誤った制御の課題に対処する。
【００１２】
いくつかの実施例では、ＶＣＰＵベースの制御は、また、各々のＶＣＰＵのための異なる制御アルゴリズムを使用することにより、更なる効果を提供してもよい。さらに他の、複数の制御アルゴリズムが、いかなるＶＣＰＵ用に利用されてもよい。例えば、１つの制御アルゴリズムはＣＰＵの利用に基づいて周波数を選択することに適していてもよい。他の制御アルゴリズムはパフォーマンスの考慮に基づいて周波数を選択するように構成されてもよい。また、他の制御アルゴリズムはパワーセービング等にその決定の基礎をおいてもよい。このような実施例では、特定の制御アルゴリズムは、プロファイリング・チャネルによって提供される現在のワークロードの特徴に基づいて、動的に選択されてもよい。現在のワークロードの特徴に変化が合った場合、現在選択された制御アルゴリズムは、他の制御アルゴリズムと交換されてもよい。以下に更に詳細に述べるが、例えば、Ｉ／Ｏに集中した（ｉｎｔｅｎｓｉｖｅ）ワークロード、メモリに集中したワークロード、及びレイテンシに集中したワークロードは、それらのワークロードの特徴の現実を考慮に入れた異なる制御アルゴリズムの使用によって、軽減されうる。
【００１３】
各々のＶＣＰＵのために用意された改善された制御能力を提供することに加えて、ＶＣＰＵベースの制御は、更に正確に、コンピューティングサービスとそのカスタマーとの間のサービスレベル契約を遵守することの判断の機会を提供する。例えば、この種の契約は、物理的な処理リソースの利用、及び速度に基づく特定の条項を含みうる。したがって、各々のＶＣＰＵが動作している周波数は、サービスレベル契約要件に対して考慮に入れてもよいファクタである。ＰＣＰＵベースの制御が使用される場合、正確に周波数の要件を遵守することが可能でないこともあろう。したがって、この種の要件に従うＶＣＰＵが、ＰＣＰＵ上で動作している限り、ＰＣＰＵベースの制御アルゴリズムはディスエーブルしなければならないかもしれない。ＶＣＰＵベースの制御は、各々のカスタマーのワークロードのためのシステムの処理リソースの利用を、より正確に測定及び課金することを容易にすることができる。
【００１４】
図１は、本発明の一実施例に従った仮想環境のＶＣＰＵベースの制御をインプリメントするための例示的なフレームワーク１００である。図１は、仮想化フレームワーク１００の実施例を示すが、実施例は、また、仮想化技術が使用される特定の用途に従って、他のフレームワーク、アーキテクチュア、システム、プラットフォーム又は環境においてインプリメントされてもよいことは言うまでもない。図１に示すように、仮想化フレームワーク１００は、ＯＳ又はＶＭＭソフトウエアを実行することができるコンピュータシステムのいずれにも対応し得る、基本的なハードウェアプラットホーム１０２を備える。例えば、基本的なハードウェアプラットホームは、パソコン、メインフレームコンピュータ、ポータブルコンピュータ、ハンドヘルド・コンピュータ、セットトップボックス、サーバ又はその他のコンピューティング・システムであってもよい。図１に示すように、基本的なハードウェアプラットホーム１０２は、物理プロセッサ（又はＰＣＰＵ）１０４、メモリ１０６、Ｉ／Ｏリソース１０７、及びプラットフォーム１０２（例えばＰＣＰＵ１０４）の各種要素用の周波数を有するクロック信号、及び電圧を生成するためのクロック生成／制御回路１０８を有する。
【００１５】
ＰＣＰＵ１０４は、任意のタイプのプロセッサであってもよい。例えば、多目的マイクロプロセッサ（例えばマルチコアプロセッサ、マイクロコントローラ又はプログラマブル・ロジック）を含む。図１は、１つのＰＣＰＵ１０４だけを示すが、基本的なハードウェアプラットホーム１０２がマルチプロセッサを含んでもよいことは言うまでもない。そして、各々がいかなる数の実行コアをも有するいかなる数のマルチコアプロセッサ、及び、各々がいかなる数のスレッドをも有するいかなる数のマルチスレッドのプロセッサを含む。
【００１６】
図１において示されるメモリ１０６は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）又は他のメモリ例えばスタティックランダムアクセスメモリを含んでもよい。基本的なプラットフォームハードウエア１０２は、いかなる数の補助装置又は接続を含んでもよい。例えば、データ、アプリケーション、ソフトウエアの命令等を保存する様々な記憶装置が挙げられる。
【００１７】
基本的なハードウェアプラットホーム１０２に加えて、図１のシステム１００は、ＶＭＭ１１０、及びＶＣＰＵｓ１１２ａ、１１２ｂ、１１２ｎ、ゲストＯＳ１２２、及び１２４、及びゲストアプリケーション１２６、１２８、１３０、及び１３４を含むＶＭ１１８、及び１２０を有する。図示するように、ゲストＯＳ１２２、及びゲストアプリケーション１２６、及び１２８は、ＶＣＰＵｓ１１２ａ、及び１１２ｂによって実行されるために、ＶＭ１１８にインストールされる。ゲストＯＳ１２４、及びゲストアプリケーション１３０、及び１３２は、ＶＣＰＵ１１２ｎによって実行されるために、ＶＭ１２０にインストールされる。しかしながら、システム１００は、いかなる数のＶＭ、ゲスト、及びＶＣＰＵｓを含んでもよく、また、ＶＭは、他の仮想資源（例えば仮想メモリ、仮想Ｉ／Ｏリソース、その他）を含んでもよい。なお、発明の範囲は、この点に関して制限されない。
ＶＭＭ１１０は、ゲストにＶＭ（すなわち基本プラットフォームハードウエア１０２の抽象化）を提供するために、又はＶＭを生成し管理し仮想化ポリシーをインプリメントするために、基本プラットフォームハードウエア１０２にインストールされあるいはアクセスできる、いかなるソフトウエア、ファームウェア又はハードウェア・ホストであってもよい。その他の実施例では、ホストは、いかなるＶＭＭ、ハイパーバイザ、ＯＳ又は他のソフトウエア、ファームウェア又は基本的なプラットフォームでハードウエア１０２が制御可能なハードウエアであってもよい。ゲストはいかなるＯＳ、いかなるＶＭＭでもあってもよい。そして、ＶＭＭ１１０の他のインスタンス、いかなるハイパーバイザ、いかなるアプリケーション、又は他のソフトウエアをも含む。
【００１８】
図１を参照すると、ＶＭＭ１１０は、仮想ベースの周波数、及び電圧制御（ＶＢＦＶＳ）センタ１３４、及び複数のＶＢＦＶＳインスタンス（ｉｎｓｔａｎｃｅ）１３６ａ−ｎを含む。各々のＶＢＦＶＳインスタンス１３６ａ−ｎは、ＶＣＰＵ１１２ａ−ｎに割り当てられる。各々のＶＢＦＶＳインスタンス１３６ａ−ｎは、また、プロファイルの関数としてのＶＣＰＵのワークロードの特徴を規定するプロファイリング・チャネル１３８ａ−ｎに拘束され、かつプロファイルを作ることによって提供されたプロファイルの関数として適切に制御された周波数及び／又は電圧（又は制御ファクタ）を決定する制御アルゴリズム１４０ａ−ｎに拘束される。いくつかの実施例では、特定の制御アルゴリズム１４０に対する拘束は、動的に実行されてもよい。例えば、プロファイリングデータは、ＶＣＰＵにかかるワークロードに対して、現在拘束されているアルゴリズム１４０ａよりも、制御アルゴリズム１４０ｂが、より適していることを示してもよい。この種の場合、ＶＢＦＶＳインスタンス１３６は、アルゴリズム１４０ａから制御アルゴリズム１４０ｂに動的に切り替えてもよい。
【００１９】
図１を再度参照する。また、システム１００は、各々のＶＣＰＵｓ１１２ａ−ｎをスケジュールするためのＶＭＭスケジューラ１４２を含む。スケジューラ１４２が新規なＶＣＰＵ（例えばＶＣＰＵ１１２ｂ）のスケジュールをするとき、スケジューラ１４２はコンテクストスイッチ・イベントをＶＢＦＶＳセンター１３４に送信する。ＶＢＦＶＳセンター１３４がコンテクストスイッチ・イベントを受け入れると、スケジュールインされたＶＣＰＵ１１２ｂに割り当てるために、ＶＢＦＶＳセンター１３４は、ＶＢＦＶＳインスタンス（例えばインスタンス１３６ｂ）を選択する。ＶＢＦＶＳインスタンス１３６ｂに関連づけられたプロファイリング・チャネル（例えば、１３８ｂチャネル）が開始され、適切に制御された周波数及び／又は電圧を決定するために、インスタンス１３６ｂに拘束される制御アルゴリズム（例えばアルゴリズム１４０ｂ）に情報を提供する。ＶＢＦＶＳセンター１３４は、ＰＣＰＵ１０４のためのクロック信号を生成するクロック生成回路１０８に新しい周波数の指示を通信することによって、周波数を制御する。いくつかの実施例では、制御は、ＶＣＰＵ１１２ｂがスケジュールインされている全ての期間の間、繰り返し実行される。実施例において、各々のＶＢＦＶＳインスタンス１３６は、また、アカウント及びバジェットモジュール（ＡＢＭ：Ａｃｃｏｕｎｔｉｎｇ ａｎｄ Ｂｕｄｇｅｔｉｎｇ Ｍｏｄｕｌｅ）１４４に関連づけられた、あるＶＣＰＵレベルでパワー、及びエネルギーのきめ細かい計算を提供する。図２は、システム１００でインプリメントされ得る周波数及び／又は電圧制御を決定するための例示的なフローチャートである。本発明は、示されるステップの特定のステップ又は特定の順番に限られないことが、理解されなければならない。他の実施例は、より少ないステップを含んでもよく、あるいは、順番を変えてもよい。
【００２０】
図２において、ブロック２０２で、ＶＭＭスケジューラ１４２は、新規なＶＣＰＵ（例えばＶＣＰＵ１１２ｂ）をスケジュールインする。ブロック２０４で、ＶＭＭスケジューラ１４２は、コンテクストスイッチ・イベントをＶＢＦＶＳセンター１３４に送信する。ＶＢＦＶＳセンター１３４は、スケジュールインされたＶＣＰＵ１１２（ブロック２０６）のためのＶＢＦＶＳインスタンス１３６を選択する。いくつかの実施例では、ＶＢＦＶＳセンター１３４は、また、制御統計をスケジューラ１４２に送信してもよい。例えば、ＶＢＦＶＳセンター１３４は、スケジュールアウトされたＶＣＰＵによってプロファイリング・チャネル及び制御アルゴリズムが最後に使用されたかを記憶してもよい。そして、ワークロード特徴、及びＶＣＰＵ使用に関する統計を更新してもよい。ＶＢＦＶＳセンター１３４は、また、スケジュールアウトされたＶＣＰＵ用に決定された最後の周波数を記録してもよい。ＶＢＦＶＳセンター１３４は、また、統計をスケジューラ１４２に送信してもよい。更に、ＶＢＦＶＳセンター１３４は、スケジュールインされたＶＣＰＵ１１２のための前に記録された最後の周波数を回復してもよく、かつ現在のスケジュールインされたＶＣＰＵ１１２によって最後に使用されたプロファイリングメカニズム、及び制御アルゴリズムを解凍してもよい。その他の実施例では、ＶＢＦＶＳセンター１３４は、スケジュールインされたＶＣＰＵに最初に適用するために、どの周波数、プロファイリングメカニズム、及び制御アルゴリズムを決定する他の技術を用いてもよい。例えば、デフォルトの開始パラメータ等が挙げられる。プロファイリングメカニズム、制御アルゴリズム、及び周波数／電圧が、スケジュールインされたＶＣＰＵのために最初に選択される態様にかかわらず、選択されたプロファイリング・チャネル１３８が、作動して、かつ、スケジュールインされたＶＣＰＵ１１２の現在の実行のワークロードの特徴のプロファイルを作成するためにデータを収集し始める（ブロック２０８、及び２１０）。プロファイルとして収集された情報は、選択された制御アルゴリズム１４０に提供される。ブロック２１２で、アルゴリズム１４０は、適切な周波数／電圧（又は制御ファクタ）を決定し、かつ、ＶＢＦＶＳセンター１３４にそれを通信する。ＶＢＦＶＳセンター１３４は、クロック生成回路１０８のクロック周波数／電圧を制御する。プロファイリング・チャネル１３８はデータを収集し、かつ制御アルゴリズム１４０を送信し続け、かつ新規なＶＣＰＵがスケジュールインされるまで、制御アルゴリズム１４０はデータに応答して周波数及び／又は電圧を制御し続ける。
【００２１】
上記したように、様々な形の制御アルゴリズムが使用されてもよい。そして、事実、複数の異なる種類の制御アルゴリズムが、現在のスケジュールインされたＶＣＰＵのために選択的に利用されてもよい。したがって、実施例によって、図２において示される制御・技術は、新規な制御アルゴリズム１４０に変更するか、プロファイルとして収集されたワークロードに基づいて、これを選択するステップを有する（ブロック２１４）。例えば、本発明の１つの例示的実施態様で、選択的に利用できる１タイプの制御アルゴリズムは、ＣＰＵ要求ベース（ＣＰＵ ｄｅｍａｎｄ−ｂａｓｅｄ）（ＣＰＵ−ＤＢＳ）のアルゴリズムである。通常、物理ＣＰＵの利用は、以下によって算出されてもよい：
（Ｔｅｌａｐｓｅｄ−Ｔｉｄｌｅ）／Ｔｅｌａｐｓｅｄ （式１）
ここで、Ｔｅｌａｐｓｅｄは、利用が最後にサンプリングされてからの経過時間である。そして、Ｔｉｄｌｅは経過時間の段階の間のＣＰＵアイドルタイムである。
【００２２】
ＶＣＰＵに基づく制御・フレームワークに対して、この要求ベースの式は、ＶＣＰＵに密接に関わるようにし、その結果、誤った制御の発生を減らすように変更することができる。例えば、いくつかの新しい要因が、仮想環境を考慮に入れたプロファイリング・チャネル１３８にもたらされてもよい。例えば、仮想マシンで、ＶＭＭスケジューラ１４２は、一般に一部のタイムクオンタム（例えば３０ｍｓ）を各々のスケジュールインされたＶＣＰＵ１１２に割り当てる。しかしながら、スケジュールインされたＶＣＰＵ１１２が、１つのタイムスライスで、それに付与されたクオンタムの全てを消費してもよいというわけでない、幾つかの状況が存在する。ＶＣＰＵ１１２自体が動作を停止したためにアイドル状態に入ったときが、その一例である。この状態では、仮想化イベントがＶＣＰＵ１１２をウエイクアップさせるまで、ＶＭＭスケジューラ１４２は、ＶＣＰＵ１１２をブロック状態（ｂｌｏｃｋｅｄ ｓｔａｔｅ）としてもよい。ＶＣＰＵの利用を特定するために、ＶＣＰＵ１１２がブロック状態のままである時間を、Ｔｂｌｏｃｋｅｄと称してもよい。したがって、スケジューラ１４２は、ワークロードの特長をプロファイルとすることに利用するために、与えられたクオンタム及びブロックされたパラメータをプロファイリング・チャネル１３８に伝えてもよい。
【００２３】
ＶＣＰＵ１１２が単一のタイムスライスのその全てのクオンタムを消費してはならない他の状況は、ＶＣＰＵ１１２よりも、他の上位の優先するＶＣＰＵｓ１１２が優先されるときに発生しうる。この場合に、優先されていない（ｐｒｅｅｍｐｔｅｄ）ＶＣＰＵ１１２は、まだ作動できる状態（ｒｕｎａｂｌｅ）であるが、動作のキュー（ｒｕｎ ｑｕｅｕｅ）に止まっており、かつ、実際に継続中の意味あるジョブを持っている。また、ＶＣＰＵ１１２利用を特定するために、この優先されてしまった時間（ｐｒｅｅｍｐｔｅｄ ｔｉｍｅ）は、Ｔｓｔｏｌｅｎと称してもよい。そして、スケジューラ１４２は、横取りされた時間パラメータ（ｓｔｏｌｅｎ ｔｉｍｅ ｐａｒａｍｅｔｅｒ）をプロファイリング・チャネル１３８に転送してもよい。
【００２４】
これらの新しい要素を踏まえ、プロファイリング・チャネル１３８は、以下の通りにＶＣＰＵ１１２の利用を算出してもよい：
（Ｔｑｕａｎｔｕｍ−Ｔｓｔｏｌｅｎ−Ｔｂｌｏｃｋｅｄ）／（Ｔｑｕａｎｔｕｍ−Ｔｓｔｏｌｅｎ） （式２）
ＶＣＰＵ１１２の利用を決定する式（２）を用いることによって、ネイティブＯＳ環境のための周知の要求周波数制御アルゴリズムが利用されてもよい。ここでの差異は、（ＰＣＰＵ１０４利用の代わりに）ＶＣＰＵ１１２の利用は、ＤＢＳベースのアルゴリズム１４０の入力として提供されることである。ＶＣＰＵの利用を入力として、ＣＰＵ−ＤＢＳアルゴリズムは、低い利用度に対しては低い周波数をアウトプットし、またその逆も成り立つ。
【００２５】
ＣＰＵ−ＤＢＳアルゴリズムは、パフォーマンス、及びパワーセービングの間の最適バランスを提供しない場合がある。いくつかの場合では、より良好なバランスを担保するためには、現在のワークロードの特徴に関して、付加的な、あるいは異なる情報（ＶＣＰＵ１１２利用以外）のプロファイルを作ることによって達成されてもよい。仮想環境においては、仮想化の間、ワークロード特徴が推論され得る多くのヒントが生成される。より詳しくは、単一の物理マシン上の複数のＶＭを統合するために、ＶＭＭは、各々のＶＭから様々な形のセンシティブなアクションをインターセプトし、所望の挙動をエミュレートし、かつ非同期仮想割り込みを導入することを必要とする。この新規な仮想化レイヤーは、基本的なハードウェアプラットホーム上の動作と比較して、オーバーヘッドを仮想マシンに加える。しかしながら、この必然的なオーバーヘッドによって提供される豊富なヒントは、ワークロード特徴の推測を補助するために使用されてもよい。
【００２６】
例えば、入出力（Ｉ／Ｏ）の集中した特徴を有するワークロードは、エミュレートされた入出力デバイス上の入出力要求の頻度に基づいて、直ちに識別され得る。入出力デバイスがドライバ・レベルで、並列に仮想化（ｐａｒａ−ｖｉｒｔｕａｌｉｚｅｄ）されている場合、高度なドライバは、Ｉ／Ｏの集中したワークロードを示す統計を率先して提供することができる。別の例として、メモリ仮想化イベントは、メモリの集中したワークロードのインジケータであってもよい。例えば、ＶＭＭは、通常は、シャドウページテーブルを維持する。シャドウページテーブルは、ゲスト・ページテーブルから生成され、後者が変更されると後者と同期する。これは、ゲスト・ページテーブルがＰＣＰＵによって直接理解することができない仮想メモリアドレスを含むためである。ＶＭＭはゲスト・ページテーブルを読取り専用にマークしてもよい。ゲストがその現在のページテーブルを修正することを試みると、同期するＶＭＭのためにページフォルトが発生する。ＶＣＰＵがしばしばメモリを割り当てて、かつ開放する場合、この種のワークロードはこの種のページフォルトを示す統計に識別されてもよい。レイテンシに敏感なワークロードは、また、直ちに識別されてもよい。通常は、レイテンシに敏感なパターンは、複数の・タイマー、及び割り込みによって特徴づけられる。タイマー、及び割り込みのソースがＶＭＭによって仮想化されるので、ＶＭＭはレイテンシに敏感なワークロードを識別するためにそれらのイベントをトラッキングすることができる。
【００２７】
上で述べた仮想化イベントは、例示的なものであることが、理解されなければならない。そして、その他方式、及びイベント又はインジケータの組合せが、プロファイルの収集に使用されてもよく、そして、適切な制御アルゴリズムを選択するために、ワークロードの特徴を推論してもよい。さらに、ワークロード特徴のプロファイルを作ること、および推論することは、ＶＭＭの特定のインプリメンテーション、ハードウエア仮想化の特徴等の基本的な特長などに従い変化してもよい。ワークロード特徴を識別する特定の方法に関係なく、本発明の実施例は、図１において示されるＶＣＰＵに基づく制御・フレームワークに、それらの特徴を導入してもよい。これらのワークロードの特徴を使用することにより、そのワークロードを持つＶＣＰＵに割り当てられるＶＣＰＵインスタンスを拘束するために、特定の制御アルゴリズムが選択されてもよい。
【００２８】
以下の実施例は、ワークロード特徴に基づいて、制御アルゴリズムの複数の・タイプの選択ができることによって達成され得る利点を例示する。第１の実施例として、メモリの集中したワークロードは通常は多くのストールサイクルを有する。このように、この種のワークロードはパフォーマンスを失うことのない、より低い周波数クロックによって動作することができ、同時に、より低い周波数オペレーションはパワーセービングとなりうる。こうした状況では、ＣＰＵ−ＤＢＳアルゴリズムは良好な候補ではない。なぜなら、ＶＣＰＵがメモリの集中したワークロードの下で完全にサチュレートしており、そのため、ＣＰＵ−ＤＢＳアルゴリズムは高い周波数を計算する。その代わりに、メモリの集中したワークロードは、より低い周波数で動作させることができるという認識に基づいて、パワーセービングベースの制御アルゴリズムが選択されうる。したがって、チャネルプロファイリルを作ることによって収集されるデータが、メモリの集中したワークロードのヒントを示す場合、より低い周波数オペレーションとなるよう、電力セーブ・アルゴリズムが選択されてもよい。
【００２９】
別の例として、レイテンシに敏感なワークロードに対しては、ＶＣＰＵの低い利用を行ってもよい。したがって、ＣＰＵ−ＤＢＳアルゴリズムは、結果として低い周波数の選択となる。しかしながら、ＶＣＰＵがレイテンシに敏感なワークロードで動作するときは、それはすばやく入力イベントに反応することが可能でなければならない。低い周波数がレイテンシ（待ち時間）を増加させるため、ＣＰＵ−ＤＢＳアルゴリズムは適切でない。その代わりに、レイテンシに敏感なワークロードが、プロファイルが作られたインジケータから推論される場合、高い周波での動作を確実にするパフォーマンスベースの制御アルゴリズムが選択され得る。
【００３０】
ＣＰＵ−ＤＢＳアルゴリズムは、多くの適用範囲を更に有する。例えば、ほとんど仮想化イベントが検出されない場合、ＶＣＰＵの利用は、周波数の制御に対する適切な指標であり得る。
【００３１】
図３の例示的実施形態に示すように、各々のＶＢＦＶＳインスタンス１３６のためのチャネルプロファイル１３８は、さまざまな仮想化イベントソース（例えば仮想デバイス１４６のモデル、仮想マシン１４８間の通信、仮想割込コントローラ１５０、メモリに関連する仮想化イベントソース１５２、その他）からの情報を収集することによって、仮想化イベントのプロファイルを作る。加えて、プロファイリング・チャネル１３８は、ＶＣＰＵの割当クオンタム、失われた時間（ｓｔｏｌｅｎ ｔｉｍｅ）、ブロック化された時間、などを含むＶＣＰＵの利用に関し、スケジューラ１４２から情報を受信する。これらのさまざまなソースからの情報は、ＶＣＰＵ１１２がスケジュールインされたＶＣＰＵであるクオンタムの間、連続的に分析される。これによって、情報から認識されるワークロード特徴パターンに基づいて、ＶＦＢＶＳインスタンス１３６がそれ自体を特定の制御アルゴリズム１４０ａ−ｃに動的に拘束することができる。図３に示すように、利用できる制御アルゴリズムは、ＣＰＵ−ＤＢＳアルゴリズム１４０ａ、電力セーブ・アルゴリズム１４０ｂ、及びパフォーマンスベースのアルゴリズム１４０ｃ、等である。
【００３２】
ＶＣＰＵベースの制御は、本願明細書において記載されている具体例に限定されない。例えば、本発明の一実施例において、ＶＣＰＵベースの制御は、単にプロファイリング情報としてＶＣＰＵ周波数変動要求を使用し、ＶＢＦＶＳセンターに要求を渡すためのパススルー制御アルゴリズム、又は、要求を直接ＶＢＦＶＳセンターにルーティングすることを選択することによって、インプリメントされてもよい。実施例は、ソフトウェアコード（ＶＭＭ１１０、及びそのコンポーネントのいずれかを含む）でインプリメントされてもよく、かつ、システムが命令を実行するようにプログラムするために使用できる命令を記憶する記憶媒体に記憶されてもよい。記憶媒体は、ディスクを含むフロッピー（登録商標）ディスク、光ディスク、固体ドライブ、コンパクトディスク読取り専用メモリ、コンパクトディスク書き換え可能メモリ、及び光磁気ディスク、半導体デバイス例えば、読取り専用メモリ、ランダムアクセスメモリ、例えばダイナミック・ランダム・アクセス・メモリ、スタティックランダムアクセスメモリ、消去可能なプログラマブル・リードオンリーメモリ、フラッシュメモリ、電気的に消去可能なリードオンリーメモリ、磁気あるいは光学カード、その他、電子的命令を記憶することに適するあらゆるタイプのメディアが含まれる。もちろん、これらに限定されるものではない。ソフトウエアの命令は、プロセッサ（例えば図１のＰＣＰＵ１０４）での実行のためにロードされてもよい。
【００３３】
本発明が限定された数の実施例に関して記載されているが、当業者はそこから多数の修正変更を理解する。添付の請求項は、本発明の精神及び本発明の範囲に該当する全ての実施例およびバリエーションを含む
【符号の説明】
【００３４】
１００ 仮想化フレームワーク
１０２ ハードウェアプラットホーム
１１０ ＶＭＭ
１１８ ＶＭ
１２０ ＶＭ
【特許請求の範囲】
【請求項１】
複数の仮想処理デバイスの各々によって実行されるワークロードの特徴のプロファイルを作るステップと；
前記仮想処理デバイスのそれぞれのプロファイルが作られた特徴の関数として、仮想処理デバイスの各々のためのクロック周波数を決定するステップと；
を有する方法。
【請求項２】
前記クロック周波数を決定するステップは、仮想処理デバイスのための前記クロック周波数を決定するために制御アルゴリズムを選択するステップ、を含み、
前記選択は、前記仮想処理デバイスのための前記ワークロードの前記プロファイルが作られた特徴に基づく、
請求項１記載の方法。
【請求項３】
前記プロファイルを作るステップは、仮想処理デバイスがそのワークロードを実行している時間間隔の間、連続的に実行される、請求項１記載の方法。
【請求項４】
前記制御アルゴリズムの前記選択は、前記時間間隔の間、動的に実行される、請求項２記載の方法。
【請求項５】
前記制御アルゴリズムの前記選択は、前記仮想処理デバイスによって実行される前記ワークロードに関連づけられた仮想化イベントに基づく、請求項４記載の方法。
【請求項６】
前記プロファイルを作るステップは、前記仮想処理デバイスに関連づけられた仮想化イベントに基づく、請求項１記載の方法。
【請求項７】
前記プロファイルを作るステップは、動的に実行される、請求項６記載の方法。
【請求項８】
前記プロファイルを作るステップは、前記仮想処理デバイスの利用に基づく、請求項１記載の方法。
【請求項９】
プロセッサ資源と；
複数の仮想プロセッサへの前記プロセッサ資源の仮想化を管理する仮想マシンモニタと、を有し、
前記仮想マシンモニタは、それぞれのワークロードを実行するために、更に時間間隔を前記仮想プロセッサに割り当て、前記仮想マシンモニタは、更に対応する時間間隔の間、実行される前記ワークロードの特徴のプロファイルを作り、かつ、前記プロファイルが作られた特徴に基づき、前記仮想プロセッサの各々のためにクロック周波数を決定する、システム。
【請求項１０】
前記仮想マシンモニタは、対応する前記仮想プロセッサが前記ワークロードを実行している前記時間間隔の間に、連続的に前記ワークロードの特徴のプロファイルを作る、請求項９記載のシステム。
【請求項１１】
前記ワークロードの前記特徴は、仮想化イベントを含む、請求項１０記載のシステム。
【請求項１２】
前記ワークロードの前記特徴は、前記仮想プロセッサの利用を含む、請求項１１記載のシステム。
【請求項１３】
前記仮想マシンモニタは、更に前記クロック周波数を決定するために、制御アルゴリズムを選択し、前記仮想マシンモニタは、前記プロファイルが作られた特徴の関数として、前記制御アルゴリズムを選択する、請求項９記載のシステム。
【請求項１４】
前記仮想マシンモニタは、前記プロファイルが作られた特徴の関数として、制御アルゴリズムを選択する、請求項１３記載のシステム。
【請求項１５】
前記仮想マシンモニタは、前記対応する仮想プロセッサが前記ワークロードを実行している前記時間間隔の間、動的に制御アルゴリズムを選択する、請求項１４記載のシステム。
【請求項１６】
命令を記憶した計算機可読の媒体であって、処理デバイスによって実行されるときに、
複数の仮想処理デバイスの各々によって実行されるワークロードの特徴のプロファイルを作ることと；
前記仮想処理デバイスのそれぞれのプロファイルが作られた特徴の関数として、各々の仮想処理デバイスのためのクロック周波数を決定することと；
を前記処理デバイスに実行させる命令を記憶した媒体。
【請求項１７】
前記命令は、前記処理デバイスが、仮想処理デバイスのための前記クロック周波数を決定するために制御アルゴリズムを選択し、
前記選択は、その仮想処理デバイスのための前記ワークロードの前記プロファイルが作られた特徴に基づく、
請求項１６記載の媒体。
【請求項１８】
前記処理デバイスは、仮想処理デバイスがそのワークロードを実行している時間間隔の間、連続的にプロファイリングを作ることを実行する、請求項１６記載の媒体。
【請求項１９】
前記プロファイルを作ることは、前記仮想処理デバイスに関連づけられた仮想化イベントに基づく、請求項１６記載の媒体。
【請求項２０】
前記命令は、処理デバイスが、前記時間間隔の間、前記仮想化イベントのプロファイルを動的に作る、請求項１９記載の媒体。
【請求項１】
複数の仮想処理デバイスの各々によって実行されるワークロードの特徴のプロファイルを作るステップと；
前記仮想処理デバイスのそれぞれのプロファイルが作られた特徴の関数として、仮想処理デバイスの各々のためのクロック周波数を決定するステップと；
を有する方法。
【請求項２】
前記クロック周波数を決定するステップは、仮想処理デバイスのための前記クロック周波数を決定するために制御アルゴリズムを選択するステップ、を含み、
前記選択は、前記仮想処理デバイスのための前記ワークロードの前記プロファイルが作られた特徴に基づく、
請求項１記載の方法。
【請求項３】
前記プロファイルを作るステップは、仮想処理デバイスがそのワークロードを実行している時間間隔の間、連続的に実行される、請求項１記載の方法。
【請求項４】
前記制御アルゴリズムの前記選択は、前記時間間隔の間、動的に実行される、請求項２記載の方法。
【請求項５】
前記制御アルゴリズムの前記選択は、前記仮想処理デバイスによって実行される前記ワークロードに関連づけられた仮想化イベントに基づく、請求項４記載の方法。
【請求項６】
前記プロファイルを作るステップは、前記仮想処理デバイスに関連づけられた仮想化イベントに基づく、請求項１記載の方法。
【請求項７】
前記プロファイルを作るステップは、動的に実行される、請求項６記載の方法。
【請求項８】
前記プロファイルを作るステップは、前記仮想処理デバイスの利用に基づく、請求項１記載の方法。
【請求項９】
プロセッサ資源と；
複数の仮想プロセッサへの前記プロセッサ資源の仮想化を管理する仮想マシンモニタと、を有し、
前記仮想マシンモニタは、それぞれのワークロードを実行するために、更に時間間隔を前記仮想プロセッサに割り当て、前記仮想マシンモニタは、更に対応する時間間隔の間、実行される前記ワークロードの特徴のプロファイルを作り、かつ、前記プロファイルが作られた特徴に基づき、前記仮想プロセッサの各々のためにクロック周波数を決定する、システム。
【請求項１０】
前記仮想マシンモニタは、対応する前記仮想プロセッサが前記ワークロードを実行している前記時間間隔の間に、連続的に前記ワークロードの特徴のプロファイルを作る、請求項９記載のシステム。
【請求項１１】
前記ワークロードの前記特徴は、仮想化イベントを含む、請求項１０記載のシステム。
【請求項１２】
前記ワークロードの前記特徴は、前記仮想プロセッサの利用を含む、請求項１１記載のシステム。
【請求項１３】
前記仮想マシンモニタは、更に前記クロック周波数を決定するために、制御アルゴリズムを選択し、前記仮想マシンモニタは、前記プロファイルが作られた特徴の関数として、前記制御アルゴリズムを選択する、請求項９記載のシステム。
【請求項１４】
前記仮想マシンモニタは、前記プロファイルが作られた特徴の関数として、制御アルゴリズムを選択する、請求項１３記載のシステム。
【請求項１５】
前記仮想マシンモニタは、前記対応する仮想プロセッサが前記ワークロードを実行している前記時間間隔の間、動的に制御アルゴリズムを選択する、請求項１４記載のシステム。
【請求項１６】
命令を記憶した計算機可読の媒体であって、処理デバイスによって実行されるときに、
複数の仮想処理デバイスの各々によって実行されるワークロードの特徴のプロファイルを作ることと；
前記仮想処理デバイスのそれぞれのプロファイルが作られた特徴の関数として、各々の仮想処理デバイスのためのクロック周波数を決定することと；
を前記処理デバイスに実行させる命令を記憶した媒体。
【請求項１７】
前記命令は、前記処理デバイスが、仮想処理デバイスのための前記クロック周波数を決定するために制御アルゴリズムを選択し、
前記選択は、その仮想処理デバイスのための前記ワークロードの前記プロファイルが作られた特徴に基づく、
請求項１６記載の媒体。
【請求項１８】
前記処理デバイスは、仮想処理デバイスがそのワークロードを実行している時間間隔の間、連続的にプロファイリングを作ることを実行する、請求項１６記載の媒体。
【請求項１９】
前記プロファイルを作ることは、前記仮想処理デバイスに関連づけられた仮想化イベントに基づく、請求項１６記載の媒体。
【請求項２０】
前記命令は、処理デバイスが、前記時間間隔の間、前記仮想化イベントのプロファイルを動的に作る、請求項１９記載の媒体。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１１−１３４３３３（Ｐ２０１１−１３４３３３Ａ）
【公開日】平成２３年７月７日（２０１１．７．７）
【国際特許分類】
【出願番号】特願２０１０−２８４７９８（Ｐ２０１０−２８４７９８）
【出願日】平成２２年１２月２１日（２０１０．１２．２１）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
【公開日】平成２３年７月７日（２０１１．７．７）
【国際特許分類】
【出願日】平成２２年１２月２１日（２０１０．１２．２１）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
[ Back to top ]