JP2009110404A - 仮想計算機システム及び同システムにおけるゲストｏｓスケジューリング方法 - Google Patents

Abstract

【課題】ＣＰＵの動作周波数が低下しても、ゲストＯＳのリアルタイム処理性能を維持できるようにする。
【解決手段】ＶＭＭ（仮想計算機マネージャ）２０は、ＣＰＵ１１０を含むＨＷ１１を仮想化することによりＶＭ（仮想計算機）３０-0〜３０-4を構築する。ＶＭ３０-0〜３０-4上ではゲストＯＳ４０-0〜４０-4が実行される。ＣＰＵ周波数変化検出部２０４はＣＰＵ１１０の動作周波数の変化を検出する。ゲストＯＳスケジューラ２０１は、上記動作周波数の変化が検出され、且つ当該動作周波数が規定動作周波数から低下した場合、ゲストＯＳ４０-0〜４０-4のうちの特定ゲストＯＳが当該規定動作周波数での動作で必要とするＣＰＵ絶対処理量を維持するために、当該特定ゲストＯＳにＣＰＵ１１０が割り当てられるべき時間が増えるようにスケジューリングを行う。
【選択図】 図１

Description

本発明は、複数の仮想計算機が動作する仮想計算機システムに係り、特に当該複数の仮想計算機で実行される複数のゲストＯＳにＣＰＵを時分割で割り当てるためのスケジュールを管理するのに好適な仮想計算機システム及び同システムにおけるゲストＯＳスケジューリング方法に関する。

古くから、メインフレームにおいてハードウェア（ＨＷ）で構成された仮想計算機（Virtual Machine：ＶＭ）支援機構（仮想マシン支援機構）を用いた仮想計算機システムが存在する。また近年、パーソナルコンピュータ（ＰＣ）のＣＰＵ（プロセッサ）が同様の仮想マシン支援機構をＨＷでサポートしてきたこともあり、ＰＣの世界でも計算機の仮想化技術が活用されるようになってきている。そのため今後は、個人用のＰＣや、いわゆるＰＣサーバ等においても、仮想マシンの技術が広く利用されるようになることが予測される。

一般に、ＰＣのような計算機システム（物理計算機）は、ＣＰＵ（実ＣＰＵ）、各種の入出力（Ｉ／Ｏ）装置（実Ｉ／Ｏ装置）及びメモリ（実メモリ）を含むＨＷ（実ＨＷ）で構成されている。この実ＨＷで構成される物理計算機（物理環境）上に、仮想マシンマネージャ（Virtual Machine Manager：ＶＭＭ）が存在する。この仮想マシンマネージャ（仮想計算機マネージャ）の提供する仮想マシン実行環境のもとで複数のゲストＯＳが動作をする。

仮想マシンマネージャは仮想マシンモニタ（Virtual Machine Monitor：ＶＭＭ）とも呼ばれる。仮想マシンマネージャは上述の実ＨＷを直接管理し、それらを仮想化して仮想計算機（仮想マシン）を構築する。つまり仮想マシンマネージャは、実ＣＰＵ、実Ｉ／Ｏ装置及び実メモリのような物理資源（ＨＷ資源）を時間的、空間（領域）的に、仮想マシンのそれぞれ仮想ＣＰＵ、仮想Ｉ／Ｏ装置及び仮想メモリとして割り当てることによって、当該仮想マシンを構築（生成）する。各ゲストＯＳは仮想マシンにロードされて、当該仮想マシン内の仮想ＣＰＵによって実行される。

このように仮想マシンマネージャは、実ＣＰＵ、実Ｉ／Ｏ装置及び実メモリのような物理資源を各ゲストＯＳに割り当てる、いわゆるゲストＯＳスケジューリングによって、当該各ゲストＯＳが同時に動作できる環境を提供し、仮想計算機システムの管理を行う。つまり仮想計算機システムにおいては、目的に合わせてゲストＯＳを複数稼動させることができる。これは従来の非仮想計算機システムに比べて大きなメリットである。しかし、仮想計算機システムではＨＷ資源を複数のゲストＯＳで共有するため、特にリアルタイム（ＲＴ）処理の実現にはそれなりの考慮が必要である。

リアルタイム処理では、予め決められた時間内に特定の処理を終える等の時間的な制約がある。このため、リアルタイム処理を実現するには、ＯＳにリアルタイムＯＳ（ＲＴＯＳ）を使用するのが一般的である。リアルタイムＯＳは、当該ＯＳ上で実行されるアプリケーションプログラム（プロセス）に関してリアルタイム処理に適した実行優先度管理を行う。リアルタイムＯＳは当該ＯＳ自体もリアルタイム性を有するように実装されており、上述のアプリケーションプログラム（リアルタイムアプリケーション）に対するＣＰＵのディスパッチ処理の時間精度、割り込みに対する応答性などを保証する。リアルタイムＯＳ上では、上述のリアルタイム性が実現されていることを前提にアプリケーションプログラムが動作する。これにより、リアルタイムＯＳ上で動作するアプリケーションプログラムを、例えば時間制約の厳しい制御用途に使用することができる。

上述のようなリアルタイムＯＳ及びリアルタイム性を要求されるアプリケーションプログラムを仮想マシンで実行する場合を想定する。一般に仮想マシンでは、各ゲストＯＳにＣＰＵを時分割で割り当てて実行する。しかし、通常のリアルタイムＯＳ及び当該ＯＳ上で動作するリアルタイムアプリケーションプログラムは、その実行のために、ＣＰＵが常に割り当てられていることを前提として、時間管理や処理に要する時間の見積もりを行うのが普通である。

このようなリアルタイムＯＳ及び当該ＯＳ上で動作するアプリケーションプログラムを仮想マシン上で実行するためには、一定の周期で一定の時間だけ正確にＣＰＵを割り当ててればよい。この結果、単位時間当たりの処理量は一定となり、リアルタイム性の設計（見積もり）がしやすくなり、リアルタイムＯＳ及びアプリケーションプログラム実行時にリアルタイム性を実現することが可能になる。

非特許文献１乃至３には、仮想計算機システムにおける一般的なゲストＯＳスケジューリングに関する技術が記載されている。例えば、非特許文献１には、仮想マシンのＣＰＵのディスパッチに関する技術が記載されている。ここには、ＣＰＵ割り当て単位としての「タイム・スライス量子（Time Slice Quantum）」が記載されている。非特許文献１は、汎用計算機の仮想化技術としてのＣＰＵ割り当てポリシーを紹介しており、この中で、対話型ユーザ及び非対話型ユーザ等からの端末入力を考慮したＣＰＵ割り当て方式を開示している。非特許文献２及び３には、ＰＣ（パーソナルコンピュータ）でのオープンソースで開発されている仮想化ソフトウェア「Xen」のディスパッチャ及びスケジューリングに関する内容が記載されている。ここには、「sefdスケジューラ」と呼ばれているデッドラインベースのスケジューラポリシに関して記載されている。
岡崎世雄・全先実著，「ＯＳシリーズ１１ ＶＭ」，共立出版株式会社，１９８９年８月，ｐ．９７−１００ 高橋浩和，「仮想マシンモニター Xen3.0解読室 第３回 ドメインのスケジューリング（１）」，オープンソースマガジン，２００６年６月号，ソフトバンククリエイティブ株式会社，第１６１−１７０ページ 高橋浩和，「仮想マシンモニター Xen3.0解読室 第４回 ドメインのスケジューリング（２）」,オープンソースマガジン，２００６年７月号，ソフトバンククリエイティブ株式会社，第１４７−１５５ページ

上記非特許文献１乃至３には、複数のゲストＯＳに対するＣＰＵ割り当て方法（つまりゲストＯＳスケジューリング方法）の例が示されている。この非特許文献１乃至３に記載の従来のゲストＯＳスケジューリング方法は対象の仮想マシンの使用目的により様々である。しかし非特許文献１乃至３に記載のゲストＯＳスケジューリング方法は、仮想マシンマネージャのスケジューラ、或いはディスパッチャにより、複数のゲストＯＳにＣＰＵ時間を割り当てる点において共通する。

