JP2009075766A - 仮想計算機システム及び同システムにおけるスケジュール調整方法 - Google Patents

Abstract

【課題】ゲストＯＳをディスパッチするためのスケジュールを、受信側ゲストＯＳでの受信割り込みの解除後の受信処理が迅速に行えるように調整する。
【解決手段】ＣＰＵ１１を含む物理計算機１上で動作するＶＭＭ２０は、割り込み管理部２３及びゲストＯＳスケジューラ２２１を含む。割り込み管理部２３は、送信側ゲストＯＳからＶＭＭ２０に与えられる受信側ゲストＯＳへのゲストＯＳ間通信の要求を受けて、ゲストＯＳ間通信の受信を受信割り込みにより通知する。ゲストＯＳスケジューラ２２１は、ゲストＯＳ３１-1〜３１-3ののうちの任意のゲストＯＳへの割り込みの要因が発生し、且つ当該要因がゲストＯＳ間通信の受信である場合に、当該任意のゲストＯＳを受信側ゲストＯＳとして、受信割り込みの解除後の受信処理に必要なＣＰＵ時間が当該受信側ゲストＯＳに追加で割り当てられるようにスケジュールを調整する。
【選択図】 図１

Description

本発明は、ＣＰＵを含む物理計算機上で動作する仮想計算機マネージャによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行される仮想計算機システムに係り、特に複数のゲストＯＳを時分割で実行させるためのスケジュール（つまりゲストＯＳをディスパッチするためのスケジュール）を調整するのに好適な仮想計算機システム及び同システムにおけるスケジュール調整方法に関する。

近年、パーソナルコンピュータのような計算機システムにおいて、仮想計算機（Virtual Machine：ＶＭ）の技術を応用した研究や開発が行われているまた、仮想計算機システムを実現するための商用のアプリケーションプログラムが実際に広く利用されている。また、メインフレームにおいて古くからハードウェア（ＨＷ）で構成された仮想計算機支援機構を用いた仮想計算機システムも存在する。

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

ＶＭＭは、実ＣＰＵ、実Ｉ／Ｏ装置及び実メモリのような物理資源の管理を行い、それらを仮想化して仮想計算機（ＶＭ）を構築する。つまりＶＭＭは、実ＣＰＵ、実Ｉ／Ｏ装置及び実メモリのような物理資源（ＨＷ資源）を時間的、空間（領域）的に、仮想計算機のそれぞれ仮想ＣＰＵ、仮想Ｉ／Ｏ装置及び仮想メモリとして割り当てることによって、当該仮想計算機を構築（生成）する。各ゲストＯＳは仮想計算機にロードされて、当該仮想計算機内の仮想ＣＰＵによって実行される。このようにＶＭＭは、実ＣＰＵ、実Ｉ／Ｏ装置及び実メモリのような物理資源を各ゲストＯＳに割り当てることによって、当該各ゲストＯＳが同時に動作できる環境を提供し、仮想計算機システムの管理を行う。

ＶＭＭは一般に、ゲストＯＳに対して、仮想ネットワークや独自仕様のメッセージプロトコルのようなゲストＯＳ同士が通信する手段（方法）を１種類以上提供する。通常、ゲストＯＳ間通信では、受信の際に特定の処理を必要とする。例えば、受信パケットがあれば解析処理を行うとか、送信側に対してアクナレッジ（Acknowledge）を返す等の処理である。

受信の通知は割り込みによって行われることが多い。一般の仮想計算機システムでは、あるゲストＯＳが割り込み状態にあるときに、そのゲストＯＳにＣＰＵ実行時間が割り当てられる。但し、一般に割り込み処理時間が長時間にわたることは好ましくないため、実際には割り込み処理においては上記の処理のうち必要最小限のみを行って、残りの大部分は割り込み解除後に行われることが多い。

このように、受信後の処理は割り込み解除後に行われるのが一般的であるが、受信割り込み直後に実行されることが期待されている。但し、複数のゲストＯＳの存在する仮想計算機実行環境では、割り込み解除したために受信者以外のゲストＯＳにディスパッチされる可能性がある。

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

上記したような仮想計算機システムでは、ゲストＯＳのディスパッチ方針が通信の効率に影響を与える。ここで、ゲストＯＳ間の通信として、例えば以下に挙げるような２つの特徴的なモデルが考えられる。

（１）第１は、１対のゲストＯＳの間で定常的に一連の関連ある処理として交互に行われる通信（１対１の通信）である。このような通信（以下、第１のタイプの通信と称する）は、１対のゲストＯＳが協調して作業を行うような場合に発生する。

（２）第２は、１つのゲストＯＳと他の複数のゲストＯＳとの間で頻繁に行われる通信（つまり複数のゲストＯＳの間で頻々に行われる通信）であり、個々の通信の間には関連性はない。このような通信（以下、第２のタイプの通信と称する）は、サーバ・クライアントモデルの通信を行うような場合に発生する。

さて、仮想計算機システムにおいて、ゲストＯＳはＶＭＭによってＣＰＵ時間を与えられた間のみディパッチして動作することができる。したがって、ゲストＯＳ間の通信の性能（スループットまたはレスポンス）は、ＶＭＭによるゲストＯＳのディスパッチの方針に大きく依存する。

例えば、上記第１の通信では、一方のゲストＯＳに行うべき処理がある場合に他方のゲストＯＳにＣＰＵ時間が割り当てられると、結果として処理が進まずにスループットが低下する。一方、上記第２の通信では、個々の通信に対してゲストＯＳのディスパッチを実施すると、ディスパッチのコストが原因でシステムの効率を悪化させる可能性がある。

このように、ゲストＯＳ間の通信とゲストＯＳのディスパッチは効率面において大きな関連がある。しかしながら、非特許文献１乃至３には、この点を考慮してゲストＯＳをディスパッチするためのスケジュール調整について記載されていない。

本発明は上記事情を考慮してなされたものでその目的は、ゲストＯＳをディスパッチするためのスケジュールを、受信側ゲストＯＳでの受信割り込みの解除後の受信処理が迅速に行えるように調整することができ、これによりゲストＯＳ間通信が効率よく行える仮想計算機システム及び同システムにおけるスケジュール調整方法を提供することにある。

本発明の１つの観点によれば、ＣＰＵを含む物理計算機上で動作する仮想計算機マネージャによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行される仮想計算機システムが提供される。この仮想計算機システムにおいて、前記仮想計算機マネージャは、前記複数のゲストＯＳのうちの任意のゲストＯＳへの割り込みを管理する割り込み管理手段であって、送信側ゲストＯＳから前記仮想計算機マネージャに与えられる受信側ゲストＯＳへのゲストＯＳ間通信の要求を受けて、前記送信側ゲストＯＳからの送信データの前記受信側ゲストＯＳでの受信を受信割り込みにより通知する割り込み管理手段と、前記複数のゲストＯＳを時分割で実行させるためのスケジュールを管理するスケジューラであって、前記複数のゲストＯＳのうちの任意のゲストＯＳへの割り込みの要因が発生し、且つ当該要因が前記受信割り込みである場合に、当該任意のゲストＯＳを前記受信側ゲストＯＳとして、前記受信割り込みの解除後の受信処理に必要なＣＰＵ時間が当該受信側ゲストＯＳに追加で割り当てられるように前記スケジュールを調整するスケジューラと、前記スケジューラによって調整された前記スケジュールに従って前記複数のゲストＯＳをディスパッチするディスパッチャとを具備することを特徴とする。

本発明によれば、あるゲストＯＳへの割り込みの要因が受信割り込みによる通知を必要とするゲストＯＳ間通信の受信である場合に、当該ゲストＯＳ（つまり受信側ゲストＯＳ）での受信割り込みの解除後の受信処理に必要なＣＰＵ時間が当該ゲストＯＳに追加で割り当てられるようにスケジュールが調整される。これにより受信側ゲストＯＳでは、追加で割り当てられるＣＰＵ時間を使用して受信処理を迅速に行うことができ、その結果としてゲストＯＳ間の通信の効率が向上し、仮想計算機システム全体の処理効率を向上させることができる。

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

物理計算機１のＨＷ１０上では、仮想計算機マネージャ（Virtual Machine Manager：ＶＭＭ）２０が動作する。ＶＭＭ２０は、仮想計算機システムの管理を行い、仮想計算機が動作する環境（仮想計算機実行環境）を構築する。更に具体的に述べるならば、ＶＭＭ２０は、物理計算機１のＨＷ１０を構成するＣＰＵ１１、Ｉ／Ｏ１２及びメモリ１３のような物理資源（ハードウェアリソース）を制御すると共に当該物理資源の時間的、領域的な配分を管理することにより、複数の仮想計算機、例えば３台の仮想計算機（ＶＭ）３０-1，３０-2，３０-3が動作する仮想計算機実行環境を提供する。ＶＭ３０-1，３０-2，３０-3は何れも、ＶＭＭ２０が、物理計算機１のＣＰＵ１１、Ｉ／Ｏ１２及びメモリ１３を、時間的、領域的に図示せぬ仮想ＣＰＵ、仮想Ｉ／Ｏ及び（ＶＭ３０-1，３０-2，３０-3の）メモリとして割り当てることにより構築される。

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

ＶＭＭ２０は、ゲストＯＳ間通信管理部２１、ゲストＯＳ実行管理部２２、割り込み管理部２３及びゲストＯＳコンテキスト管理部２４を含む。
ゲストＯＳ間通信管理部２１は、ゲストＯＳ３１-1〜３１-3間の通信を管理すると共にその通信のための機能（送信手続き及び受信手続き等の通信手段）を提供するモジュールである。本実施形態においてゲストＯＳ間の通信手段は、送信元（送信側）のゲストＯＳからのデータパケットを送信先（受信側）のゲストＯＳの受信バッファにコピーすることによって情報の受け渡しを行うものであるとするが、これに限らない。例えば通信手段が、送信ゲストＯＳと受信側ゲストＯＳとで共有されるメモリ空間を介して情報の受け渡しを行うものであっても構わない。また、ゲストＯＳ間の通信手段が複数存在する場合、ゲストＯＳ間通信管理部２１が通信手段の種類に応じて複数存在しても構わない。

ゲストＯＳ間通信管理部２１は、ゲストＯＳに対してゲストＯＳ間の通信手段として、ゲストＯＳ間通信インタフェース（ゲストＯＳ間通信ＩＦ）を提供する。図１の例では、ゲストＯＳ３１-1，３１-2に対し、ゲストＯＳ間通信管理部２１（ＶＭＭ２０内のゲストＯＳ間通信管理部２１）によってそれぞれゲストＯＳ間通信ＩＦ２１０が提供されている状態が示されている。ゲストＯＳ３１-1，３１-2は、それぞれゲストＯＳ間通信ＩＦ２１０を使用して、他のゲストＯＳへのデータ送信、或いは他のゲストＯＳから受信したデータの取得を、ＶＭＭ２０に対して要求する。ここで、ゲストＯＳ３１-3に対してゲストＯＳ間通信ＩＦ２１０が提供されるならば、当該ゲストＯＳ３１-3もゲストＯＳ３１-1，３１-2と同様にデータ送信或いはデータ取得をＶＭＭ２０に対して要求することができる。

ゲストＯＳ間通信管理部２１は、ゲストＯＳ間通信監視部２１１を含む。ゲストＯＳ間通信監視部２１１は、ゲストＯＳ間通信管理部２１によって送信側のゲストＯＳ３１-i（ｉ＝１，２，３）及び受信側のゲストＯＳ３１-j（ｊ＝１，２，３、但しｊ≠ｉ）にそれぞれ提供されるゲストＯＳ間通信ＩＦ２１０を用いてのゲストＯＳ間通信の状況を監視する。ゲストＯＳ間通信監視部２１１は、この監視の結果に基づき、受信側のゲストＯＳ３１-jにおける後述する受信処理に必要なＣＰＵ追加割当時間として用いられるＣＰＵ時間（ＣＰＵ実行時間）を決定する。

ゲストＯＳ実行管理部２２はゲストＯＳ３１-1〜３１-3の実行を管理する。ゲストＯＳ実行管理部２２は、ゲストＯＳスケジューラ２２１、ＣＰＵ時間割当テーブル２２２及びディスパッチャ２２３を含む。

ゲストＯＳスケジューラ２２１は、各ゲストＯＳ３１-1〜３１-3に対して、いつ、どれだけの期間ＣＰＵ１１を仮想ＣＰＵとして割り当てるか、つまり、どれだけのＣＰＵ時間（ＣＰＵ実行時間）を割り当てるかを管理するモジュールである。

ＣＰＵ時間割当テーブル２２２は、各ゲストＯＳ３１-1〜３１-3をディスパッチするためのスケジュール（の情報）を保持するデータテーブルである。更に具体的に述べるならば、ＣＰＵ時間割当テーブル２２２は、ＣＰＵ時間を各ゲストＯＳ３１-1〜３１-3にいつの時点でどれだけ割り当てるかの予定（スケジュール）を表すデータテーブルである。ＣＰＵ時間割当テーブル２２２によって表される（保持される）スケジュール（の情報）は動的に変更可能である。図１では、ＣＰＵ時間割当テーブル２２２はＶＭＭ２０のゲストＯＳ実行管理部２２に含まれているが、物理的には例えばメモリ１３に格納して用いられる。

図２はＣＰＵ時間割当テーブル２２２の示すスケジュール例を示す。図２に示すスケジュールでは、現在から２４ｍｓ先の時点までのＣＰＵ時間割り当て予定が設定されている。ここでは、２４ｍｓが２ｍｓ毎に１２分割されて、ＣＰＵ時間が３個のゲストＯＳ３１-1〜３１-3に２ｍｓ（のフレーム）単位でラウンドロビンで割り当てられる予定であることが示されている。１２分割された各枠内の数字はゲストＯＳ番号を表している。ＣＰＵ時間割当テーブル２２２は、ゲストＯＳスケジューラ２２１によって更新される。ここではＣＰＵ時間割当テーブル２２２は、実際にゲストＯＳのコンテキストスイッチ（他のゲストＯＳへのディスパッチ）が発生したタイミングで更新される。

ディスパッチャ２２３は、現在ＣＰＵ１１を使って実行しているゲストＯＳをＣＰＵ時間割当テーブル２２１に基づいて他のゲストＯＳに切り替えるためのモジュールである。即ちディスパッチャ２２３は、ＣＰＵ時間割当テーブル２２２の示すＣＰＵ時間割り当ての順番（図２の例では左端から右端に向かう順番）に従ってゲストＯＳのディスパッチを行う。なお、図２に示されるＣＰＵ時間割当テーブル２２２のようなフレーム単位のスケジュール表に基づくスケジューリングに代えて、プライオリティキューを使ったスケジューリングを適用することも可能である。

割り込み管理部２３は、ゲストＯＳへの割り込みを管理する。ゲストＯＳへの割り込みの１つに、受信割り込みがある。受信割り込みは、送信側ゲストＯＳ３１-iから受信側ゲストＯＳ３１-jへの通信（ゲストＯＳ間通信）に伴う送信データの受信を当該ゲストＯＳ３１-jに通知するための割り込みである。

ゲストＯＳコンテキスト管理部２４は、ゲストＯＳ３１-1〜３１-3を実行する際に必要な情報の集合であるゲストＯＳコンテキスト２４１-1〜２４１-3を生成する。図１では、ゲストＯＳコンテキスト２４１-1〜２４１-3はＶＭＭ２０のゲストＯＳコンテキスト管理部２４に含まれているが、物理的には例えばメモリ１３によって提供されるメモリ領域に格納して用いられる。

図３はゲストＯＳコンテキスト２４１-i（ｉ＝１，２，３）のデータ構造例を示す。ゲストＯＳコンテキスト２４１-iは、ゲストＯＳ固有データ２４２、割り込み要因レジスタ２４３及びＣＰＵ追加割当時間情報２４４を含む。

ゲストＯＳ固有データ２４２は、ゲストＯＳ切り替え時のＣＰＵレジスタ状態を含む情報である。
割り込み要因レジスタ２４３は、ゲストＯＳ３１-iに割り込みが発生した場合に、その割り込みの要因を識別するためのビットの群から構成される割り込み要因保持管理手段である。割り込み要因レジスタ２４３はゲストＯＳ通信受信ビットを含む。ゲストＯＳ通信受信ビットは、ゲストＯＳ３１-iへの割り込みが、ゲストＯＳ間通信による送信データの受信を当該ゲストＯＳ３１-iに通知するための割り込み、つまり受信割り込みであることを示す特定ビットである。このゲストＯＳ通信受信ビットは、ゲストＯＳ間通信による送信データがゲストＯＳ３１-iで受信された際（本実施形態では、ゲストＯＳ３１-iの受信バッファにコピーされた際）にＯＮされる。割り込み要因レジスタ２４３は、例えば、物理計算機１のＨＷ１０に含まれている物理レジスタをゲストＯＳ３１-iが動作するＶＭ３０-iの実行環境（仮想計算機実行環境）にマップすることによって実現されるものとする。しかし、割り込み要因レジスタ２４３が、ＶＭＭ２０によって作成される仮想レジスタであっても構わない。

ＣＰＵ追加割当時間情報２４４は、ゲストＯＳ３１-iが他のゲストＯＳからの通信を受信した場合に、当該ゲストＯＳ３１-iに追加で割り当てられるＣＰＵ時間（ＣＰＵ追加割当時間）の値を表す変数である。ＣＰＵ追加割当時間情報２４４には、ゲストＯＳ間通信の受信側でのデータ受信に伴う処理（受信処理）に必要なＣＰＵ時間（ＣＰＵ実行時間）を示す値が用いられる。本実施形態ではＣＰＵ追加割当時間情報２４４として、４ｍｓの値が設定されているものとする。但し、ＣＰＵ追加割当時間情報２４４は、後述するＣＰＵ追加割当時間設定部２４０によって動的に変更される。ＣＰＵ追加割当時間情報２４４はゲストＯＳ３１-iから参照される必要のない変数である。なお、ゲストＯＳ間通信の手段が複数存在する場合、それぞれの手段に対応した変数（ＣＰＵ追加割当時間情報２４４）が設定される構成であっても良い。

再び図１を参照すると、ゲストＯＳコンテキスト管理部２４はＣＰＵ追加割当時間設定部２４０を含む。ＣＰＵ追加割当時間設定部２４０は、ゲストＯＳ間通信管理部２１内のゲストＯＳ間通信監視部２１１によるゲストＯＳ間通信の状況の監視結果に基づき、受信側のゲストＯＳ３１-j（ｊ＝１，２，３）における受信処理に必要なＣＰＵ時間（ＣＰＵ実行時間）をＣＰＵ追加割当時間として決定する。ＣＰＵ追加割当時間設定部２４０は、ゲストＯＳコンテキスト２４１-jに含まれているＣＰＵ追加割当時間情報２４４を、決定されたＣＰＵ追加割当時間の値に設定変更する。

このように、ゲストＯＳ間通信の状況に応じて、受信側のゲストＯＳ３１-jにおける受信処理に必要なＣＰＵ時間がＣＰＵ追加割当時間として動的に設定される構成とすることにより、システム全体の処理が効率よく進められるようになる。

なお、各ゲストＯＳコンテキスト２４１-jに含まれるＣＰＵ追加割当時間情報２４４を、ゲストＯＳ３１-j毎のＣＰＵ追加割当時間の設定値が保存された設定ファイルを用いて、例えばシステム起動時にＣＰＵ追加割当時間設定部２４０が設定する構成とすることも可能である。ここで、ＨＷ１０に含まれているＩ／Ｏ１２がハードディスクドライブのようなディスクドライブであるとする。この場合、上述の設定ファイルをユーザの操作により予め作成してディスクドライブ（Ｉ／Ｏ１２）に格納しておき、システム起動時に、ＣＰＵ追加割当時間設定部２４０が当該設定ファイルを当該ディスクドライブから読み込んで、当該設定ファイルに基づいて各ゲストＯＳコンテキスト２４１-jに含まれるＣＰＵ追加割当時間情報２４４を設定すれば良い。

このように、ユーザの操作により予め作成された設定ファイルに基づき、各ゲストＯＳコンテキスト２４１-jに含まれるＣＰＵ追加割当時間情報２４４を設定する手法を適用しても、当該ユーザが各ゲストＯＳ３１-jの処理内容を熟知している場合は、各ゲストＯＳ３１-jに対して適切なＣＰＵ追加割当時間を設定することが可能となるため、システム全体の処理が効率よく進められる。