ところで、最近のＣＰＵは状況に応じて動作周波数が変化するように構成されている。代表的なケースとしては、例えば、ＣＰＵ、或いは当該ＣＰＵを含むシステム（計算機システム）の温度が異常に上昇した場合に、当該ＣＰＵ（或いは当該ＣＰＵを含むシステム）の動作周波数が自動的に下げられる。このように、ＣＰＵの動作周波数が下げられることにより、当該ＣＰＵ及びシステムの消費電力が低減して温度上昇を止めることが可能となる。また、ＣＰＵ（システム）の負荷が低いときにはＯＳのようなソフトウェア（ＳＷ）が例えば当該ＣＰＵの動作周波数を決定するＨＷに対して当該動作周波数を下げるように指示（設定）することにより、当該ＣＰＵ及びシステムの消費電力を低減して、無駄な電力消費を避けることが可能となる。勿論、温度が下がった場合には、自動的に或いはＳＷの指示により、ＣＰＵの動作周波数が元のレベルに戻される。同様に、負荷が増えた場合にも、ＳＷの指示によりＣＰＵの動作周波数が元のレベルに戻される。

このようにＣＰＵ（或いは当該ＣＰＵを含むシステム）の動作周波数が変化すると、当該ＣＰＵの処理能力も影響を受ける。例えばＣＰＵの動作周波数が下げられた場合には、一般的に当該ＣＰＵの処理能力が低下する。このように、ＣＰＵの動作周波数が変化する状況は、予め処理時間を見込んで、その通りに当該ＣＰＵが一定の能力で処理することを期待するリアルタイムＯＳ及び当該ＯＳ上で動作するリアルタイムアプリケーションプログラムにとっては非常に都合が悪い。即ちＣＰＵの動作周波数が変化すると処理時間の大きな誤差要因となるため、時間保証を伴ったリアルタイム処理が実現できなくなってしまう。これは仮想マシンだけの問題ではなく、広く計算機一般の問題である。

しかしながら、従来技術においては、ＣＰＵの動作周波数の変化とゲストＯＳのリアルタイム実行性の両方を考慮したゲストＯＳスケジューリングは存在しない。

本発明は上記事情を考慮してなされたものでその目的は、ＣＰＵの動作周波数が低下しても、ゲストＯＳに割り当てるＣＰＵ時間を増加することにより、当該ゲストＯＳのリアルタイム処理性能を維持できる仮想計算機システム及び同システムにおけるゲストＯＳスケジューリング方法を提供することにある。

本発明の１つの観点によれば、ＣＰＵを含むハードウェアと、温度を含む動作環境の変動に応じて前記ＣＰＵの動作周波数を変化させる動作周波数可変手段と、前記ハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを実行させるための管理を行う仮想計算機マネージャとを具備する仮想計算機システムが提供される。このシステムにおいて、前記仮想計算機マネージャは、前記動作周波数の変化を検出するための動作周波数変化検出手段と、前記複数のゲストＯＳに前記ＣＰＵを時分割で割り当てるためのスケジュールを管理するスケジューラであって、前記動作周波数変化検出手段によって前記動作周波数の変化が検出され、且つ当該動作周波数が予め定められた規定動作周波数から低下した場合、前記複数のゲストＯＳのうちの予め定められた特定ゲストＯＳが当該規定動作周波数で必要とする前記ＣＰＵの処理能力であるＣＰＵ絶対処理量を維持するために、当該特定ゲストＯＳに前記ＣＰＵが割り当てられるべき時間（つまりＣＰＵ時間）が増えるように前記スケジュールを調整するスケジューラと、前記スケジューラによって管理される前記スケジュールに従って前記複数のゲストＯＳに前記ＣＰＵを時分割で割り当てるディスパッチャとを含む。ここで、スケジューラによるスケジュールの調整では、動作周波数の規定動作周波数からの低下分を相殺するように、特定ゲストＯＳに割り当てられるべきＣＰＵ時間を増やすとよい。

本発明によれば、ＣＰＵの動作周波数が変化した場合、特に当該動作周波数が規定動作周波数よりも低下した場合に、特定ゲストＯＳが当該規定動作周波数での動作で必要とするＣＰＵ絶対処理量（ＣＰＵの処理能力）を維持するために、当該特定ゲストＯＳに割り当てられるべきＣＰＵ時間が増えるようにスケジューリングされる。これにより、温度変化等の要因によりＣＰＵの動作周波数が規定動作周波数よりも低下しても、少なくとも特定ＯＳに関しては、リアルタイム性を保証することができ、仮想計算機の組み込み用途などへの応用の可能性を広げることができる。

以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る仮想計算機システム（ＶＭシステム）１の構成を示すブロック図である。図１に示す仮想計算機システム１は、物理計算機１０を用いて実現される。物理計算機（実計算機）１０は、仮想計算機（仮想マシン）の実行環境を提供するハードウェア（ＨＷ）１１を備えている。ＨＷ１１は、ＣＰＵ（実ＣＰＵ）１１０、更には図示せぬＩ／Ｏ（入出力）装置（実Ｉ／Ｏ装置）及びメモリ（実メモリ）を含む。

物理計算機１０のＨＷ１１上では、仮想マシン（仮想計算機）マネージャ（Virtual Machine Manager：ＶＭＭ）２０が動作する。ＶＭＭ２０は、仮想計算機システム１の管理を行い、仮想マシン（Virtual Machine：ＶＭ）が動作する環境（仮想マシン実行環境）を提供する。更に具体的に述べるならば、ＶＭＭ２０は、物理計算機１０のＨＷ１１を構成する物理資源（ＣＰＵ１１０を含む物理資源）を管理すると共に当該物理資源の時間的、領域的な配分を管理することにより、複数の仮想マシン、例えば５台の仮想マシン（ＶＭ）３０-0，３０-1，３０-2，３０-3及び３０-4が動作する仮想マシン実行環境を提供する。ＶＭ３０-0〜３０-4は何れも、ＶＭＭ２０が、物理計算機１のＨＷ１１を構成する物理資源（ＣＰＵ１１０を含む物理資源）を、時間的、領域的に割り当てることにより構築される。

ＶＭ３０-0，３０-1，３０-2，３０-3及び３０-4上では、それぞれゲストＯＳ４０-0（＃０），４０-1（＃１），４０-2（＃２），４０-3（＃３）及び４０-4（＃４）が動作する。更に具体的に述べるならば、ゲストＯＳ４０-0〜４０-4は、それぞれＶＭ３０-0〜３０-4にロードされて、当該ＶＭ３０-0〜３０-4内の仮想ＣＰＵによって実行される。ゲストＯＳ４０-0〜４０-4には、それぞれゲストＯＳ番号０〜４が割り当てられている。

ＶＭＭ２０は、ゲストＯＳスケジューラ２０１、ゲストＯＳ管理テーブル２０２、ディスパッチャ２０３、ＣＰＵ周波数変化検出部２０４及びＣＰＵ周波数変更部２０５を含む。

ゲストＯＳスケジューラ２０１は、適切なタイミングで起動され、ＶＭＭ２０が管理する全てのゲストＯＳ（ここではゲストＯＳ４０-0〜４０-4）の各々にどの程度の時間の割合でＣＰＵ１１０を割り当てるかを計算し決定するモジュールである。本実施形態において、上記適切なタイミングとは、後述する要因１または２のいずれかが発生した場合である。

ゲストＯＳ管理テーブル２０２は、ゲストＯＳスケジューラ２０１によって決定された、ゲストＯＳ毎にＣＰＵ１１０が割り当てられるべき時間（ＣＰＵ時間）の割合（ＣＰＵ割り当て率）を保持するのに用いられる。このゲストＯＳスケジューラ２０１によって決定されたゲストＯＳ毎のＣＰＵ割り当て率を、「現在の割当量」と称する。ゲストＯＳ管理テーブル２０２は更に、ＣＰＵ１１０（を含むＨＷ１１）が規定の動作周波数（規定ＣＰＵ周波数）で動作する場合に各ゲストＯＳのリアルタイム性能を保証するのに必要な当該ゲストＯＳ毎のＣＰＵ割り当て率（以下、「ＣＰＵ絶対処理量」と称する）を保持するのに用いられる。