また、ＣＰＵ追加割当時間情報２４４として有効なＣＰＵ追加割当時間の値が与えられているか否かによって、ゲストＯＳ３１-jに対する受信割り込み発生に伴う割り込み処理の直後に当該ゲストＯＳ３１-jに対して追加のＣＰＵ時間（ＣＰＵ追加割当時間）を付与するか否かを決定することも可能である。

次に、図１の仮想計算機システムにおける動作の概要について説明する。
まず、あるゲストＯＳ３１-jが他のゲストＯＳ（送信側ゲストＯＳ）３１-iからのゲストＯＳ間通信の送信データをＶＭＭ２０を介して受け取ったものとする。このような場合、ＶＭＭ２０内の割り込み管理部２３は、送信側ゲストＯＳ３１-iからの送信データの受信をゲストＯＳ３１-j（つまり受信側ゲストＯＳ３１-j）に通知するために当該受信側ゲストＯＳ３１-jへの割り込み（受信割り込み）を発生する。

多くの通信形態では、受信側ゲストＯＳ３１-jは、データ受信後に受信データ（例えばパケットデータ）の解析やアクナレッジ（ＡＣＫ）の返信のような受信に伴う処理（受信処理）を行う必要がある。一般にゲストＯＳは仮想計算機実行環境でない通常の計算機環境で動作するものをベースにしている場合が多い。このようなゲストＯＳは、割り込み処理と受信処理とを別々に実装していることが多い。そのため従来技術では、受信側ゲストＯＳ３１-jによる受信処理の大部分は、データを受信した直後ではなくて、割り込み解除後に行われるのが一般的である。

図４は、ＣＰＵ時間割当テーブル２２２によって表されるゲストＯＳ３１-1〜３２-3を対象とするスケジュール（ＣＰＵ時間割り当てスケジュール）の問題を説明するための図である。図４において、時点ｔ0は現在時点であり、時点ｔ0から２４ｍｓ先の時点ｔnまでの時間２４ｍｓは、２ｍｓ毎に１２分割されて管理される。図４の例では、時点ｔ0から、ＣＰＵ時間が３個のゲストＯＳ３１-1〜３１-3に２ｍｓ単位でゲストＯＳ３１-2→ゲストＯＳ３１-3→ゲストＯＳ３１-1→ゲストＯＳ３１-2…のようにラウンドロビンで割り当てられることが予定されている。

さて、時点ｔ0でゲストＯＳ３１-2にＣＰＵ１１が割り当てられた結果、当該ゲストＯＳ３１-2の実行が開始されたものとする。そして、時点ｔ0から例えば１ｍｓが経過した時点ｔ1で、ゲストＯＳ（送信側ゲストＯＳ）３１-2がゲストＯＳ（受信側ゲストＯＳ）３１-1に対してＶＭＭ２０を経由して通信を行ったものとする。

この場合ＶＭＭ２０の割り込み管理部２３は、受信側ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に含まれている割り込み要因レジスタ２４３のゲストＯＳ間通信受信ビットをＯＮにする。

またＶＭＭ２０のゲストＯＳ実行管理部２２に含まれているディスパッチャ２２３は、従来技術であれば、受信側ゲストＯＳ３１-1が割り込み状態であることを確認して当該ゲストＯＳ３１-1の割り込みハンドラ（図示せず）に一時的にディスパッチする。ゲストＯＳ３１-1の割り込みハンドラは、当該ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に含まれている割り込み要因レジスタ２４３のゲストＯＳ間通信受信ビットのＯＮ状態に基づき割り込み要因を確認し、当該受信ビットをＯＦＦする割り込み処理を行う。そしてゲストＯＳ３１-1の割り込みハンドラは割り込み処理後、早い段階（実際の受信処理を行う前に）で割り込み解除をＶＭＭ２０に通知する。

従来技術では、ＶＭＭ２０のディスパッチャ２２３はゲストＯＳ３１-1から割り込み解除の通知を受けた場合、当該ゲストＯＳ３１-1に一時的に割り当てていたＣＰＵ１１をＣＰＵ時間割当テーブル２２２の示すスケジュールの通りにゲストＯＳ３１-2に返却する。これによりゲストＯＳ３１-2が再びディスパッチされる。ここで、ゲストＯＳ３１-1がゲストＯＳ３１-2からの送信データの受信処理に例えば４ｍｓの時間が必要であるものとする。この場合、従来技術でば、ゲストＯＳ３１-1が受信処理を終了するのは、当該ゲストＯＳ３１-1に２ｍｓのＣＰＵ時間が２回割り当てられて、その２回目のＣＰＵ時間が経過した時点ｔ2である。この時点ｔ2は、図４からも明らかなように、時点ｔ0（つまりＣＰＵ時間割当テーブル２２２の示すスケジュールの開始時点）から１０ｍｓ経過した時点である。

さて、送信側ゲストＯＳ３１-2が、受信側ゲストＯＳ３１-1に送信したデータに対する当該ゲストＯＳ３１-1の受信処理の後に当該ゲストＯＳ３１-1から返されるＡＣＫを待って、自身の処理を再開することがある。ところが従来技術では、受信側ゲストＯＳ３１-1の受信処理が終了するのは時点ｔ0から１０ｍｓが経過した時点ｔ2である。時点ｔ0から時点ｔ2までの間に、送信側ゲストＯＳ３１-2にはＣＰＵ１１が２ｍｓ単位で（つまり２ｍｓのＣＰＵ時間が）２度割り当てられる。

従来技術では、送信側ゲストＯＳ３１-2に２度割り当てられるＣＰＵ時間内に、受信側ゲストＯＳ３１-1からＡＣＫが返されない。このため送信側ゲストＯＳ３１-2は、２度割り当てられるＣＰＵ時間において処理を再開できず、ＣＰＵ時間の無駄が生じる。このことから本発明者は、ゲストＯＳ間通信が行われる場合に、受信側ゲストＯＳでの受信処理は迅速に行われた方が有利であることを認識するに至った。

そこで本実施形態では、受信側ゲストＯＳ３１-1へのゲストＯＳ間通信の割り込みが発生する場合、当該割り込みに対応する割り込み処理の終了に伴う割り込み解除後も当該ゲストＯＳ３１-1に追加でＣＰＵ時間が割り当てられるように、ＶＭＭ２０のゲストＯＳスケジューラ２２１によってＣＰＵ時間割当テーブル２２２が変更される。

図５は、変更後のＣＰＵ時間割当テーブル２２２によって表されるスケジュールの例を示す。図５の例では、時点ｔ1で受信側ゲストＯＳ３１-1への受信割り込みが発生し、その時点ｔ1から受信処理に必要な４ｍｓが経過する時点ｔ3までの期間、当該ゲストＯＳ３１-1にＣＰＵ時間（ＣＰＵ追加割当時間）が割り当てられる。この結果、ＣＰＵ時間割当テーブル２２２の示すスケジュールの開始時点ｔ0から５ｍｓ経過した時点ｔ3までの間に、受信側ゲストＯＳ３１-1は受信処理を完了させることができる。

このように本実施形態においては、受信側ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に含まれているＣＰＵ追加割当時間情報２４４に基づいてＣＰＵ時間割当テーブル２２２を変更することにより、図５に示されるようにＣＰＵ時間割り当てのスケジュールを変更するようにしている。これにより、ＣＰＵ時間割当テーブル２２２を変更せずに、図４で示されるような、元のＣＰＵ時間割当テーブル２２２の示すスケジュールの通りに受信側ゲストＯＳ３１-1をディスパッチする場合に比べて、当該ゲストＯＳ３１-1の受信処理を早く完了させることができる。この結果、送信側ゲストＯＳ３１-2の処理も、早く進めさせることができる。

次に、上述のような、受信側のゲストＯＳの受信処理を早く完了させるためのスケジュール調整処理の手順について、図６のフローチャートを参照して説明する。
まず、送信側ゲストＯＳ３１-2が、受信側ゲストＯＳ３１-1との間のゲストＯＳ間通信のために、ＶＭＭ２０に対してゲストＯＳ間通信ＩＦ２１０の呼び出しを行ったものとする。本実施形態において、このゲストＯＳ間通信ＩＦ２１０の呼び出しは、送信側ゲストＯＳ３１-2からＶＭＭ２０に対してゲストＯＳ間通信ＩＦコール命令を発行することにより実現される。

ＶＭＭ２０のゲストＯＳ間通信管理部２１は送信側ゲストＯＳ３１-2からのゲストＯＳ間通信ＩＦの呼び出しを受けて、当該ゲストＯＳ３１-2及び受信側となるゲストＯＳ３１-1の各々に対して、それぞれゲストＯＳ間通信ＩＦ２１０を提供する（ステップＳ１）。これにより送信側ゲストＯＳ３１-2は、ゲストＯＳ間通信ＩＦ２１０を用いて、ＶＭＭ２０を介して受信側ゲストＯＳ３１-1（の受信バッファ）にデータを送信することができる。

するとＶＭＭ２０の割り込み管理部２３は、受信側ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に含まれている割り込み要因レジスタ２４３のゲストＯＳ間通信受信ビットをＯＮにする（ステップＳ２）。

さて、ＶＭＭ２０のゲストＯＳスケジューラ２２１は、受信側ゲストＯＳ３１-1への何らかの割り込みの要因が発生すると、ディスパッチャ２２３が受信側ゲストＯＳ３１-1への割り込み発生に伴う当該ゲストＯＳ３１-1のディスパッチを発生させる直前に、ステップＳ１１を実行する。このステップＳ１１においてゲストＯＳスケジューラ２２１は、受信側ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に含まれている割り込み要因レジスタ２４３のゲストＯＳ通信受信ビットがＯＮ状態にあるかを判定する。つまりステップＳ１１においてゲストＯＳスケジューラ２２１は、受信側ゲストＯＳ３１-1への割り込みの要因が、受信割り込みによる通知が必要な、当該受信側ゲストＯＳ３１-1でのゲストＯＳ間通信の受信であるかを判定する。なお、受信側ゲストＯＳ３１-1への割り込み（受信割り込み）がいつ発生するかはシステムの実装に依存し、上記ステップＳ２の直後である必要はない。

もし、受信割り込みビットがＯＮ状態にあり、したがって受信側ゲストＯＳ３１-1への割り込みの要因がゲストＯＳ間通信の受信であるならば（ステップＳ１１）、ゲストＯＳスケジューラ２２１はステップＳ１２を実行する。このステップＳ１２においてゲストＯＳスケジューラ２２１は、受信側ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に含まれているＣＰＵ追加割当時間情報２４４が有効なＣＰＵ追加割当時間の値を示しているかを判定する。

もし、ＣＰＵ追加割当時間情報２４４が有効なＣＰＵ追加割当時間の値を示しているならば（ステップＳ１２）、ゲストＯＳスケジューラ２２１は、そのＣＰＵ追加割当時間の値に基づいて、上述のようなＣＰＵ時間割当テーブル２２２の変更を行う（ステップＳ１３）。ここでは、受信側ゲストＯＳ３１-1への割り込み（受信割り込み）発生に伴う割り込み処理の直後に、ＣＰＵ追加割当時間情報２４４の示すＣＰＵ時間（ＣＰＵ追加割当時間）が当該ゲストＯＳ３１-1に割り当てられるように、ＣＰＵ時間割当テーブル２２２が変更（更新）される。なお、ＣＰＵ時間割当テーブル２２２の示すスケジュールの範囲内で受信側ゲストＯＳ３１-1に割り当てられるＣＰＵ追加割当時間がまかなえない場合は、更に先のスケジュールを作成することで解決できる。

ゲストＯＳスケジューラ２２１によってＣＰＵ時間割当テーブル２２２が変更されると（ステップＳ１３）、割り込み管理部２３は受信側ゲストＯＳ３１-1への割り込み（受信割り込み）を発生する（ステップＳ１４）。

一方、受信割り込みビットがＯＮ状態になく、したがって受信側ゲストＯＳ３１-1への割り込みの要因がゲストＯＳ間通信の受信でないならば（ステップＳ１１）、ステップＳ１２及びＳ１３をスキップして、当該要因に対応する受信側ゲストＯＳ３１-1への割り込み（受信割り込みとは異なる割り込み）が発生される（ステップＳ１４）。また、ステップＳ１２において、ＣＰＵ追加割当時間情報２４４が有効なＣＰＵ追加割当時間の値を示していないと判定されたならば、ステップＳ１３をスキップして、受信側ゲストＯＳ３１-1への割り込み（受信割り込み）が発生される（ステップＳ１４）。

次に上記実施形態で適用される、ゲストＯＳ３１-jに固有のＣＰＵ追加割当時間情報２４４、即ちゲストＯＳ３１-jにおける受信処理に必要なＣＰＵ時間（ＣＰＵ追加割当時間）の値を、常に最適な値に動的に変更することによってシステムの通信を最適化するための処理手順について説明する。

システムの通信は、ゲストＯＳ３１-i及びゲストＯＳ３１-jが定常的に１対１で交互に通信を行う第１のタイプの通信と、複数のゲストＯＳ３１-1〜３１-3が頻繁に通信を行う第２のタイプの通信に大別される。そこで、第１のタイプの通信が行われる状況でのシステムの最適化と、第２のタイプの通信が行われる状況でのシステムの最適化とについて、順次説明する。

＜第１のタイプの通信が行われる状況でのシステムの最適化＞
まず、第１のタイプの通信が行われる状況でシステムを最適化するための処理手順について、図７のフローチャートを参照して説明する。

ＶＭ３０-1〜３０-3上で動作するゲストＯＳ３１-1〜３１-3が第１のタイプの通信（定常的な１対１交互の通信）を行っている状況では、当該ゲストＯＳ３１-1〜３１-3への受信割り込みが定常的に発生する。ゲストＯＳ３１-j（ｊ＝１，２，３）は、当該ゲストＯＳ３１-jへの受信割り込みが発生すると、割り込み処理の直後に前述の受信処理を実行する。ゲストＯＳコンテキスト管理部２４内のＣＰＵ追加割当時間設定部２４０は、ゲストＯＳ３１-jに追加で割り当てられるＣＰＵ時間（ＣＰＵ追加割当時間）が最適値となるように、当該ＣＰＵ追加割当時間の設定値（ＣＰＵ追加割当時間情報２４４）を図７のフローチャートに従う手順で調整する。この調整は、ゲストＯＳ間通信管理部２１内のゲストＯＳ間通信監視部２１１と連携することによって次のように行われる。

まず、ゲストＯＳ間通信監視部２１１は、ゲストＯＳ間の通信を監視することにより、定常的に１対１で通信（第１のタイプの通信）を行っているゲストＯＳを検知する（ステップＳ２１）。このように、定常的に１対１で通信を行っているゲストＯＳを検知するには、例えばゲストＯＳ間通信監視部２１１がゲストＯＳ３１-1〜３１-3からのゲストＯＳ間通信ＩＦ２１０の呼び出しのログを採取すれば良い。ここでは、ゲストＯＳ間通信ＩＦ２１０の呼び出しのログから、例えばゲストＯＳ３１-iとゲストＯＳ３１-jとが交互にゲストＯＳ間通信ＩＦ２１０を呼び出している回数が予め定められた閾値を超えていると判定できるならば、ゲストＯＳ間通信監視部２１１は当該ゲストＯＳ３１-iとゲストＯＳ３１-jとを定常的に１対１で通信（第１のタイプの通信）を行っているゲストＯＳであると検知できる。

ＣＰＵ追加割当時間設定部２４０は、ゲストＯＳ３１-iとゲストＯＳ３１-jとが定常的に１対１で通信（第１のタイプの通信）を行っているゲストＯＳであるとゲストＯＳ間通信監視部２１１によって検知されると（ステップＳ２１）、例えばゲストＯＳ３１-i及び３１-jの双方にそれぞれ固有のＣＰＵ追加割当時間情報２４４を変更して、ＣＰＵ追加割当時間を現在の例えば２倍に設定する（ステップＳ２２）。

この状態でゲストＯＳ間通信監視部２１１は、ゲストＯＳ３１-i及び３１-jの間の通信の状況、例えば通信スループットを観測する（ステップＳ２３）。そしてゲストＯＳ間通信監視部２１１は、通信スループットが改善したか否かを判定する（ステップＳ２４）。本実施形態では通信スループットとして、一定時間当たりの通信回数が用いられる。

もし、スループットが改善したとゲストＯＳ間通信監視部２１１によって判定されたならば（ステップＳ２４）、ＣＰＵ追加割当時間設定部２４０は、ゲストＯＳ３１-i及び３１-j各々のＣＰＵ追加割当時間を更に２倍に設定する（ステップＳ２５ａ）。逆に、スループットが劣化したとゲストＯＳ間通信監視部２１１によって判定されたならば（ステップＳ２４）、ＣＰＵ追加割当時間設定部２４０は、ゲストＯＳ３１-i及び３１-j各々のＣＰＵ追加割当時間を現在の値の半分に設定し直す（ステップＳ２５ｂ）。

いずれの場合においても、ゲストＯＳ間通信監視部２１１は、先のステップＳ２３，Ｓ２４と同様に、通信状況（スループット）の観測及び判定（ステップＳ２６ａ，Ｓ２７ａまたはステップＳ２６ｂ，Ｓ２７ｂ）を行う。

もし、ステップＳ２７ａでスループットが改善したと判定された場合、ＣＰＵ追加割当時間設定部２４０は再びステップＳ２５ａを実行して、ＣＰＵ追加割当時間を更に２倍に設定する。するとゲストＯＳ間通信監視部２１１は通信状況（スループット）の観測及び判定（ステップＳ２６ａ，Ｓ２７ａ）を再び実行する。これに対し、ステップＳ２７ａでスループットが劣化したと判定された場合、ＣＰＵ追加割当時間設定部２４０はＣＰＵ追加割当時間を現在の値の半分に設定し直す（ステップＳ２８ａ）。ＣＰＵ追加割当時間設定部２４０は、ステップＳ２８ａで設定された最新のＣＰＵ追加割当時間値が最適値であるとして、処理を終了する。

一方、ステップＳ２７ｂでスループットが改善したと判定された場合、ＣＰＵ追加割当時間設定部２４０は再びステップＳ２５ｂを実行して、ＣＰＵ追加割当時間を現在の値の半分に設定し直す。するとゲストＯＳ間通信監視部２１１は通信状況（スループット）の観測及び判定（ステップＳ２６ｂ，Ｓ２７ｂ）を再び実行する。これに対し、ステップＳ２７ｂでスループットが劣化したと判定された場合、ＣＰＵ追加割当時間設定部２４０はＣＰＵ追加割当時間を現在の２倍に設定する（ステップＳ２８ｂ）。ＣＰＵ追加割当時間設定部２４０は、ステップＳ２８ｂで設定された最新のＣＰＵ追加割当時間値が最適値であるとして、処理を終了する。

なお、ＣＰＵ追加割当時間の調整範囲に制約を設け、ＣＰＵ追加割当時間が制御可能な範囲を当該調整範囲として設定し、この範囲を超えないようにＣＰＵ追加割当時間を調整することも可能である。

上記実施形態では、第１のタイプの通信を行っているゲストＯＳ３１-i及び３１-jの双方のＣＰＵ追加割当時間が最適値に変更される。しかし、ゲストＯＳ３１-i及び３１-jの一方、例えば主として応答を返す側（受信側）のゲストＯＳのＣＰＵ追加割当時間のみが最適値に変更される構成であっても構わない。この構成では、ゲストＯＳ間通信監視部２１１は、上記通信状況の観測結果に基づき、ゲストＯＳ３１-i及び３１-jの一方が応答を返す側となる割合が予め定められた閾値を超えているかを調べることによって、当該一方が主として受信側ゲストＯＳであるかを判定すれば良い。

＜第２のタイプの通信が行われる状況でのシステムの最適化＞
ゲストＯＳ３１-1〜３１-3が第２のタイプの通信を行っている状況（頻繁に通信を行っている状況）では、頻繁に受信割り込みによるディスパッチが発生する。このような状況では、ディスパッチそれ自体にかかるオーバヘッドの影響によってシステム性能の低下を引き起こす可能性がある。例えば、サーバクライアントモデルの通信は第２のタイプの通信に相当し、このような通信がゲストＯＳ上のアプリケーションで行われているような場合、個々の通信は独立である。