図２はゲストＯＳ管理テーブル２０２の一例を示す。図２のゲストＯＳ管理テーブル２０２には、ゲストＯＳ番号がそれぞれ０，１，２，３及び４のゲストＯＳに対応付けて、当該ゲストＯＳ、即ちゲストＯＳ４０-0（＃０），４０-1（＃１），４０-2（＃２），４０-3（＃３）及び４０-4（＃４）にＣＰＵ１１０を割り当てる割合であるＣＰＵ割り当て比率４０％，３０％，２０％，５％及び５％を示す情報が、「現在の割当量」として保持されている。また図２のゲストＯＳ管理テーブル２０２には、ゲストＯＳ４０-0（＃０），４０-1（＃１），４０-2（＃２），４０-3（＃３）及び４０-4（＃４）に対応付けて、そのゲストＯＳの「ＣＰＵ絶対処理量」として、それぞれ２０％，１５％，１０％，０％及び０％を示す情報が保持されている。

再び図１を参照すると、ディスパッチャ２０３は、ゲストＯＳ管理テーブル２０２に保持されているゲストＯＳ毎の「現在の割当量」（つまりゲストＯＳ管理テーブル２０２の示すスケジュール）に従って、各ゲストＯＳに実際にＣＰＵ１１０を割り当てるディスパッチ処理を行う。図２のゲストＯＳ管理テーブル２０２の例であれば、ディスパッチャ２０３は、ゲストＯＳ４０-0（＃０），４０-1（＃１），４０-2（＃２），４０-3（＃３）及び４０-4（＃４）に対して、ＣＰＵ１１０をそれぞれ４０％，３０％，２０％，５％及び５％の割合で時分割で割り当てる。

図３はディスパッチャ２０３によるディスパッチの例を示す。図３において、横軸は時間の経過を示す。

本実施形態において、ゲストＯＳにＣＰＵ１１０を割り当てる時間単位は一定である。この時間単位を「クォンタム」と呼び「τ」で示す。図３には、図２のゲストＯＳ管理テーブル２０２に従い、ゲストＯＳ番号が２のゲストＯＳ４０-2（＃２）に対してＣＰＵ１１０を２０％の割合で割り当てる例が示されている。ここではディスパッチャ２０３が、５τ毎に１τだけゲストＯＳ４０-2（＃２）をディスパッチすることで、上記の比率（ＣＰＵ割り当て比率）２０％を実現している。このようなディスパッチャ２０３によるディスパッチは、ゲストＯＳ４０-2（＃２）以外のゲストＯＳに対しても同様に行われる。つまり本実施形態では、時間（時間単位）τ毎にＶＭＭ２０内のディスパッチャ２０３に制御が渡り、次の時間（クォンタム）にＣＰＵ１１０を割り当てるべきゲストＯＳを選択する処理が繰り返される。

本実施形態において、ＨＷ１１は、当該ＨＷ１１の温度（つまり、ＣＰＵ１１０を含むＨＷ１１の動作環境の１つである温度）が上昇した際にＣＰＵ１１０の動作周波数（ＣＰＵ周波数）を自動的に下げる周知のＣＰＵ周波数自動調整機能を有している。ＶＭＭ２０内のＣＰＵ周波数変化検出部２０４は、このＨＷ１１の機能によりＣＰＵ周波数が変化させられたことを検出する。ここではＣＰＵ周波数変化検出部２０４は、ＣＰＵ周波数の変化（現在のＣＰＵ周波数）を、ＨＷ１１内の後述するＣＰＵ周波数変化通知部１１１からの通知により検出する。

ＣＰＵ周波数変更部２０５は、ＣＰＵ周波数を変更する。ここではＣＰＵ周波数変更部２０５は、ＨＷ１１内の後述するＣＰＵ周波数設定部１１２に所望のＣＰＵ周波数を設定することにより、ＣＰＵ周波数を変更操作する。

ＨＷ１１は、ＣＰＵ周波数変化通知部１１１及びＣＰＵ周波数設定部１１２を含む。ＣＰＵ周波数変化通知部１１１は、ＨＷ１１のＣＰＵ周波数自動調整機能によりＣＰＵ周波数が変化した場合に、その際のＣＰＵ周波数をＣＰＵ周波数変化検出部２０４に通知する。ここではＣＰＵ周波数変化通知部１１１は、ＣＰＵ周波数の変化を割り込みによりＣＰＵ周波数変化検出部２０４に通知する。ＣＰＵ周波数変化通知部１１１は、この割り込みを受けたＣＰＵ周波数変化検出部２０４からの問い合わせに対して、現在のＣＰＵ周波数を当該ＣＰＵ周波数変化検出部２０４に通知する。また、ＣＰＵ周波数変化通知部１１１は、ＣＰＵ周波数の変化に無関係に、つまりＣＰＵ周波数変化検出部２０４への割り込みに無関係に、当該ＣＰＵ周波数変化検出部２０４からの問い合わせに対して現在のＣＰＵ周波数を当該ＣＰＵ周波数変化検出部２０４に通知する。

ＣＰＵ周波数設定部１１２は、ＣＰＵ周波数変更部２０５によって所望のＣＰＵ周波数を設定するのに用いられる。ＣＰＵ周波数設定部１１２は、例えばＣＰＵ周波数変更部２０５からアクセス可能なレジスタである。ＣＰＵ周波数設定部１１２にＣＰＵ周波数が設定されることにより、ＣＰＵ１１０（を含むＨＷ１１）を当該設定されたＣＰＵ周波数で動作させることができる。なお、ＣＰＵ周波数変化通知部１１１及びＣＰＵ周波数設定部１１２がＣＰＵ１１０に内蔵されていても構わない。

次に本実施形態における動作について説明する。
本実施形態において、予めリアルタイム処理を行う必要がある特定ゲストＯＳ４０-i（＃ｉ）（ｉは０〜４のいずれか）は、ＶＭＭ２０に対する専用のシステムコールを使って、自身に割り当てられるべき「ＣＰＵ絶対処理量」を当該ＶＭＭ２０に要求する。そのため本実施形態では、
VMM_set_cpu_absolute_time(Cpu_Time_Rate);
のような、インターフェイス（インターフェイス関数）呼び出しのためのシステムコールが用意されている。ゲストＯＳ４０-iがインターフェイス関数を呼び出すとＶＭＭ２０に対するシステムコールが発生する。

前記したように、「ＣＰＵ絶対処理量」は、規定ＣＰＵ周波数での動作でゲストＯＳ４０-iのリアルタイム性能を保証するのに必要なＣＰＵ割り当て率（％）、つまりゲストＯＳ４０-iが規定ＣＰＵ周波数での動作で必要とするＣＰＵ割り当て率（％）として定義される。例えば、規定ＣＰＵ周波数（つまり通常時のＣＰＵ周波数）が１ＧＨｚであった場合、ゲストＯＳ４０-iがリアルタイム性能の保証のために、１ＧＨｚ動作時の単位時間当たりＣＰＵ処理能力の２０％相当の処理量を「ＣＰＵ絶対処理量」として確保したいときには、
VMM_set_cpu_absolute_time(20);
のように、このインターフェイスを呼び出すことにより、当該「ＣＰＵ絶対処理量」の割り当てを要求する。ゲストＯＳスケジューラ２０１は、このインタフェースの機能を有する。