したがって受信側ゲストＯＳへの受信割り込みに伴う割り込み処理の直後に受信処理を行わなくてもシステム全体の動作に矛盾は生じないことが多い。この場合、受信量がある程度溜まってから受信側ゲストＯＳに受信処理をまとめて実行させたほうが、ディスパッチの回数が減ってスループットが改善する可能性がある。

以下、第２のタイプの通信が行われる状況でシステムを最適化するための処理手順について、図８のフローチャートを参照して説明する。

ゲストＯＳ間通信監視部２１１は、ゲストＯＳ間の通信を監視することにより、通信量が多いために受信割り込みの回数が多くなったこと、つまりゲストＯＳ間で頻繁に通信（第２のタイプの通信）が行われていることを検知する（ステップＳ３１）。このような通信を検知するには、例えばゲストＯＳ間通信監視部２１１がゲストＯＳ３１-1〜３１-3からのゲストＯＳ間通信ＩＦ２１０の呼び出しのログを採取すれば良い。ここでは、ゲストＯＳ間通信ＩＦ２１０の呼び出しのログから、一定時間当たりの受信割り込みの回数が予め定められた閾値を超えていると判定できるならば、ゲストＯＳ間通信監視部２１１はゲストＯＳ３１-1〜３１-3の間で頻繁に通信（第２のタイプの通信）が行われていると検知できる。ここでは、ゲストＯＳ３１-1がサーバとして動作し、ゲストＯＳ３１-2及び３１-3がクライアントとして動作しているものとする。つまり、ゲストＯＳ３１-2及び３１-3が送信側、ゲストＯＳ３１-1が受信側として、それぞれ動作している
ＣＰＵ追加割当時間設定部２４０は、ゲストＯＳ３１-1〜３１-3の間の頻繁な通信（第２のタイプの通信）がゲストＯＳ間通信監視部２１１によって検知されると（ステップＳ３１）、ステップＳ３２を実行する。このステップＳ３２においてＣＰＵ追加割当時間設定部２４０は、受信側ゲストＯＳ３１-1への受信割り込みを発生させるために必要な受信量の閾値（受信量閾値）を例えば現在の値の２倍に設定すると共に、当該ゲストＯＳ３１-1に固有のＣＰＵ追加割当時間情報２４４を変更して、ＣＰＵ追加割当時間を現在の例えば２倍に設定する。つまりＣＰＵ追加割当時間設定部２４０は、ゲストＯＳ３１-1の受信量閾値及びＣＰＵ追加割当時間を、いずれも現在の値の２倍に設定する。

この状態でゲストＯＳ間通信監視部２１１は、ゲストＯＳ３１-1とゲストＯＳ３１-2及び３１-3の間の通信の状況、例えば通信スループットを観測する（ステップＳ３３）。そしてゲストＯＳ間通信監視部２１１は、通信スループットが改善したか否かを判定する（ステップＳ３４）。本実施形態では通信スループットとして、前述したように一定時間当たりの通信回数が用いられる。

もし、スループットが改善したとゲストＯＳ間通信監視部２１１によって判定されたならば（ステップＳ３４）、ＣＰＵ追加割当時間設定部２４０は、ゲストＯＳ３１-1の受信量閾値及びＣＰＵ追加割当時間を、いずれも現在の値の２倍に設定する（ステップＳ３５ａ）。逆に、スループットが劣化したとゲストＯＳ間通信監視部２１１によって判定されたならば（ステップＳ３４）、ＣＰＵ追加割当時間設定部２４０は、ゲストＯＳ３１-1の受信量閾値及びＣＰＵ追加割当時間を、いずれも現在の値の半分に設定し直す（ステップＳ３５ｂ）。

いずれの場合においても、ゲストＯＳ間通信監視部２１１は、先のステップＳ３２，Ｓ３３と同様に、通信状況（スループット）の観測及び判定（ステップＳ３６ａ，Ｓ３７ａまたはステップＳ３６ｂ，Ｓ３７ｂ）を行う。

もし、ステップＳ３７ａでスループットが改善したと判定された場合、ＣＰＵ追加割当時間設定部２４０は再びステップＳ３５ａを実行して、ゲストＯＳ３１-1の受信量閾値及びＣＰＵ追加割当時間を更に２倍に設定する。するとゲストＯＳ間通信監視部２１１は通信状況（スループット）の観測及び判定（ステップＳ３６ａ，Ｓ３７ａ）を再び実行する。これに対し、ステップＳ３７ａでスループットが劣化したと判定された場合、ＣＰＵ追加割当時間設定部２４０はゲストＯＳ３１-1の受信量閾値及びＣＰＵ追加割当時間を現在の値の半分に設定し直す（ステップＳ３８ａ）。ＣＰＵ追加割当時間設定部２４０は、ステップＳ３８ａで設定された最新の受信量閾値及びＣＰＵ追加割当時間値が最適値であるとして、処理を終了する。

一方、ステップＳ３７ｂでスループットが改善したと判定された場合、ＣＰＵ追加割当時間設定部２４０は再びステップＳ３５ｂを実行して、ゲストＯＳ３１-1の受信量閾値及びＣＰＵ追加割当時間を現在の値の半分に設定し直す。するとゲストＯＳ間通信監視部２１１は通信状況（スループット）の観測及び判定（ステップＳ３６ｂ，Ｓ３７ｂ）を再び実行する。これに対し、ステップＳ３７ｂでスループットが劣化したと判定された場合、ＣＰＵ追加割当時間設定部２４０はゲストＯＳ３１-1の受信量閾値及びＣＰＵ追加割当時間を現在の２倍に設定する（ステップＳ３８ｂ）。ＣＰＵ追加割当時間設定部２４０は、ステップＳ３８ｂで設定された最新の受信量閾値及びＣＰＵ追加割当時間値が最適値であるとして、処理を終了する。

なお、ＣＰＵ追加割当時間に関しては、調整範囲に制約を設け、ＣＰＵ追加割当時間が制御可能な範囲を当該調整範囲として設定し、この範囲を超えないようにＣＰＵ追加割当時間を調整することも可能である。

［第１の変形例］
次に、上記実施形態の第１の変形例について説明する。
上記実施形態では、ゲストＯＳ間通信の受信側ゲストＯＳ３１-jに追加で割り当てられるＣＰＵ時間（つまりＣＰＵ追加割当時間）がＶＭＭ２０側で動的に調整される。しかし、ゲストＯＳ間通信の送信側ゲストＯＳ３１-iが、受信側ゲストＯＳ３１-jでのデータ受信に伴う受信処理に必要な時間（ＣＰＵ時間）を予測して当該受信側ゲストＯＳ３１-jのＣＰＵ追加割当時間を調整することも可能である。このような調整手法は、受信側ゲストＯＳ３１-jの受信処理に必要なＣＰＵ時間量が送信側ゲストＯＳ３１-iからの通信の内容に依存する場合に最適であり、より精度の高い時間指定が期待できる。

第１の変形例の特徴は、受信側ゲストＯＳ３１-jの臨時のＣＰＵ追加割当時間を送信側ゲストＯＳ３１-iが指定することにある。以下、送信側ゲストＯＳ３１-iによる受信側ゲストＯＳ３１-jの臨時のＣＰＵ追加割当時間指定及び当該指定に基づくスケジュール調整の手順について、図９のフローチャートを参照して説明する。

ゲストＯＳ間通信の送信側のゲストＯＳ３１-iは、受信側ゲストＯＳ３１-jとのゲストＯＳ間通信のためにＶＭＭ２０に対してゲストＯＳ間通信ＩＦ２１０を呼ぶ際には、当該受信側ゲストＯＳ３１-jに対して行おうとしている通信の内容から当該受信側ゲストＯＳ３１-jでの受信処理に要する時間を予測する。送信側のゲストＯＳ３１-iは、予測された時間を受信側ゲストＯＳ３１-jに割り当てられるべきＣＰＵ時間（ＣＰＵ追加割当時間）として、例えばゲストＯＳ間通信ＩＦコール命令の引数により指定し、当該コール命令をＶＭＭ２０に対して発行することで、ゲストＯＳ間通信ＩＦ２１０を呼ぶ。

するとＶＭＭ２０のゲストＯＳ間通信管理部２１は、送信側のゲストＯＳ３１-2及び受信側ゲストＯＳ３１-1の各々に対して、それぞれゲストＯＳ間通信ＩＦ２１０を提供する（ステップＳ４１）。割り込み管理部２３は、受信側ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に含まれている割り込み要因レジスタ２４３のゲストＯＳ間通信受信ビットをＯＮにする（ステップＳ４２）。このステップＳ４２において、ＣＰＵ追加割当時間設定部２４０は、送信側のゲストＯＳ３１-2から指定されたＣＰＵ時間の値を受信側ゲストＯＳ３１-1の臨時のＣＰＵ追加割当時間の値として設定する。ここでは、指定された臨時のＣＰＵ追加割当時間の値が、受信側ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1の一部として設定される。しかし、臨時のＣＰＵ追加割当時間の値が、ゲストＯＳコンテキスト２４１-1とは別に受信側ゲストＯＳ３１-1に対応付けて用意されるロケーション（物理的にはメモリ１３内の特定の領域）に設定される構成であっても構わない。

その後、ＶＭＭ２０のゲストＯＳスケジューラ２２１は、ディスパッチャ２２４が受信側ゲストＯＳ３１-1への割り込み発生に伴う当該ゲストＯＳ３１-1のディスパッチを発生させる直前に、当該ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に含まれている割り込み要因レジスタ２４３のゲストＯＳ通信受信ビットがＯＮ状態にあるかを判定する（ステップＳ５１）。

もし、受信割り込みビットがＯＮ状態にある場合、つまり受信側ゲストＯＳ３１-1への割り込みの要因がゲストＯＳ間通信の受信である場合（ステップＳ５１）、ゲストＯＳスケジューラ２２１はステップＳ５２を実行する。このステップＳ５２においてゲストＯＳスケジューラ２２１は、受信側ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に設定されている臨時のＣＰＵ追加割当時間の値が有効な値であるかを判定する。

もし、臨時のＣＰＵ追加割当時間の値が有効な値であるならば（ステップＳ５２）、ゲストＯＳスケジューラ２２１は、当該臨時のＣＰＵ追加割当時間の値に基づき、上記実施形態のステップＳ１３と同様に、ＣＰＵ時間割当テーブル２２２の変更を行う（ステップＳ５４）。ここでは、受信側ゲストＯＳ３１-1への受信割り込み発生に伴う割り込み処理の直後に、上記ステップＳ１３と異なって（ＣＰＵ追加割当時間情報２４４の示すＣＰＵ時間ではなくて）、臨時のＣＰＵ追加割当時間が当該ゲストＯＳ３１-1に割り当てられるように、ＣＰＵ時間割当テーブル２２２が変更される。