ゲストＯＳスケジューラ２０１のインタフェースは上述のインターフェイス関数を用いたゲストＯＳ４０-iからのシステムコールにより呼び出されると、当該インターフェイス関数の引数で示される「ＣＰＵ絶対処理量」（ここでは２０％）の割り当ての要求を受け付ける。するとゲストＯＳスケジューラ２０１は、上記引数で示される「ＣＰＵ絶対処理量」をゲストＯＳ４０-i（のゲストＯＳ番号ｉ）に対応付けてゲストＯＳ管理テーブル２０２に登録する。以後、ＣＰＵ周波数が変化したときには、ゲストＯＳスケジューラ２０１はゲストＯＳ管理テーブル２０２に従い、規定ＣＰＵ周波数で動作時の２０％の処理能力に相当するＣＰＵ処理量（つまりＣＰＵ周波数の変化分を相殺するＣＰＵ処理量）となるようなＣＰＵ割り当て比率（現在の割当量）で、ＣＰＵ１１０をゲストＯＳ４０-iに割り当てる。

なお、上述のインターフェイス関数の呼び出し（システムコール）を実行していないゲストＯＳ、即ち「ＣＰＵ絶対処理量」を要求しないゲストＯＳ（非要求ゲストＯＳ、非特定ゲストＯＳ）に関しては、「ＣＰＵ絶対処理量」を要求したゲストＯＳ（要求ゲストＯＳ、特定ゲストＯＳ）に対してＣＰＵ処理量を割り当てた後の残ったＣＰＵ処理量を当該非要求ゲストＯＳに等分して割り当てるものとする。ゲストＯＳ管理テーブル２０２においては、非要求ゲストＯＳの絶対ＣＰＵ処理量の欄には（デフォルト値として）０がセットされる。

図２のゲストＯＳ管理テーブル２０２の例では、ゲストＯＳ番号がそれぞれ０，１及び２のゲストＯＳ４０-0，４０-1及び４０-2が要求ゲストＯＳ（特定ゲストＯＳ）であり、ゲストＯＳ番号がそれぞれ３及び４のゲストＯＳ４０-3及び４０-4が非要求ゲストＯＳ（非特定ゲストＯＳ）である。この例では、ゲストＯＳ４０-0，４０-1及び４０-2には、それぞれ規定ＣＰＵ周波数で動作時の２０％，１５％及び１０％の処理能力に相当するＣＰＵ処理量となるようなＣＰＵ割り当て比率（現在の割当量）４０％，３０％及び２０％で、ＣＰＵ１１０が割り当てられる。この場合、残りのＣＰＵ処理量は、（１００−（４０＋３０＋２０））％、即ち１０％である。このため、ゲストＯＳ４０-3及び４０-4には、この１０％を２等分して、それぞれ５％のＣＰＵ割り当て比率（現在の割当量）でＣＰＵ１１０が割り当てられる。

次に、本実施形態においてＣＰＵ周波数が変化したときのスケジューリング処理について、図４のフローチャートを参照して説明する。
図４のフローチャートに従うスケジューリング処理は、例えば、
１）温度上昇などが原因でＣＰＵ周波数が自動的に低下してＨＷ１１内のＣＰＵ周波数変化通知部１１１が働いた結果、ＶＭＭ２０（内のＣＰＵ周波数変化検出部２０４）が当該ＣＰＵ周波数変化通知部１１１から割り込み（ＣＰＵ周波数変更通知割り込み）を受けた場合（要因１）
２）システム負荷が低下したとＶＭＭ２０が判断することにより、或いはユーザの指示によりＶＭＭ２０内のＣＰＵ周波数変更部２０５がＨＷ１１内のＣＰＵ周波数設定部１１２を操作することによってＣＰＵ周波数を低下させる場合（要因２）
のいずれかのケースに行われる。

このような要因によりＣＰＵ周波数が変化する場合、ＶＭＭ２０内のゲストＯＳスケジューラ２０１は、ゲストＯＳ管理テーブル２０２で「ＣＰＵ絶対処理量」が０でない要求ゲストＯＳ（図２の例では、ゲストＯＳ４０-0，４０-1及び４０-2）、及び「ＣＰＵ絶対処理量」が０の非要求ゲストＯＳ（図２の例では、ゲストＯＳ４０-3及び４０-4）に対して、図４のフローチャートに従ったスケジューリング処理を次のように行う。

まずゲストＯＳスケジューラ２０１は、ＣＰＵ周波数変化検出部２０４を用いて現在のＣＰＵ周波数をＨＷ１１内のＣＰＵ周波数変化通知部１１１に問い合わせさせ、その値を変数Ｆｃとして設定する（ステップＳ１）。次にゲストＯＳスケジューラ２０１は、「ＣＰＵ絶対処理量」を保証する要求ゲストＯＳ（以下、第１のタイプのゲストＯＳと称する）の集合の中に未処理（ＣＰＵ処理量が未割り当て）のゲストＯＳが存在するかを判定する（ステップＳ２）。本実施形態において、第１のタイプのゲストＯＳは、ゲストＯＳ管理テーブル２０２において、「ＣＰＵ絶対処理量」として０以外の値が設定されているゲストＯＳ（要求ゲストＯＳ）である。したがってゲストＯＳスケジューラ２０１は、ゲストＯＳ管理テーブル２０２を参照することにより第１のタイプのゲストＯＳ（「ＣＰＵ絶対処理量」を保証するゲストＯＳ）と「ＣＰＵ絶対処理量」を保証する必要のないゲストＯＳ（以下、第２のタイプのゲストＯＳと称する）とを識別することができる。

未処理の第１のタイプのゲストＯＳが存在するならば（ステップＳ２）、ゲストＯＳスケジューラ２０１は、その中の１つを選択し、ＧＯＳｉとして設定する（ステップＳ３）。次にゲストＯＳスケジューラ２０１は、ゲストＯＳ管理テーブル２０２においてＧＯＳｉに対応付けて登録されている「ＣＰＵ絶対処理量」、即ち当該ＧＯＳｉに対して定められている、当該ＧＯＳｉが必要とする「ＣＰＵ絶対処理量」をＲｓ（％）として設定する（ステップＳ４）。明らかなように、Ｒｓは、規定ＣＰＵ周波数をＦｓとすると、ＧＯＳｉが必要とする、当該Ｆｓにおける単位時間当たりのＣＰＵ割り当て率を示す。

次にゲストＯＳスケジューラ２０１は、現在のＣＰＵ周波数ＦｃにおいてＧＯＳｉが必要とするＣＰＵ処理量Ｒｎｏｗを、次式
Ｒｎｏｗ＝Ｒｓ×（Ｆｓ／Ｆｃ） ……（１）
により算出する（ステップＳ５）。つまりゲストＯＳスケジューラ２０１は、ＧＯＳｉに対して定められているＣＰＵ絶対処理量Ｒｓ、現在のＣＰＵ周波数Ｆｃ及び規定ＣＰＵ周波数Ｆｓに基づき、現在のＣＰＵ周波数ＦｃにおいてＧＯＳｉが必要とするＣＰＵ処理量Ｒｎｏｗ（つまり、規定ＣＰＵ周波数Ｆｓに対する現在のＣＰＵ周波数Ｆｃの低下分を相殺するためのＣＰＵ処理量Ｒｎｏｗ）を算出する。

ゲストＯＳスケジューラ２０１は、算出されたＣＰＵ処理量Ｒｎｏｗを、ゲストＯＳ管理テーブル２０２のＧＯＳｉに対応付けられている現在の割り当て量の欄に登録する（ステップＳ６）。つまりゲストＯＳスケジューラ２０１は、ゲストＯＳ管理テーブル２０２においてＧＯＳｉに対応付けられている現在の割り当て量の欄の値を、算出されたＣＰＵ処理量Ｒｎｏｗに更新する。

上記（１）式では、現在のＣＰＵ処理量Ｒｎｏｗが、ＣＰＵ周波数の変化に反比例する値として算出される。例えば、現在のＣＰＵ周波数Ｆｃが規定ＣＰＵ周波数Ｆｓの１／２になれば、（１）式に従って算出されるＣＰＵ処理割当量Ｒｎｏｗは２倍になる。図２のゲストＯＳ管理テーブル２０２には、ＣＰＵ周波数Ｆｃが規定ＣＰＵ周波数Ｆｓの半分になった（１ＧＨｚ→５００ＭＨｚ）場合の「現在の割当量」が示されている。

ゲストＯＳスケジューラ２０１は、以上の処理を、未処理の第１のタイプのゲストＯＳがなくなるまで繰り返す（ステップＳ２）。そして、未処理の第１のタイプのゲストＯＳがなくなったなら（ステップＳ２）、ゲストＯＳスケジューラ２０１はステップＳ７に進む。ステップＳ７において、ゲストＯＳスケジューラ２０１は全ての第１のタイプのゲストＯＳに割り当てられたＣＰＵ処理量（現在の割当量）Ｒｎｏｗの総和ΣＲｎｏｗ（％）を１００％から差し引いた、残りのＣＰＵ処理量（ＣＰＵ時間）を未割り当て時間（単位は％）として算出する。次にゲストＯＳスケジューラ２０１は、算出された未割り当て時間を第２のタイプのゲストＯＳの数で等分して、当該第２のタイプのゲストＯＳに割り当てる（ステップＳ８）。つまりゲストＯＳスケジューラ２０１は、未割り当て時間を全ての第２のタイプのゲストＯＳに均等に割り当てる。ステップＳ８において、ゲストＯＳスケジューラ２０１は、等分された未割り当て時間（ＣＰＵ処理量）を、ゲストＯＳ管理テーブル２０２において各第２のタイプのゲストＯＳに対応付けられている現在の割り当て量の欄に登録する。つまりゲストＯＳスケジューラ２０１は、ゲストＯＳ管理テーブル２０２において各第２のタイプのゲストＯＳに対応付けられている現在の割り当て量の欄の値を、等分された未割り当て時間（ＣＰＵ処理量）に更新する。ゲストＯＳスケジューラ２０１はステップＳ８を実行すると、スケジューリング処理を終了する。

以後、ディスパッチャ２０３は、ＣＰＵ周波数の変化に応じて更新されたゲストＯＳ管理テーブル２０２にゲストＯＳ４０-0〜４０-4に対応付けて登録されている最新の「現在の割当量」に従って、当該ゲストＯＳ４０-0〜４０-4にＣＰＵ１１０を割り当てるディスパッチ処理を行う。これにより、上述のようにＣＰＵ周波数が低下した場合には、その低下分を補うＣＰＵ時間を第１のタイプのゲストＯＳ（図２の例では、ゲストＯＳ４０-0〜４０-2）に割り当てられる。この結果、ＣＰＵ周波数が低下しても、第１のタイプのゲストＯＳ（ゲストＯＳ４０-0〜４０-2）の単位時間当たりの処理量が一定になるように保証され、当該第１のタイプのゲストＯＳのリアルタイム処理性能が維持される。

［第１の変形例］
上記実施形態によれば、ＣＰＵ周波数が規定ＣＰＵ周波数の例えば１／２に低下した場合には、第１のタイプのゲストＯＳに対して、単位時間当たりのＣＰＵ処理量（ＣＰＵ割り当て比率）を２倍に増やすことにより、当該第１のタイプのゲストＯＳの実行効率は影響を受けないで済む。しかしながら、第２のタイプのゲストＯＳに関しては、第１のタイプのゲストＯＳに割り当てるＣＰＵ処理量を増やした分、割り当てることができるＣＰＵ処理量（ＣＰＵ時間）が少なくなる。これについて具体例を挙げて説明する。

図５は、現在のＣＰＵ周波数が規定周波数に一致する場合のゲストＯＳ管理テーブル２０２の一例を示す。この例では、第１のタイプのゲストＯＳ４０-0，４０-1及び４０-2に割り当てられる「現在の割当量」は、図５に示されるように、それぞれ「ＣＰＵ絶対処理量」である２０％，１５％及び１０％に一致する。この場合、第１のタイプのゲストＯＳ４０-0，４０-1及び４０-2に割り当てられる「現在の割当量」の総量は４５％であり、残りのＣＰＵ処理量（余ったＣＰＵ処理量）は５５％となる。この５５％が、第２のタイプのゲストＯＳ４０-3及び４０-4に均等に割り当てられる。これにより、第２のタイプのゲストＯＳ４０-3及び４０-4にそれぞれ割り当てられる「現在の割当量」は、図５に示されるように、５５％の１／２である２７．５％となる。

ところが、ＣＰＵ周波数が規定ＣＰＵ周波数の１／２となったために、第１のタイプのゲストＯＳ４０-0，４０-1及び４０-2に割り当てられる「現在の割当量」を図５の状態から図２の例のように２倍に増やした場合、第２のタイプのゲストＯＳ４０-3及び４０-4に割り当てられるＣＰＵ処理量（ＣＰＵ時間）は２７．５％から５％に低減する。この２７．５％から５％への変化は、第２のタイプのゲストＯＳ４０-3及び４０-4に単位時間当たりに割り当てられるクォンタムの個数が、その変化率に比例して減ること、つまり５／２７．５に減ることを意味する。この結果、第２のタイプのゲストＯＳ４０-3及び４０-4に関しては、ディスパッチ機会が少なくなり応答時間の悪化を引き起こしてしまう。

そこで、ＣＰＵ周波数が低下しても、第１のタイプのゲストＯＳの単位時間当たりの処理量が一定になるように保証しつつ、第２のタイプのゲストＯＳのディスパッチ回数の減少を抑えることができる、上記実施形態の第１の変形例について説明する。第１の変形例が上記実施形態と相違するのは、スケジューリング処理である。

この第１の変形例におけるスケジューリング処理について、図６のフローチャートを参照して、図４のフローチャートと相違する点を中心に説明する。なお、図６のフローチャートにおいて、図４と同様のステップには同一参照符号を付してある。

図６のフローチャートが図４のフローチャートと相違する点は、ステップＳ９が追加されたことにある。このステップＳ９において、ゲストＯＳスケジューラ２０１は、規定ＣＰＵ周波数Ｆｓに対するＣＰＵ周波数Ｆｃの割合、つまりＦｃ／Ｆｓで、ゲストＯＳにＣＰＵ時間を割り当てる単位であるクォンタムを変化させる。規定ＣＰＵ周波数におけるクォンタムの値（時間）をτ、変化後の新しいクォンタムの値をτ’で表すと、新しいクォンタムの値τ’は、次式
τ’＝τ×（Ｆｃ／Ｆｓ） ……（２）
により算出される。

したがって、ＣＰＵ周波数が規定ＣＰＵ周波数の例えば半分になった（１ＧＨｚ→５００ＭＨｚ）場合には、上記（２）式は
τ’＝τ×（５００ＭＨｚ／１ＧＨｚ）
＝０．５τ
となり、クォンタムの値は半分になる。

このように第１の変形例においては、ＣＰＵ周波数の低下に応じて、例えば規定ＣＰＵ周波数Ｆｓに対するＣＰＵ周波数Ｆｃの割合に応じて、クォンタムの値を低減している。これにより、上述のように第２のタイプのゲストＯＳ４０-3及び４０-4に割り当てられるＣＰＵ処理量（ＣＰＵ時間）は低減しても、ディスパッチ回数の減少を抑えることができる。

ＣＰＵ周波数Ｆｃが規定ＣＰＵ周波数Ｆｓの１／２となった上記の例では、クォンタムの値は、τから（τ’＝）０．５τのように１／２となる。この結果、単位時間当たりのクォンタムの数のＣＰＵ周波数の変化前のそれに対する比率は、上記実施形態と比較して２倍となる。具体的には、第２のタイプのゲストＯＳ４０-3及び４０-4に割り当てられるＣＰＵ時間が上述のように２７．５％から５％に低減した場合、上記比率は、５／２７．５から（５／２７．５）×２＝１０／２７．５となる。これにより、第２のタイプのゲストＯＳ４０-3及び４０-4のディスパッチ回数の減少を抑えることができ、当該ゲストＯＳ４０-3及び４０-4の応答性悪化を緩和することができる。