これに対し、臨時のＣＰＵ追加割当時間の値が有効な値でないならば（ステップＳ５２）、ゲストＯＳスケジューラ２２１は、上記実施形態のステップＳ１２と同様に、受信側ゲストＯＳ３１-1に固有のゲストＯＳコンテキスト２４１-1に含まれているＣＰＵ追加割当時間情報２４４が有効なＣＰＵ追加割当時間の値を示しているかを判定する（ステップＳ５３）。

もし、ＣＰＵ追加割当時間情報２４４が有効なＣＰＵ追加割当時間の値を示しているならば（ステップＳ５３）、ゲストＯＳスケジューラ２２１は、そのＣＰＵ追加割当時間の値に基づいて、上記実施形態のステップＳ１３と同様にＣＰＵ時間割当テーブル２２２の変更を行う（ステップＳ５４）。

ゲストＯＳスケジューラ２２１はＣＰＵ時間割当テーブル２２２を変更すると、ＣＰＵ追加割当時間設定部２４０によりゲストＯＳコンテキスト２４１-1からＣＰＵ追加割当時間の設定値を削除させる（ステップＳ５５）。ＣＰＵ追加割当時間設定部２４０は、ゲストＯＳコンテキスト２４１-1にＣＰＵ追加割当時間の値が設定されているならば、その設定値を削除する。すると割り込み管理部２３は、受信側ゲストＯＳ３１-1への割り込み（受信割り込み）を発生する（ステップＳ５６）。

一方、受信割り込みビットがＯＮ状態にないならば（ステップＳ５１）、ＣＰＵ時間割当テーブル２２２が変更されることなくステップＳ５６が実行されて、受信側ゲストＯＳ３１-1への割り込み（受信割り込みとは異なる割り込み）が発生される。また、ステップＳ５３において、ＣＰＵ追加割当時間情報２４４が有効なＣＰＵ追加割当時間の値を示していないと判定された場合にも、ＣＰＵ時間割当テーブル２２２が変更されることなくステップＳ５６が実行されて、受信側ゲストＯＳ３１-1への割り込み（受信割り込み）が発生される。

［第２の変形例］
次に、上記実施形態の第２の変形例について説明する。
上記実施形態では、受信側ゲストＯＳの受信割り込み処理の後に行われる受信処理のために、当該受信側ゲストＯＳに追加でＣＰＵ時間（ＣＰＵ追加割当時間）が割り当てられる。このため、不当にＣＰＵ時間を奪われる他のゲストＯＳが存在する可能性がある。

図５の例では、時点ｔ0から１ｍｓが経過した時点ｔ1で、ゲストＯＳ３１-1に追加でＣＰＵ時間（ＣＰＵ追加割当時間）が割り当てられた結果、ゲストＯＳ３１-2及びゲストＯＳ３１-3に割り当てられるべきＣＰＵ時間が当該ゲストＯＳ３１-2及びゲストＯＳ３１-3から奪われている。このような場合、ＣＰＵ時間を奪われたゲストＯＳ３１-2及びゲストＯＳ３１-3のうちのゲストＯＳ３１-3は、ゲストＯＳ３１-1（追加でＣＰＵ時間が割り当てられたゲストＯＳ３１-1）とゲストＯＳ３１-2との間で行われるゲストＯＳ間通信とは無関係であるのに、当該ゲストＯＳ３１-3の性能が低下する可能性がある。このような性能低下は、特にゲストＯＳ３１-3がリアルタイム性を要求される処理を行っている場合に問題となる。

第２の変形例の特徴は、追加でＣＰＵ時間が割り当てられるゲストＯＳを第１のゲストＯＳ、ＣＰＵ時間を奪われるゲストＯＳを第２のゲストＯＳと呼ぶものとすると、第２のゲストＯＳから奪われるＣＰＵ時間を、第１のゲストＯＳに割り当てられる予定のＣＰＵ時間で埋め合わせることにある。この埋め合わせは、第２のゲストＯＳから奪われるＣＰＵ時間を、当該奪われるＣＰＵ時間の割り当てが予定されていた時間帯（割り当て予定時間帯）に最も近い時間帯に第１のゲストＯＳに割り当てられる予定のＣＰＵ時間と交換することにより実現される。

以下、第２のゲストＯＳから奪われるＣＰＵ時間を第１のゲストＯＳに割り当てられる予定のＣＰＵ時間と交換することによって実現されるスケジュール調整の手順について、図１０のフローチャートを参照して説明する。

今、送信側ゲストＯＳ３１-2からの通信に伴う送信データが受信側ゲストＯＳ３１-1で受信され、当該受信側ゲストＯＳ３１-1に受信割り込みが発生したものとする。この場合、スケジュールの変更の必要が発生する。

するとゲストＯＳスケジューラ２２１は、受信側ゲストＯＳ３１-1での割り込み処理後に行われる受信処理に必要なＣＰＵ割当時間が現在受信側ゲストＯＳ３１-1用に設定されているＣＰＵ追加割当時間では不足しているかを判定する（ステップＳ６１）。ここで、受信側ゲストＯＳ３１-1での割り込み処理後の受信処理に必要なＣＰＵ割当時間の値は、ゲストＯＳコンテキスト２４１-1に含まれているＣＰＵ追加割当時間情報２４４によって示される。また、ステップＳ６１が最初に実行される段階では、受信側ゲストＯＳ３１-1用に設定されているＣＰＵ追加割当時間の時間帯は存在しない。

もし、受信側ゲストＯＳ３１-1での割り込み処理後の受信処理に必要なＣＰＵ割当時間が不足しているならば、ゲストＯＳスケジューラ２２１はステップＳ６２の処理を実行する。このステップＳ６２においてゲストＯＳスケジューラ２２１は、ＣＰＵ時間割当テーブル２２２を参照することにより、受信側ゲストＯＳ３１-1用のＣＰＵ追加割当時間の時間帯外で、最も近い将来に受信側ゲストＯＳ３１-1に割り当てられる予定の時間帯となるＣＰＵ時間（ディスパッチ予定時間）を探す。

次にゲストＯＳスケジューラ２２１は、現在受信側ゲストＯＳ３１-1用に設定されているＣＰＵ追加割当時間の時間帯の直後に他のゲストＯＳに割り当てられるように予定されているＣＰＵ時間を、ステップＳ６２で探し求められた、受信側ゲストＯＳ３１-1に割り当てられる予定のＣＰＵ時間とを入れ替える（ステップＳ６３）。つまり、ゲストＯＳスケジューラ２２１は、ＣＰＵ追加割当時間の時間帯の直後に他のゲストＯＳに割り当てられるように予定されているＣＰＵ時間を受信側ゲストＯＳ３１-1用のＣＰＵ追加割当時間に追加し、ステップＳ６２で探し求められた、受信側ゲストＯＳ３１-1に割り当てられる予定のＣＰＵ時間を当該他のゲストＯＳ用に変更する操作を、ＣＰＵ時間割当テーブル２２２上で行う。ステップＳ６３が最初に実行される段階では、受信側ゲストＯＳ３１-1用に設定されているＣＰＵ追加割当時間の時間帯は存在しない。この場合、ＣＰＵ追加割当時間の時間帯の直後に他のゲストＯＳに割り当てられるように予定されているＣＰＵ時間の時間帯は、送信側ゲストＯＳ３１-2が受信側ゲストＯＳ３１-1に対して通信を行った時点が属するＣＰＵ時間の時間帯であり、送信側ゲストＯＳ３１-2用のＣＰＵ時間の時間帯である。

ゲストＯＳスケジューラ２２１は、上述のステップＳ６２及びＳ６３を、受信側ゲストＯＳ３１-1に追加で割り当てられるＣＰＵ時間（ＣＰＵ追加割当時間）が不足しなくなるまで（ステップＳ６１）、繰り返す。

図１１は、図１０のフローチャートの示す手順に従ってゲストＯＳ３１-1〜３２-3を対象とするスケジュールが調整された際の調整前後のスケジュールの例を示す。図１１の例では、時点ｔ10においてゲストＯＳ３１-2に２ｍｓのＣＰＵ時間が割り当てられる。このＣＰＵ時間割り当ての直後にゲストＯＳ３１-2がゲストＯＳ３１-1への通信を行ったものとする。

割り込み管理部２３は、この時点（ｔ10の時点）で受信側ゲストＯＳ３１-1へのゲストＯＳ間通信の受信割り込みを発生する。するとゲストＯＳスケジューラ２２１によって、ＣＰＵ時間割当テーブル２２２の示すスケジュールの調整が行われる。この調整では、図１１（ａ）において矢印１１１で示されるように、時点ｔ10に送信側ゲストＯＳ３１-2に割り当てられる予定の（割り当てられた）時点ｔ10から時点ｔ11（＝ｔ10＋２ｍｓ）までの時間帯の２ｍｓのＣＰＵ時間と、時点ｔ12に受信側ゲストＯＳ３１-1に割り当てられる予定の時点ｔ12（＝ｔ10＋４ｍｓ）から時点ｔ13（＝ｔ10＋６ｍｓ）までの時間帯の２ｍｓのＣＰＵ時間との入れ替えが行われる。同様に、図１１（ａ）において矢印１１２で示されるように、時点ｔ11（＝ｔ10＋２ｍｓ）にゲストＯＳ３１-3に割り当てられる予定の時点ｔ11（＝ｔ10＋２ｍｓ）から時点ｔ12（＝ｔ10＋４ｍｓ）までの時間帯の２ｍｓのＣＰＵ時間と、時点ｔ14（＝ｔ10＋１０ｍｓ）に受信側ゲストＯＳ３１-1に割り当てられる予定の時点ｔ14（＝ｔ10＋１０ｍｓ）から時点ｔ15（＝ｔ10＋１２ｍｓ）までの時間帯の２ｍｓのＣＰＵ時間との入れ替えが行われる。