上述の第１の変形例では、クォンタムの値を規定ＣＰＵ周波数Ｆｓに対するＣＰＵ周波数Ｆｃの割合に比例するように変えている。しかし、ＣＰＵ周波数が規定ＣＰＵ周波数に一致する場合に第２のタイプのゲストＯＳに割り当てられる「現在の割当量」を第１の割当量と呼び、ＣＰＵ周波数が規定ＣＰＵ周波数よりも低下した場合に当該第２のタイプのゲストＯＳに割り当てられる「現在の割当量」を第２の割当量と呼ぶならば、クォンタムの値を、第１の割当量に対する第２の割当量の割合に比例するように変えても良い。このようにすると、第２のタイプのゲストＯＳ（上記の例では、ゲストＯＳ４０-3及び４０-4）に関して、単位時間当たりのクォンタムの個数が減るのを完全に防止できる。但し、クォンタムの値を小さくし過ぎるとゲストＯＳ切り替えのオーバヘッドが増えて性能が悪化する可能性もある。そこで、クォンタムの値の下限値を予め定めておき、クォンタムの値が当該下限値より小さな値に設定されないようにすると良い。

図７は、第２のタイプのゲストＯＳ、例えばゲストＯＳ４０-3（＃３）に対するディスパッチの様子を示し。図７（ａ）は図５のゲストＯＳ管理テーブル２０２で示される割当状況におけるゲストＯＳ４０-3（＃３）へのＣＰＵディスパッチの様子を示す。ここでは、単位時間を１秒、クォンタムの値を５ｍｓ（τ＝５ｍｓ）とすると、当該単位時間当たり５５個のクォンタムτ（つまり、単位時間当たりのクォンタムの総数２００個の２７，５％）がゲストＯＳ４０-3（＃３）に割り当てられる。

図７（ａ）の状態で、クォンタムの値そのままで（つまりτ＝５ｍｓ）、ＣＰＵ周波数が半分になった状態、つまり図２のゲストＯＳ管理テーブル２０２で示される割当状況におけるゲストＯＳ４０-3（＃３）へのＣＰＵディスパッチの様子を図７（ｂ）に示す。ここでは、ゲストＯＳ４０-3（＃３）に対する「現在の割当量」は５％なので、単位時間（１秒）当たり１０個のクォンタムτが当該ゲストＯＳ４０-3（＃３）に割り当てられている。この状況では、明らかにゲストＯＳ４０-3（＃３）へのＣＰＵ割当回数が少なくなっている。この場合、ゲストＯＳ４０-3（＃３）の応答性は悪くなる。

そこで、上記第１の変形例のように、クォンタムの値を規定ＣＰＵ周波数Ｆｓに対するＣＰＵ周波数Ｆｃの割合で変更する。ＣＰＵ周波数Ｆｃが規定ＣＰＵ周波数Ｆｓの半分になった（１ＧＨｚ→５００ＭＨｚ）例では、新しいクォンタムの値は、５ｍｓから２．５ｍｓ（τ＝２．５ｍｓ）となる。なお、ここでは便宜的に、新しいクォンタムの値もτで表している。

図２のゲストＯＳ管理テーブル２０２で示される割当状況で、クォンタムの値が２．５ｍｓに変更された場合のゲストＯＳ４０-3（＃３）へのＣＰＵディスパッチの様子を図７（ｃ）に示す。ここでは、ディスパッチ１回あたりの時間（τ）は２．５ｍｓとなるが、単位時間当たりのゲストＯＳ４０-3（＃３）へのディスパッチ回数は２０回となり、図７（ｂ）の単位時間当たりのディスパッチ回数（１０回）よりも改善されたことが分かる。つまり、ディスパッチ１回あたりの処理時間は半分になるが、ディスパッチ頻度は２倍（ディスパッチ間隔は半分）となり応答性改善が期待できる。

例えば、制御用のシステムで、且つ（割り込みではなく）ポーリング方式で対象デバイスを制御しているような場合には、ＣＰＵが割り当てられる頻度が重要である。したがって、このようなシステムにおいて、第１の変形例のようにクォンタムの値が小さくなったとしても、ディスパッチ機会が増えることは応答性向上に貢献する。

［第２の変形例］
上記実施形態では、第１のタイプのゲストＯＳが複数存在し、且つ、例えばＣＰＵ周波数が大きく下がったときに、全ての第１のタイプのゲストＯＳのＣＰＵ割当量に関する要求を満たそうとすると、ＣＰＵ処理量が足りなくなる可能性がある。そのため、ＣＰＵ周波数がシステムの運用で想定される最低周波数となった場合でも当該システムを運用可能とする仕組みを予め用意しておくことが好ましい。即ち、ＣＰＵ周波数が最低周波数（最低ＣＰＵ周波数）となった場合でも、第１のタイプのゲストＯＳから要求された「ＣＰＵ絶対処理量」を実現できるように、当該ゲストＯＳに対するＣＰＵ割り当てを調整する仕組みを必要とする。

そこで、このような仕組みを実現する、上記実施形態の第２の変形例について説明する。第２の変形例では、第１のタイプのゲストＯＳが複数存在する場合に、当該ゲストＯＳの要求する「ＣＰＵ絶対処理量」の保証の優先順位を当該ゲストＯＳ毎に設定できるようにしたことを特徴とする。この優先順位により、ＣＰＵ周波数が大きく（例えば最低周波数まで）下がっても必ずＣＰＵ絶対処理性能を保証すべきゲストＯＳと、それよりも優先順位が下がるが、できるだけＣＰＵ絶対処理性能を保証すべきゲストＯＳとを区別して指定することが可能となる。

図８は、第２の変形例で適用されるゲストＯＳ管理テーブル２１２を示す。第２の変形例では、このゲストＯＳ管理テーブル２１２が、図１に示されるゲストＯＳ管理テーブル２０２に代えて用いられるものとする。ゲストＯＳ管理テーブル２１２がゲストＯＳ管理テーブル２０２と相違する点は、ゲストＯＳ（のゲストＯＳ番号）に対応付けられる項目として、「ＣＰＵ絶対処理量割り当て優先度」「ＡＬＬＯＣフラグ」及び「ＭＳＧフラグ」が追加されていることである。

「ＣＰＵ絶対処理量割り当て優先度」は、ゲストＯＳスケジューラ２０１がスケジューリングする際に「ＣＰＵ絶対処理量」を割り当てるゲストＯＳの順番を決定するのに用いられる。この例では、「ＣＰＵ絶対処理量割り当て優先度」は０〜７の値をとり、値が大きいほど優先的に「ＣＰＵ絶対処理量」が割り当てられる。

第２の変形例においてゲストＯＳ４０-i（＃ｉ）（ｉは０〜４のいずれか）は、「ＣＰＵ絶対処理量割り当て優先度」の設定が必要な場合、専用のシステムコールを使って、当該「ＣＰＵ絶対処理量割り当て優先度」の設定をＶＭＭ２０に要求する。そのため第２の変形例では、
VMM_set_guestos_priority(Priority);
のようなインターフェイス（インターフェイス関数）呼び出しのためのシステムコールが用意されている。ゲストＯＳ４０-iがインターフェイス関数を呼び出すとＶＭＭ２０に対するシステムコールが発生する。このインターフェイス関数の引数は「ＣＰＵ絶対処理量割り当て優先度」である。

ゲストＯＳスケジューラ２０１は上述のインターフェイス関数を用いたゲストＯＳ４０-iからのシステムコールにより、当該インターフェイス関数の引数の「ＣＰＵ絶対処理量割り当て優先度」（つまり指定された値）を当該ゲストＯＳ４０-i（のゲストＯＳ番号ｉ）に対応付けて、ゲストＯＳ管理テーブル２１２の「ＣＰＵ絶対処理量割り当て優先度」の欄に登録する。

「ＡＬＬＯＣフラグ」は、ＣＰＵ絶対処理量割り当て処理が行われたことを示すフラグである。「ＭＳＧフラグ」は、スケジューリング処理の結果、第１のタイプのゲストＯＳに対して、指定されていたＣＰＵ絶対処理量分のＣＰＵ処理量が割り当てられなかったことを示すフラグである。「ＭＳＧフラグ」がセットされていると、当該「ＭＳＧフラグ」に対応するゲストＯＳに対してＶＭＭ２０から警告が発せられる。この警告は、例えばＶＭＭ２０が対応するゲストＯＳに対して、メッセージパケットと割り込みを送信することで実現されるものとする。

図８に示されるゲストＯＳ管理テーブル２１２は、ＣＰＵ周波数が規定ＣＰＵ周波数に一致する場合におけるスケジューリングの結果を表している。図８の例では、第１のタイプのゲストＯＳは上記実施形態及び第１の変形例と同様に、ゲストＯＳ４０-0〜４０-2である。ここでは、第１のタイプの全てのゲストＯＳ４０-0〜４０-2に対して、要求された分のＣＰＵ処理量が割り当てられている。

このような状態で、ＣＰＵ周波数が規定ＣＰＵ周波数の半分になった場合のスケジューリング処理について、図９Ａ及び図９Ｂのフローチャートを参照して説明する。図において、Ｒｒｅｓｔは、現時点においてＣＰＵ処理量が未割り当ての第１のタイプのゲストＯＳに対して割り当て可能なＣＰＵ処理量（％）を示す。Ｒ０は、第２のタイプのゲストＯＳを実行するための最低限のＣＰＵ処理量（％）を示す。ここでは、Ｒ０として２０％が予め定められているものとする。

ゲストＯＳスケジューラ２０１はまず、Ｒｒｅｓｔを初期設定する（ステップＳ１１）。Ｒｒｅｓｔの初期値は、１００％からＲ０を減じた値である。これにより、第２のタイプのゲストＯＳのためにＲ０で示されるＣＰＵ処理量が残される。次にゲストＯＳスケジューラ２０１は、ゲストＯＳ管理テーブル２１２のゲストＯＳ毎の「現在の割当量」「ＡＬＬＯＣフラグ」及び「ＭＳＧフラグ」を全てクリアする（ステップＳ１２）。

次にゲストＯＳスケジューラ２０１は、Ｒｒｅｓｔが０であるかを判定する（ステップＳ１３）。もし、Ｒｒｅｓｔが０でないならば（ステップＳ１３）、ゲストＯＳスケジューラ２０１は、この段階で未処理の第１のタイプのゲストＯＳに割り当てるＣＰＵ処理量は残されているとして、ステップＳ１４に進む。

ステップＳ１４において、ゲストＯＳスケジューラ２０１はゲストＯＳ管理テーブル２１２を参照することにより、現時点で未処理で且つＣＰＵ絶対処理量割り当て優先度が予め定められた最低優先度よりも高い第１のタイプのゲストＯＳが存在するかを判定する。但し、第２の変形例において上記最低優先度は０であり、第２のタイプのゲストＯＳの優先度である。したがって最低優先度以下の第１のタイプのゲストＯＳは存在しない。

もし、このような第１のタイプのゲストＯＳが存在するならば（ステップＳ１４）、ゲストＯＳスケジューラ２０１は、その中で最もＣＰＵ絶対処理量割り当て優先度の高いゲストＯＳを１つ選択し、ＧＯＳｉとして設定する（ステップＳ１５）。但し、第２の変形例において上記最低優先度は０であり、第２のタイプのゲストＯＳのＣＰＵ絶対処理量割り当て優先度である。したがって第１のタイプのゲストＯＳのＣＰＵ絶対処理量割り当て優先度は全て最低優先度より高い。

ゲストＯＳスケジューラ２０１は、選択された第１のタイプのゲストＯＳ（即ちＧＯＳｉ）の「ＣＰＵ絶対処理量」をゲストＯＳ管理テーブル２１２から取得し、その「ＣＰＵ絶対処理量」をＡｉとする（ステップＳ１６）。次にゲストＯＳスケジューラ２０１は、現在のＣＰＵ周波数ＦｃにおけるＡｉに相当するＣＰＵ処理量を求め、Ｒｉ［％］として設定する（ステップＳ１７）。ここでＲｉは、上記実施形態におけるＲｎｏｗに相当し、図４または図５のフローチャートのステップＳ４と同様に、ＧＯＳｉに対して定められている「ＣＰＵ絶対処理量」、現在のＣＰＵ周波数Ｆｃ及び規定ＣＰＵ周波数Ｆｓに基づき算出される。

次にゲストＯＳスケジューラ２０１は、ＲｉがＲｒｅｓｔ（未割り当てのＣＰＵ処理量）以下であるかを判定する（ステップＳ１８）。もし、ＲｉがＲｒｅｓｔ以下であるならば（ステップＳ１８）、ゲストＯＳスケジューラ２０１はＧＯＳｉに対してＲｉを割り当て可能であると判定する。この場合、ゲストＯＳスケジューラ２０１は、ＲｒｅｓｔからＲｉを減じて新たなＲｒｅｓｔとすると共に（ステップＳ１９）、当該ＲｉをゲストＯＳ管理テーブル２１２のＧＯＳｉに対応付けられた「現在の割当量」の欄に登録する（ステップＳ２３）。つまりゲストＯＳスケジューラ２０１は、ＧＯＳｉにＲｉを割り当てる。

これに対し、ＲｉがＲｒｅｓｔよりも大きいならば（ステップＳ１８）、ゲストＯＳスケジューラ２０１はＧＯＳｉに対してＲｉの一部のみが割り当て可能であると判定する。この場合、ゲストＯＳスケジューラ２０１は、Ｒｒｅｓｔの全てをＧＯＳｉに割り当てるために、ＲｉをＲｒｅｓｔに変更すると共に（ステップＳ２１）、Ｒｒｅｓｔを０に設定する（ステップＳ２２）。このステップＳ２２は、Ｒｒｅｓｔから当該Ｒｒｅｓｔを減じて新たなＲｒｅｓｔとすることと等価である。そしてゲストＯＳスケジューラ２０１は、ステップＳ２１で変更されたＲｉを、ゲストＯＳ管理テーブル２１２のＧＯＳｉに対応付けられた「現在の割当量」の欄に登録する（ステップＳ２３）。つまりゲストＯＳスケジューラ２０１は、ＧＯＳｉに、ステップＳ１８の実行時点のＲｒｅｓｔの全てを（Ｒｉとして）割り当てる。またゲストＯＳスケジューラ２０１は、ＧＯＳｉから要求されている「ＣＰＵ絶対処理量」を当該ＧＯＳｉに割り当てられなかったので、後で当該ＧＯＳｉに警告を出すために、当該ＧＯＳｉに対応付けられたゲストＯＳ管理テーブル２１２の「ＭＳＧフラグ」の欄に１をセットする（ステップＳ２０）。即ちゲストＯＳスケジューラ２０１は、ＧＯＳｉに対応付けられているゲストＯＳ管理テーブル２１２の「ＭＳＧフラグ」をセットする。

ゲストＯＳスケジューラ２０１は、上記ステップＳ２３を実行すると、ＧＯＳｉにＣＰＵ処理量を割り当てたことを記録するために、当該ＧＯＳｉに対応付けられたゲストＯＳ管理テーブル２１２の「ＡＬＬＯＣフラグ」の欄に１をセットする（ステップＳ２４）。

ゲストＯＳスケジューラ２０１は、以上の処理を、Ｒｒｅｓｔが０になるか、或いは未処理の第１のタイプのゲストＯＳがなくなるまで繰り返す（ステップＳ１３，Ｓ１４）。そして、Ｒｒｅｓｔが０になるか（ステップＳ１３）、或いは未処理の第１のタイプのゲストＯＳがなくなったなら（ステップＳ１４）、ゲストＯＳスケジューラ２０１はステップＳ２５に進む。このとき、未処理（ＣＰＵ処理量が未割り当て）の第１のタイプのゲストＯＳが残っていれば、ゲストＯＳスケジューラ２０１はステップＳ２５において、当該第１のタイプのゲストＯＳに対応付けられているゲストＯＳ管理テーブル２１２のＭＳＧフラグをセットする。