これにより、図１１（ｂ）に示されるように、時点ｔ10での受信割り込み直後に、時点ｔ10から時点ｔ12までの、本来ゲストＯＳ３１-2及び３１-3に順に割り当てられる予定の４ｍｓのＣＰＵ時間が、受信側ゲストＯＳ３１-1に割り当てられる。これとは逆に、本来受信側ゲストＯＳ３１-1に割り当てられる予定の、時点ｔ12から時点ｔ13までの２ｍｓのＣＰＵ時間及び時点ｔ14から時点ｔ15までの２ｍｓのＣＰＵ時間が、図１１（ｂ）に示されるように、それぞれゲストＯＳ３１-2及び３１-3に割り当てられる。

このように、図１１の例では、時点ｔ11での受信割り込み直後に、受信側ゲストＯＳ３１-1に、当該ゲストＯＳ３１-1での受信処理に必要な（ゲストＯＳコンテキスト２４１-1に含まれているＣＰＵ追加割当時間情報２４４の示す）値のＣＰＵ時間が割り当てられるように、ＣＰＵ時間割当テーブル２２２の示すスケジュールが変更される。また、スケジュールされた範囲内において、ゲストＯＳ３１-1〜３１-3の各々に割り当てられるＣＰＵ時間量は均等に保たれる。

上記第２の変形例では、説明の簡略化のために、ゲストＯＳ３１-1〜３１-3に本来割り当てられる予定のＣＰＵ時間単位で交換が行われることを前提としている。しかし、受信割り込みは、実行中のゲストＯＳに割り当てられているＣＰＵ時間の途中で発生することが一般的である。また、各ゲストＯＳに割り当てられるＣＰＵ時間も、ゲストＯＳ毎に異なることも考えられる。このような場合、ゲストＯＳスケジューラ２２１は、各ゲストＯＳに割り当てられる予定のＣＰＵ時間を必要な時間量（例えばゲストＯＳスケジューラ２２１が管理する最小時間単位）に分割してスケジュールの調整をすれば良い。なお、スケジュールの範囲内で受信側ゲストＯＳに割り当てられるＣＰＵ時間がまかなえない場合は、更に先のスケジュールを作成することで解決できる。

［第３の変形例］
次に、上記実施形態の第３の変形例について説明する。第３の変形例の特徴は、受信側ゲストＯＳへの受信割り込み時に当該ゲストＯＳに追加で割り当てられるＣＰＵ時間を、送信側ゲストＯＳに割り当てられる予定のＣＰＵ時間でまかなうことにある。このように第３の変形例では、受信側ゲストＯＳの受信割り込み処理の後に行われる受信処理用に、送信側ゲストＯＳに割り当てられる予定のＣＰＵ時間を譲渡する手法が適用される。この手法は、例えば、送信側ゲストＯＳの処理の進行に受信側ゲストＯＳの応答が必要な場合の通信モデルに適用できる。また、この手法は、受信側ゲストＯＳ（ＣＰＵ時間が追加で割り当てられる受信側ゲストＯＳ）が関係するゲストＯＳ間通信とは無関係のゲストＯＳに対するＣＰＵ時間の割り当てに影響を与えない。

以下、送信側ゲストＯＳに割り当てられる予定のＣＰＵ時間を受信側ゲストＯＳの受信処理用に譲渡することによって実現されるスケジュール調整の手順について、図１２のフローチャートを参照して説明する。

今、ゲストＯＳ３１-1がゲストＯＳ（送信側ゲストＯＳ）３１-2からの通信の送信データを受信し、そのゲストＯＳ（受信側ゲストＯＳ）３１-1に受信割り込みが発生したものとする。この場合、第２の変形例と同様にスケジュールの変更の必要が発生する。

するとゲストＯＳスケジューラ２２１は、ＣＰＵ時間割当テーブル２２２を参照して、受信割り込み時点における当該ＣＰＵ時間割当テーブル２２２の示すスケジュール上の位置（つまり現在のスケジュール位置）を確認する（ステップＳ７１）。次にゲストＯＳスケジューラ２２１は、受信割り込み時点から最も最近に確認されたスケジュール位置までに受信側ゲストＯＳ３１-1に割り当てられる予定のＣＰＵ時間（ＣＰＵ割当予定時間）の合計量が、当該ゲストＯＳ３１-1に固有のＣＰＵ追加割当時間情報２４４の示す値（つまりゲストＯＳ３１-1の受信処理に必要な時間）以上であるかを判定する（ステップＳ７２）。

もし、上述のＣＰＵ割当予定時間の合計量が、ゲストＯＳ３１-1の受信処理に必要な時間に満たないならば（ステップＳ７２）、ゲストＯＳスケジューラ２２１は、最も最近に確認されたスケジュール位置が送信側ゲストＯＳ３１-2にＣＰＵ時間が割り当てられるディスパッチ予定位置であるかを判定する（ステップＳ７３）。もし、このステップＳ７３での判定がＹＥＳであるならば、ゲストＯＳスケジューラ２２１は、ＣＰＵ時間割当テーブル２２２の示す該当する送信側ゲストＯＳ３１-2用のスケジュール位置（ここでは現在のスケジュール位置）を受信側ゲストＯＳ３１-1（へのディスパッチ予定）用に変更する（ステップＳ７４）。つまりＣＰＵ時間割当テーブル２２２は、本来送信側ゲストＯＳ３１-2に割り当てられるべき２ｍｓのＣＰＵ時間を、受信側ゲストＯＳ３１-1に譲渡させる。この変更（譲渡）により、受信割り込み時点から最も最近に確認されたスケジュール位置までにおける受信側ゲストＯＳ３１-1へのＣＰＵ割当予定時間の合計量が２ｍｓだけ増加する。

ゲストＯＳスケジューラ２２１は、ステップＳ７４を実行するとステップＳ７５に進む。これに対し、ステップＳ７３での判定がＮＯであるならば、ゲストＯＳスケジューラ２２１は、ステップＳ７４をスキップしてステップＳ７５に進む。なお、ステップＳ７３での判定がＮＯであっても、最も最近に確認されたスケジュール位置が受信側ゲストＯＳ３１-1にＣＰＵ時間が割り当てられるディスパッチ予定位置であるならば、受信割り込み時点から最も最近に確認されたスケジュール位置までにおける受信側ゲストＯＳ３１-1へのＣＰＵ割当予定時間の合計量は２ｍｓだけ増加する。

ステップＳ７５においてゲストＯＳスケジューラ２２１は、ＣＰＵ時間割当テーブル２２２の次のスケジュール位置を確認する。するとゲストＯＳスケジューラ２２１は、ステップＳ７１で現在のスケジュール位置が確認された場合と同様に、ステップＳ７２以降の処理を行う。

即ちゲストＯＳスケジューラ２２１は、上述のような受信側ゲストＯＳ３１-1へのＣＰＵ割当予定時間の合計量が、当該ゲストＯＳ３１-1の受信処理に必要な時間に対して依然として不足しているかを判定する（ステップＳ７２）。

もし、上述のような受信側ゲストＯＳ３１-1へのＣＰＵ割当予定時間の合計量が不足しているならば（ステップＳ７２）、ゲストＯＳスケジューラ２２１は、最も最近に確認されたスケジュール位置、つまりステップＳ７５で確認された次のスケジュール位置が、送信側ゲストＯＳ３１-2にＣＰＵ時間が割り当てられるスケジュール位置であるかを判定する（ステップＳ７３）。もし、ステップＳ７３の判定がＹＥＳであるならば、ゲストＯＳスケジューラ２２１は、ステップＳ７５で確認された次のスケジュール位置を受信側ゲストＯＳ３１-1用に変更する（ステップＳ７４）。そして、再びステップＳ７５及びＳ７２が行われる。これに対してステップＳ７３の判定がＮＯであるならば、ステップＳ７４をスキップして、再びステップＳ７５及びＳ７２が行われる。

やがて、上述のような受信側ゲストＯＳ３１-1へのＣＰＵ割当予定時間の合計量が、当該ゲストＯＳ３１-1の受信処理に必要な時間以上となったならば（ステップＳ７２）、ゲストＯＳスケジューラ２２１は図１２のフローチャートに従うスケジュール調整処理を終了する。

このように本実施形態においては、ＣＰＵ時間割当テーブル２２２に基づき、受信割り込み発生時点以降にＣＰＵ時間が割り当てられる予定（ディスパッチ予定）のゲストＯＳを順に調べ、送信側ゲストＯＳ３１-2用に割り当てられる予定のＣＰＵ時間を受信側ゲストＯＳ３１-1用に変更する処理を、受信割り込み発生時点以降に当該ゲストＯＳ３１-1に割り当てられることになるＣＰＵ時間（ＣＰＵ割当予定時間）の合計が４ｍｓを超えるまで繰り返す。

図１３は、図１２のフローチャートの示す手順に従ってゲストＯＳ３１-1〜３２-3のうちのゲストＯＳ３１-1及び３１-2を対象とするスケジュールが調整された際の調整前後のスケジュールの例を示す。

今、図１３（ａ）における時点ｔ20、即ちゲストＯＳ３１-2へのＣＰＵ時間の割り当て時点ｔ20の直後に、当該ゲストＯＳ３１-2からゲストＯＳ３１-1への通信を行ったものとする。ＶＭＭ２０の割り込み管理部２３は時点ｔ20で受信側ゲストＯＳ３１-1へのゲストＯＳ間通信の受信割り込みを発生する。するとゲストＯＳスケジューラ２２１によって、ＣＰＵ時間割当テーブル２２２の示すスケジュールの調整が次のように行われる。

まず、割り込み時点（現時点）ｔ20直後、時点ｔ21までの２ｍｓのＣＰＵ時間（つまり現在のスケジュール位置のＣＰＵ時間）が割り当てられるゲストＯＳ３１-2は、送信側ゲストＯＳである。この場合、時点ｔ20から時点ｔ21までの２ｍｓのＣＰＵ時間は、矢印１３０で示されるように、送信側ゲストＯＳ３１-2用から受信側ゲストＯＳ３１-1用に変更される。

次の時点ｔ21から時点ｔ22までの２ｍｓのＣＰＵ時間はゲストＯＳ３１-3用に予定されている。このゲストＯＳ３１-3は、ゲストＯＳ３１-2とゲストＯＳ３１-1との間のゲストＯＳ間通信とは無関係である。このため、ゲストＯＳ３１-3用に予定されているＣＰＵ時間に関してはスケジュール調整は行われない。