次にゲストＯＳスケジューラ２０１は、Ｒ０を含めた未割り当て時間Ｒｔｏｔａｌ（＝Ｒｒｅｓｔ＋Ｒ０）を算出する（ステップＳ２６）。そしてゲストＯＳスケジューラ２０１は、未割り当て時間Ｒｔｏｔａｌを、未処理（ＣＰＵ処理量が未割り当て）の全てのゲストＯＳ（つまり未処理の第１のタイプのゲストＯＳ及び未処理の第２のタイプのゲストＯＳ）に均等に割り当て、その結果をゲストＯＳ管理テーブル２１２の当該未処理のゲストＯＳに対応付けられた「現在の割当量」の欄に登録するる（ステップＳ２７）。

このような図９Ａ及び９Ｂのフローチャートに従うスケジューリング処理が、図８に示すゲストＯＳ管理テーブル２１２の状態のときに行われた場合、当該ゲストＯＳ管理テーブル２１２は図１０のようになる。

図１０のゲストＯＳ管理テーブル２１２の例では、第１のタイプのゲストＯＳ４０-0（＃０）〜４０-2（＃２）のうち、ＣＰＵ絶対処理量優先度が高いゲストＯＳ４０-1（＃１）及びＯＳ４０-2（＃２）には、それぞれ当該ゲストＯＳ４０-1（＃１）及びＯＳ４０-2（＃２）が要求しているＣＰＵ絶対処理量２０％及び１５％を保証するＣＰＵ割当量４０％及び３０％が割り当てられている。

これに対して、ゲストＯＳ４０-1（＃１）及びＯＳ４０-2（＃２）よりもＣＰＵ絶対処理量優先度が低いゲストＯＳ４０-2（＃２）には、当該ゲストＯＳ４０-2（＃２）が要求しているＣＰＵ絶対処理量１０％を保証するのに必要なＣＰＵ割当量２０％ではなくて、それより少ない１０％だけが割り当てられている。このため、ゲストＯＳ４０-2に対応付けてＭＳＧフラグがセットされている。ディスパッチャ２０３は、このＭＳＧフラグに基づき、ゲストＯＳ４０-2に対して警告メッセージを送る。

なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。

本発明の一実施形態に係る仮想計算機システム１の構成を示すブロック図。 同実施形態において適用される、現在のＣＰＵ周波数が規定ＣＰＵ周波数の半分の場合のゲストＯＳ管理テーブルの一例を示す図。 図１に示されるディスパッチャによるディスパッチの例を示す図。 同実施形態におけるスケジューリング処理の手順を示すフローチャート。 現在のＣＰＵ周波数が規定周波数に一致する場合のゲストＯＳ管理テーブルの一例を示す図。 同実施形態の第１の変形例におけるスケジューリング処理の手順を示すフローチャート。 同記第１の変形例における第２のタイプのゲストＯＳに対するディスパッチの様子を示す図。 同実施形態の第２の変形例で適用される、現在のＣＰＵ周波数が規定周波数に一致する場合のゲストＯＳ管理テーブルの一例を示す図。 同記第２の変形例においてＣＰＵ周波数が規定ＣＰＵ周波数の半分になった場合のスケジューリング処理の手順を示すフローチャート。 同記第２の変形例においてＣＰＵ周波数が規定ＣＰＵ周波数の半分になった場合のスケジューリング処理の手順を示すフローチャート。 図９Ａ及び９Ｂのフローチャートに従うスケジューリング処理が図８に示すゲストＯＳ管理テーブルの状態のときに行われた後の、当該ゲストＯＳ管理テーブルの状態を示す図。

符号の説明

１…仮想計算機システム、１０…物理計算機、１１…ＨＷ（ハードウェア）、２０…ＶＭＭ（仮想計算機マネージャ）、３０-0〜３０-3…ＶＭ（仮想マシン、仮想計算機）、４０-0〜４０-3…ゲストＯＳ、１１０…ＣＰＵ、１１１…ＣＰＵ周波数変化通知部、１１２…ＣＰＵ周波数設定部、２０１…ゲストＯＳスケジューラ、２０２，２１２…ゲストＯＳ管理テーブル、２０３…ディスパッチャ、２０４…ＣＰＵ周波数変化検出部、２０５…ＣＰＵ周波数変更部。

Claims (5)

1. ＣＰＵを含むハードウェアと、
   温度を含む動作環境の変動に応じて前記ＣＰＵの動作周波数を変化させる動作周波数可変手段と、
   前記ハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを実行させるための管理を行う仮想計算機マネージャとを具備し、
   前記仮想計算機マネージャは、
   前記動作周波数の変化を検出するための動作周波数変化検出手段と、
   前記複数のゲストＯＳに前記ＣＰＵを時分割で割り当てるためのスケジュールを管理するスケジューラであって、前記動作周波数変化検出手段によって前記動作周波数の変化が検出され、且つ当該動作周波数が予め定められた規定動作周波数から低下した場合、前記複数のゲストＯＳのうちの予め定められた特定ゲストＯＳが当該規定動作周波数での動作で必要とする前記ＣＰＵの処理能力であるＣＰＵ絶対処理量を維持するために、当該特定ゲストＯＳに前記ＣＰＵが割り当てられるべき時間が増えるように前記スケジュールを調整するスケジューラと、
   前記スケジューラによって管理される前記スケジュールに従って前記複数のゲストＯＳに前記ＣＰＵを時分割で割り当てるディスパッチャと
   を含むことを特徴とする仮想計算機システム。
2. 前記仮想計算機マネージャは、前記特定ゲストＯＳにより発行される、当該特定ゲストＯＳへの前記ＣＰＵ絶対処理量の割り当てのためのＣＰＵ絶対処理量設定要求を受け付けるインターフェイスを含み、
   前記スケジューラは、前記インターフェイスで前記ＣＰＵ絶対処理量設定要求が受け付けられた場合、当該要求の示すＣＰＵ絶対処理量を、前記特定ゲストＯＳが前記規定動作周波数での動作で必要とする前記ＣＰＵの処理能力であるとして管理する
   ことを特徴とする請求項１記載の仮想計算機システム。
3. 前記ＣＰＵ絶対処理量設定要求は、前記ＣＰＵ絶対処理量の割り当ての優先度を含み、
   前記スケジューラは、前記動作周波数が前記規定動作周波数から低下し、且つ前記複数のゲストＯＳの中に前記ＣＰＵ絶対処理量設定要求を発行した前記特定ゲストＯＳが複数含まれている場合、前記ＣＰＵ絶対処理量設定要求の示す前記優先度に従って、前記複数の特定ゲストＯＳのうち優先度の高い特定ゲストＯＳから優先的に当該ＣＰＵ絶対処理量を維持するために前記スケジュールを調整する
   ことを特徴とする請求項２記載の仮想計算機システム。
4. 前記スケジューラは、前記特定ゲストＯＳに前記ＣＰＵが割り当てられるべき時間が増えるように前記スケジュールを調整する際に、前記複数のゲストＯＳに前記ＣＰＵを割り当てる時間単位の大きさを小さくすることを特徴とする請求項１乃至３のいずれかに記載の仮想計算機システム。
5. ＣＰＵを含むハードウェアと、温度を含む動作環境の変動に応じて前記ＣＰＵの動作周波数を変化させる動作周波数可変手段と、前記ハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを実行させるための管理を行う仮想計算機マネージャとを具備する仮想計算機システムにおけるゲストＯＳスケジューリング方法であって、
   前記動作周波数が予め定められた規定動作周波数から低下したことを前記仮想計算機マネージャが検出するステップと、
   前記動作周波数が前記規定動作周波数から低下した場合、前記複数のゲストＯＳのうちの予め定められた特定ゲストＯＳが当該規定動作周波数での動作で必要とする前記ＣＰＵの処理能力であるＣＰＵ絶対処理量を維持するために、当該特定ゲストＯＳに前記ＣＰＵが割り当てられるべき時間が増えるように前記スケジュールを前記仮想計算機マネージャが調整するステップと
   を具備することを特徴とするゲストＯＳスケジューリング方法。

Images