次の時点ｔ22から時点ｔ23までの２ｍｓのＣＰＵ時間は、もともと受信側ゲストＯＳ３１-1用に予定されている。したがって、時点ｔ22から時点ｔ23までの対応するスケジュール位置における２ｍｓのＣＰＵ時間を含めて、割り込み時点（現時点）ｔ20から６ｍｓが経過する当該時点ｔ23までに受信側ゲストＯＳ３１-1に割り当てられる予定のＣＰＵ時間の合計は、当該受信側ゲストＯＳ３１-1での割り込み処理直後の受信処理に必要な４ｍｓを充足する。この場合、スケジュールの調整は終了する。

第３の変形例によるスケジュール調整では、受信側ゲストＯＳ３１-1に追加で割り当てられるＣＰＵ時間は連続にはならない。しかし、受信側ゲストＯＳ３１-1との間でゲストＯＳ間通信を行う送信側ゲストＯＳ３１-2よりも先に、当該受信側ゲストＯＳ３１-1にＣＰＵ時間が割り当てられるので一般には問題にならない。

上記第３の変形例では、第２の変形例と同様に、説明の簡略化のために、ゲストＯＳ３１-1〜３１-3に本来割り当てられる予定のＣＰＵ時間単位で譲渡（割り当て予定先のゲストＯＳの変更）が行われることを前提としている。しかし、受信割り込みは、実行中のゲストＯＳに割り当てられているＣＰＵ時間の途中で発生することが一般的である。また、各ゲストＯＳに割り当てられるＣＰＵ時間も、ゲストＯＳ毎に異なることも考えられる。このような場合、ゲストＯＳスケジューラ２２１は、各ゲストＯＳに割り当てられる予定のＣＰＵ時間を必要な時間量（例えばゲストＯＳスケジューラ２２１が管理する最小時間単位）に分割してスケジュールの調整をすれば良い。

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

本発明の一実施形態に係る仮想計算機システムの構成を示すブロック図。 ＣＰＵ時間割当テーブルによって表されるスケジュール例を示す図。 ゲストＯＳコンテキストのデータ構造例を示す図。 ＣＰＵ時間割当テーブルによって表されるスケジュールの問題を説明するための図 変更後のＣＰＵ時間割当テーブルによって表されるスケジュールの例を示す図。 同実施形態におけるスケジュール調整処理の手順を示すフローチャート。 同実施形態において第１のタイプの通信が行われる状況でシステムを最適化するための処理手順を示すフローチャート。 同実施形態において第２のタイプの通信が行われる状況でシステムを最適化するための処理手順を示すフローチャート。 同実施形態の第１の変形例で適用される、送信側ゲストＯＳによる受信側ゲストＯＳの臨時のＣＰＵ追加割当時間指定及び当該指定に基づくスケジュール調整の手順を示すフローチャート。 同実施形態の第２の変形例で適用されるスケジュール調整の手順を示すフローチャート。 図１０のフローチャートの示す手順に従ってスケジュールが調整された際の調整前後のスケジュールの例を示す図。 同実施形態の第３の変形例で適用されるスケジュール調整の手順を示すフローチャート。 図１２のフローチャートの示す手順に従ってスケジュールが調整された際の調整前後のスケジュールの例を示す図。

符号の説明

１…物理計算機、１０…ハードウェア（ＨＷ）、１１…ＣＰＵ（実ＣＰＵ）、２０…仮想計算機マネージャ（ＶＭＭ）、２１…ゲストＯＳ間通信管理部、２２…ゲストＯＳ実行管理部、２３…割り込み管理部、２４…ゲストＯＳコンテキスト管理部、２１０…ゲストＯＳ間通信ＩＦ、２１１…ゲストＯＳ間通信監視部、２２１…ゲストＯＳスケジューラ、２２２…ＣＰＵ時間割当テーブル、２２３…ディスパッチャ、２４０…ＣＰＵ追加割当時間設定部、２４１-1〜２４１-3…ゲストＯＳコンテキスト、２４２…ゲストＯＳ固有データ、２４３…割り込み要因レジスタ、２４４…ＣＰＵ追加割当時間情報。

Claims (12)

1. ＣＰＵを含む物理計算機上で動作する仮想計算機マネージャによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行される仮想計算機システムにおいて、
   前記仮想計算機マネージャは、
   前記複数のゲストＯＳのうちの任意のゲストＯＳへの割り込みを管理する割り込み管理手段であって、送信側ゲストＯＳから前記仮想計算機マネージャに与えられる受信側ゲストＯＳへのゲストＯＳ間通信の要求を受けて、前記受信側ゲストＯＳでの前記ゲストＯＳ間通信の受信を受信割り込みにより通知する割り込み管理手段と、
   前記複数のゲストＯＳを時分割で実行させるためのスケジュールを管理するスケジューラであって、前記複数のゲストＯＳのうちの任意のゲストＯＳへの割り込みの要因が発生し、且つ当該要因が前記ゲストＯＳ間通信の受信である場合に、当該任意のゲストＯＳを前記受信側ゲストＯＳとして、前記受信割り込みの解除後の受信処理に必要なＣＰＵ時間が当該受信側ゲストＯＳに追加で割り当てられるように前記スケジュールを調整するスケジューラと、
   前記スケジューラによって調整された前記スケジュールに従って前記複数のゲストＯＳをディスパッチするディスパッチャと
   を具備することを特徴とする仮想計算機システム。
2. 前記仮想計算機マネージャは、前記複数のゲストＯＳの各々の受信割り込み解除後の受信処理に必要なＣＰＵ時間の値をＣＰＵ追加割当時間設定値として含むゲストＯＳコンテキストを管理するゲストＯＳコンテキスト管理手段を更に具備し、
   前記スケジューラは、前記ゲストＯＳコンテキスト管理手段によって管理される、前記受信側ゲストＯＳの受信割り込み解除後の受信処理に必要なＣＰＵ追加割当時間設定値に基づき前記スケジュールを調整する
   ことを特徴とする請求項１記載の仮想計算機システム。
3. 前記仮想計算機マネージャは、ゲストＯＳ間通信を監視することによって通信スループットを観測するゲストＯＳ間通信監視手段と、
   前記ゲストＯＳ間通信監視手段による通信スループットの観測結果に基づき、対応するゲストＯＳに固有の前記ＣＰＵ追加割当時間設定値を変更するＣＰＵ追加割当時間設定手段と
   を更に具備することを特徴とする請求項２記載の仮想計算機システム。
4. 前記スケジューラは、特定の時間帯において、前記複数のゲストＯＳの各々に対するＣＰＵ時間の割当量がスケジュール調整前後で一定量に保たれるように前記スケジュールを調整することを特徴とする請求項１記載の仮想計算機システム。
5. 前記スケジューラは、前記受信側ゲストＯＳに追加でＣＰＵ時間が割り当てられる第１の時間帯に他のゲストＯＳに割り当てられる予定の第２の時間帯が含まれている場合、前記第２の時間帯と、前記第１の時間帯より後の当該受信側ゲストＯＳに割り当てられる予定の第３の時間帯とを入れ替えることを特徴とする請求項４記載の仮想計算機システム。
6. 前記スケジューラは、前記受信側ゲストＯＳに追加で割り当てられるＣＰＵ時間に、前記送信側ゲストＯＳに割り当てられる予定のＣＰＵ時間を充当することを特徴とする請求項１記載の仮想計算機システム。
7. ＣＰＵを含む物理計算機上で動作する仮想計算機マネージャによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行される仮想計算機システムにおいて、前記複数のゲストＯＳを時分割で実行させるためのスケジュールを調整するスケジュール調整方法であって、
   前記複数のゲストＯＳのうちの任意のゲストＯＳへの割り込みの要因が発生した場合に、当該要因が送信側ゲストＯＳからのゲストＯＳ間通信に伴う前記任意のゲストＯＳでの前記ゲストＯＳ間通信の受信であるかを前記仮想計算機マネージャが判定するステップと、
   前記任意のゲストＯＳへの割り込みの要因がゲストＯＳ間通信の受信である場合に、前記仮想計算機マネージャが、当該任意のゲストＯＳを受信側ゲストＯＳとして、前記ゲストＯＳ間通信の受信を当該受信側ゲストＯＳに通知するための受信割り込みの解除後の受信処理に必要なＣＰＵ時間が当該受信側ゲストＯＳに追加で割り当てられるように前記スケジュールを調整するステップと
   を具備することを特徴とするスケジュール調整方法。
8. 前記調整するステップにおいて前記前記仮想計算機マネージャは、前記仮想計算機マネージャが有するゲストＯＳコンテキスト管理手段によって管理される、前記受信側ゲストＯＳの受信割り込み解除後の受信処理に必要なＣＰＵ時間の設定値に基づき、前記スケジュールを調整する
   ことを特徴とする請求項７記載のスケジュール調整方法。
9. 前記仮想計算機マネージャが、ゲストＯＳ間通信を監視することによって通信スループットを観測するステップと、
   前記通信スループットの観測結果に基づき、前記ゲストＯＳコンテキスト管理手段によって管理される、対応するゲストＯＳに固有の前記ＣＰＵ時間の設定値を前記仮想計算機マネージャが変更するステップと
   を更に具備することを特徴とする請求項８記載のスケジュール調整方法。
10. 前記調整するステップにおいて前記仮想計算機マネージャは、特定の時間帯において、前記複数のゲストＯＳの各々に対するＣＰＵ時間の割当量がスケジュール調整前後で一定量に保たれるように前記ＣＰＵ時間割当テーブルを変更することを特徴とする請求項７記載のスケジュール調整方法。
11. 前記調整するステップにおいて前記仮想計算機マネージャは、前記受信側ゲストＯＳに追加でＣＰＵ時間が割り当てられる第１の時間帯に他のゲストＯＳに割り当てられる予定の第２の時間帯が含まれている場合、前記第２の時間帯と、前記第１の時間帯より後の当該受信側ゲストＯＳに割り当てられる予定の第３の時間帯とを入れ替えることを特徴とする請求項１０記載のスケジュール調整方法。
12. 前記調整するステップにおいて前記仮想計算機マネージャは、前記受信側ゲストＯＳに追加で割り当てられるＣＰＵ時間に、前記送信側ゲストＯＳに割り当てられる予定のＣＰＵ時間を充当することを特徴とする請求項７記載のスケジュール調整方法。

Images