ゲストＯＳスケジューリング方法及び仮想計算機モニタ
【課題】ゲストＯＳ間で通信をしながら処理を進める場合における通信処理効率の向上を図る
【解決手段】仮想計算機モニタによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行される仮想計算機システムにおいて、仮想計算機モニタは、当該仮想計算機モニタが提供する通信機能を用いて相互に通信するゲストＯＳの組を特定する（Ｓ１１〜Ｓ１４）。次に仮想計算機モニタは、上記複数のゲストＯＳのうち、上記特定されたゲストＯＳの組に含まれる各ゲストＯＳの実行スケジュールにおけるクオンタムを短くする（Ｓ１５）。
【解決手段】仮想計算機モニタによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行される仮想計算機システムにおいて、仮想計算機モニタは、当該仮想計算機モニタが提供する通信機能を用いて相互に通信するゲストＯＳの組を特定する（Ｓ１１〜Ｓ１４）。次に仮想計算機モニタは、上記複数のゲストＯＳのうち、上記特定されたゲストＯＳの組に含まれる各ゲストＯＳの実行スケジュールにおけるクオンタムを短くする（Ｓ１５）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想的な計算機実行環境を提供する仮想計算機システムに係り、特に当該仮想的な計算機実行環境で実行されるゲストＯＳ間の通信状況に基づいてゲストＯＳの実行スケジュールを切り替えるゲストＯＳスケジューリング方法及び仮想計算機モニタに関する。
【背景技術】
【０００２】
近年、パーソナルコンピュータのような計算機システムにおいても、仮想計算機（Virtual Machine：ＶＭ）の技術を応用した研究や開発が行われている（例えば、特許文献１参照）。また、ＶＭシステム（仮想計算機システム）を実現するための商用のアプリケーションプログラムが実際に広く利用されている。また、メインフレームで古くからハードウェア（ＨＷ）で構成されたＶＭ支援機構によるＶＭシステムも存在する。
【０００３】
一般に、パーソナルコンピュータのような計算機システムは、プロセッサ（実プロセッサ）、各種の入出力（Ｉ／Ｏ）装置（実Ｉ／Ｏ装置）及びメモリ（実メモリ）を含むＨＷ（実ＨＷ）で構成されている。この計算機システムでは、オペレーティングシステム（ＯＳ）が動作する。ＯＳ上では各種アプリケーションプログラム（アプリケーション）が実行される。そのアプリケーションの１つとしてＶＭアプリケーションが知られている。
【０００４】
ＶＭアプリケーションの内部には、仮想計算機モニタ（Virtual Machine Monitor：ＶＭＭ）が存在する。つまり、ＶＭアプリケーションの実行によりＶＭＭが実現される。ＶＭＭは、仮想計算機マネージャ（Virtual Machine Manager）と呼ばれることもある。ＶＭＭは、ＶＭシステムの管理を行い、また仮想ＨＷ装置を構成する。仮想ＨＷ装置は仮想プロセッサ、仮想Ｉ／Ｏ装置及び仮想的なメモリ装置（仮想メモリ）のような仮想ＨＷ群を含む。ＶＭＭは、論理的にこれらの仮想ＨＷをエミュレートして、仮想的な計算機実行環境（仮想計算機実行環境）、つまり仮想計算機システムの実行環境（仮想計算機システム環境）を実現する。この環境にゲストＯＳとして適切なＯＳがロードされ、当該ロードされたＯＳ（ゲストＯＳ）が動作する。
【０００５】
ＶＭＭは、仮想ＨＷとしてのメモリ装置にゲストＯＳのコードを展開し、その実行コードを仮想プロセッサのエミュレートという形で実行することでゲストＯＳの処理を進める。ゲストＯＳからのＩ／Ｏ要求は、ＶＭＭが仮想Ｉ／Ｏ装置のエミュレートを行うことにより処理する。
【０００６】
このように、ＶＭＭは一般的な計算機システム内で仮想計算機実行環境（仮想計算機システム環境）を構築して、その中で複数のゲストＯＳを実行させることができる。ここではＶＭＭは、上述のように、ＯＳ上で実行される１つのアプリケーションとして実装される。
【０００７】
この他に、ＶＭＭが計算機システムの実ＨＷ上に実装される構成も知られている。実ＨＷ上に実装されるＶＭＭはＶＭＭ機構と呼ばれ、実質的にＯＳとして機能する。ＶＭＭ機構は、実プロセッサ及び実Ｉ／Ｏ装置のような実ＨＷを仮想化して各ゲストＯＳに機能として提供する。ＶＭＭ機構の上には、仮想計算機実行環境が当該ＶＭＭ機構により構築される。ＶＭＭ機構は仮想プロセッサ及び仮想Ｉ／Ｏ装置のような仮想ＨＷをエミュレートする。或いはＶＭＭ機構は、実プロセッサ、実Ｉ／Ｏ装置及び実メモリ装置のような実ＨＷ（ＨＷリソース）を時間的及び領域的に、仮想プロセッサ、仮想Ｉ／Ｏ装置及び仮想メモリ装置のような仮想ＨＷに割り当てる。このようにしてＶＭＭ機構は、仮想計算機実行環境を構築する。ゲストＯＳは仮想計算機実行環境にロードされて、仮想プロセッサにより実行される。
【０００８】
仮想計算機実行環境内でゲストＯＳが実行される環境は、ゲストＯＳ実行環境と呼ばれる。一般に仮想計算機システムでは、複数のゲストＯＳが実行される。そこで、複数のゲストＯＳの各々が実行される実行環境においては、ゲストＯＳ間で通信を行うための通信手段があると便利である。そのためＶＭＭは、このような通信手段を提供する。
【０００９】
この通信手段の代表的な機能は、
（１）ゲストＯＳ間割り込み機能
（２）ゲストＯＳ間共有メモリ機能
（３）ゲストＯＳ間メッセージ送受信機能
である。
【００１０】
ゲストＯＳ間割り込み機能とは、ゲストＯＳから指定した他のゲストＯＳに割り込みを送る機能である。受信側には、この割り込みが、いずれのゲストＯＳから送られたものかを知る手段を、例えば割り込み要因情報により提供される。
【００１１】
ゲストＯＳ間共有メモリ機能とは、特定のゲストＯＳ間で、メモリ空間を共有する仕組みである。送信側となるゲストＯＳがデータを書き込んだ後、受信側となるゲストＯＳがそのデータを読み取ることでデータの授受が可能である。データの授受の同期化には、上記ゲストＯＳ間割り込みの仕組みを使えば良い。
【００１２】
ゲストＯＳ間メッセージ送受信機能とは、送信側のゲストＯＳが送信されるべきデータ（送信データ）と送信先（受信側）のゲストＯＳとを指定してＶＭＭに依頼すると、指定されたデータを当該ＶＭＭが送信先のゲストＯＳの受信バッファにコピーして、その後に受信割り込みを当該送信先のゲストＯＳに設定する機能である。
【００１３】
ゲストＯＳ間割り込み機能及びゲストＯＳ間共有メモリ機能を併用するか、或いはゲストＯＳ間メッセージ送受信機能を単独で使用することにより、基本的なゲストＯＳ間通信が実現できる。
【特許文献１】特開２００６−０３９７６３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
従来の仮想計算機システムにおいて、上述の通信機能をプリミティブな仕組みに使うことにより、ＶＭＭが提供する仮想計算機実行環境内で実行されるゲストＯＳ間で、例えばＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）のような通信プロトコルをゲストＯＳ間で実現することができる。そこで、複数のゲストＯＳが、上記の仕組みで互いに通信を行い協調しながらサービスを提供することが考えられる。例えば、外部の通信路（外部ネットワーク）に直接つながるゲストＯＳがファイヤーウォール（ＦＷ）となり、他のゲストＯＳが仮想ネットワーク経由でそのゲストＯＳに接続されるような利用形態が考えられる。
【００１５】
ところが、ゲストＯＳ間で通信をしながら処理を進めるような利用形態の場合に、通信の処理効率が良くならない場合がある。これについて、例を挙げて説明する。
【００１６】
まず、ＶＭＭが構築する仮想計算機実行環境で４つのゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ及び＃Ｄが稼動しており、これらのゲストＯＳのうちのゲストＯＳ＃Ａ及び＃Ｃが互いに通信しながら処理を進めるものとする。更に具体的に述べるならば、ゲストＯＳ＃Ａ中の「プロセス＃ａ」とゲストＯＳ＃Ｃ中の「プロセス＃ｃ」とが互いに送受信しながら処理を進めているものとする。
【００１７】
ＶＭＭは、前述のゲストＯＳ間の通信のための３つの機能、つまりゲストＯＳ間割り込み機能、ゲストＯＳ間共有メモリ機能及びゲストＯＳ間メッセージ送受信機能をサポートしている。ゲストＯＳ＃Ａ及び＃Ｃは、これらの機能を使って通信している。
【００１８】
例えば、プロセス＃ａ及び＃ｃがＴＰＣ／ＩＰのインターフェイスでそれぞれのゲストＯＳに送受信要求を行うものとする。この場合、各ゲストＯＳは、その送受信要求を受け取って処理し、ＶＭＭが提供するゲストＯＳ間通信手段で相手にメッセージ送信を行う。ＶＭＭの提供する代表的なゲストＯＳ間通信手段は、例えば「ゲストＯＳ間メッセージ送受信機能」である。
【００１９】
ゲストＯＳ＃Ａ及び＃Ｃの間で、次の４つの処理が繰り返されるものとする。
（１）ゲストＯＳ＃Ａ（プロセス＃ａ）は３つのメッセージ（ネットワークパケット）をゲストＯＳ＃Ｃに送る（処理ａ１）。
（２）ゲストＯＳ＃Ｃ（プロセス＃ｃ）はゲストＯＳ＃Ａから送られた３つのメッセージを受信して処理する（処理ｃ１）。
（３）ゲストＯＳ＃Ｃ（プロセス＃ｃ）は受信メッセージの処理の結果、新たなメッセージ１つを生成して、そのメッセージをゲストＯＳ＃Ａに送る（処理ｃ２）。
（４）ゲストＯＳ＃Ａ（プロセス＃ａ）はゲストＯＳ＃Ｃから送られたメッセージを受信して処理する（処理ａ２）。
【００２０】
この４つの処理が繰り返される場合の動作シーケンスを図４（ａ）に示す。この図では、処理ａ１及びａ２を合わせた処理が処理ａと表現され、処理ｃ１及び処理ｃ２を合わせた処理が処理ｃと表現されている。図４（ａ）において、横軸は時間の経過を示す。
【００２１】
「τ」はＶＭＭが各ゲストＯＳにプロセッサ（ＣＰＵ）を割り当てる時間の単位を示し、一般にクオンタム（タイムクオンタム）と呼ばれる。説明を簡単にするために、図４（ａ）の例では、クオンタムτの途中でゲストＯＳの切り替えが発生しないものとする。つまり図４（ａ）の例では、時刻ｔn+1，ｔn+2，ｔn+3及びｔn+4からそれぞれ始まるクオンタムτでは、ゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ及び＃Ｄにプロセッサが割り当てられる。同様に、時刻ｔn+5，ｔn+6，ｔn+7及びｔn+8からそれぞれ始まるクオンタムτでも、ゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ及び＃Ｄにプロセッサが割り当てられる。但し、実際の例では、割り込み発生のようなイベントにより、クオンタム途中でのゲストＯＳ切り替えも発生する。
【００２２】
図４（ａ）において、下向きの矢印は送信メッセージを示し、上向きの矢印は受信メッセージを示す。また、矢印の数はメッセージ数を示す。更に、上向きの矢印（受信メッセージ）の下に付されているτを含む符号は、対応するメッセージがそのτを含む符号で示される時間で送られことを示す。また、τを含む符号の下に記載された括弧内の英記号は、対応するメッセージがその英記号で示されるゲストＯＳから送られたことを示す。
【００２３】
図４（ａ）の例では、上述のように時刻ｔn+1でゲストＯＳ＃Ａにプロセッサがディスパッチされて当該ゲストＯＳ＃Ａが動き出す。そして、ゲストＯＳ＃Ａのプロセス＃ａが動き出して、処理ａ１を行う。これにより、３つのメッセージがゲストＯＳ＃Ｃに送られる。するとプロセス＃ａは、その時刻ｔｘ以降、少なくともゲストＯＳ＃Ｃからメッセージが返されるまでは、処理（処理ａ２）ができなくなる。また、ゲストＯＳ＃Ｃからメッセージが返されても、ゲストＯＳ＃Ａが動作可能でない場合には、当該ゲストＯＳ＃Ａが動作可能となるまでプロセス＃ａは処理（処理ａ２）ができなくなる。但し、処理ａ１と処理ａ２の処理時間の和がクオンタムτに対して小さいとすると、クオンタムτの残りの時間内で、ゲストＯＳ＃Ａのプロセス＃ａ以外の処理を行うことは可能である。
【００２４】
ＶＭＭは、ゲストＯＳ＃Ａのプロセス＃ａによって送信されたメッセージをゲストＯＳ＃Ｃに送る。しかし、この時点ではゲストＯＳ＃Ｃは未だ動いていない。図４（ａ）の例において、ゲストＯＳ＃Ｃが動くことができるのは時刻ｔn+3からである。このため、処理ａ１でゲストＯＳ＃Ｃに送られたメッセージは、当該ゲストＯＳ＃Ｃで直ちには受信されず、時刻ｔn+3になりようやく受信される。
【００２５】
ゲストＯＳ＃Ｃのプロセス＃ｃは、処理ｃ１及びｃ２に要する時間がτに対して小さいとするならば、当該処理ｃ１及びｃ２を行い、メッセージを１つゲストＯＳ＃Ａに送る。その後（時刻ｔｙ以降）、ゲストＯＳ＃Ｃのプロセス＃ｃの処理は継続できず、当該ゲストＯＳ＃Ｃ内の他のプロセスが処理される。
【００２６】
ゲストＯＳ＃Ａは、時刻ｔn+1から４τ後の時刻ｔn+5に再び動作可能となり、先にゲストＯＳ＃Ｃから送られたメッセージを受信して処理する（処理ａ２）。
【００２７】
このようにして、一連の処理ａ１，ｃ１，ｃ２及びａ２は４τの時間（周期）をかけて実行される。図４（ａ）からも明らかなように、このような状況はプロセス＃ａ及び＃ｃにとって非常に効率が悪い。
【００２８】
そこで、保留（ペンディング）しているゲストＯＳに割り込みに応じてプロセッサを優先的にディスパッチすることが考えられる。先に述べたように、ゲストＯＳ間通信は送信先への割り込みとして実現される。したがって、このディスパッチ手法を適用することにより、通信メッセージが送られるタイミングで送信先のゲストＯＳにプロセッサがディスパッチされる。
【００２９】
ところが、上述のディスクパッチ手法では、メッセージ送信のたびにゲストＯＳが切り替わることになる。すると、今度はゲストＯＳ切り替えのオーバヘッドが目立って大きなコストになりかねない。更に、上述の例のように複数のメッセージが送られないとプロセス＃ｃが次の処理を行えないような場合、次に述べるようにシステム性能の低下を招く可能性がある。
【００３０】
まず、プロセス＃ａの１つ目のメッセージ送信で制御を渡されただけでは、プロセス＃ｃは、残りの２つのメッセージがないので処理ｃ１を終えることができない。つまり、プロセス＃ｃは、再度ゲストＯＳ＃Ａがスケジューリングされて、当該ゲストＯＳ＃Ａから残りの全ての（２つの）メッセージが送られるのを待つ必要がある。このため、状況によっては、割り込みに伴うゲストＯＳの切り替えの結果、システム性能の低下を招く可能性がある。
【００３１】
更に他の手法として、クオンタムτをより小さい値に設定することが考えられる。τの値が小さいほど、各ゲストＯＳが実行される機会を増やすことができる。この場合、メッセージを送られた後、より短い時間でメッセージ送信先のゲストＯＳが動作可能となるため、メッセージ受信処理が早期に行われる。しかし、τを小さくすると「ゲストＯＳ切り替えコスト」が増加し、システム全体の効率が低下する。
【００３２】
一般にτは、対象となるシステムにおいて「システムのレスポンス時間が良好（τの値を小さくする方向）」で、且つ「ゲストＯＳの切り替えコストが目立たない（悪影響を及ぼさない）（τの値を大きくする方向）」ような最適な値に設定される。このため、本来最適な値に設定されているτの値を小さくすると、システム全体の効率が悪くなる虞がある。
【００３３】
本発明は上記事情を考慮してなされたものでその目的は、ゲストＯＳ間で通信をしながら処理を進める場合における通信処理効率の向上が図れるゲストＯＳスケジューリングを実現するゲストＯＳスケジューリング方法及び仮想計算機モニタを提供することにある。
【課題を解決するための手段】
【００３４】
本発明の１つの観点によれば、仮想計算機モニタによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行され、前記複数のゲストＯＳのうちの任意のゲストＯＳ間で前記仮想計算機モニタによって提供される通信機能を用いて相互に通信を行いながら処理が進められる仮想計算機システムに適用されるゲストＯＳスケジューリング方法が提供される。このゲストＯＳスケジューリング方法は、前記仮想計算機モニタが提供する通信機能を用いて相互に通信するゲストＯＳの組を前記仮想計算機モニタが特定するステップと、前記複数のゲストＯＳのうち、前記特定されたゲストＯＳの組に含まれる各ゲストＯＳの実行スケジュールにおけるクオンタムを前記仮想計算機モニタが短くするステップとを具備する。
【発明の効果】
【００３５】
本発明によれば、ゲストＯＳ間で相互に通信を行いながら連携して処理を行うような場合に、そのゲストＯＳの実行スケジュールにおけるクオンタムだけを短くすることにより、このような通信で従来は発生する通信遅延による性能劣化を、他のゲストＯＳに何ら影響を及ぼすことなく改善することが可能となる。
【発明を実施するための最良の形態】
【００３６】
以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る仮想計算機システム（ＶＭシステム）を実現する計算機システム１の構成を示すブロック図である。計算機システム１は、実計算機を構成するハードウェア（ＨＷ）１０を備えている。ＨＷ１０は、周知のように、実プロセッサ１１、Ｉ／Ｏ装置（入出力装置）１２及びメモリ（図示せず）を含む。ＨＷ１０上では、ホストＯＳと呼ばれるＯＳ２０が動作する。ＯＳ（ホストＯＳ）２０上では仮想計算機アプリケーション（ＶＭアプリケーション）３０を含む各種のアプリケーションが実行される。
【００３７】
ＶＭアプリケーション３０の内部には、仮想計算機モニタ（Virtual Machine Monitor：ＶＭＭ）３１が存在する。つまり、ＶＭアプリケーション３０の実行によりＶＭＭ３１が実現される。ＶＭＭ３１は、ＶＭシステムの管理を行い、仮想計算機システム（ＶＭシステム）の環境（仮想計算機実行環境）を構築する。図１では、４つの仮想計算機実行環境３２Ａ，３２Ｂ，３２Ｃ及び３２Ｄが構築されている例が示されている。
【００３８】
仮想計算機実行環境３２ｉ（ｉ＝Ａ，Ｂ，Ｃ，Ｄ）は、仮想ＨＷ環境（仮想ＨＷ装置）３３ｉ及びゲストＯＳ実行環境３４ｉからなる。仮想ＨＷ環境３３ｉは、仮想プロセッサ（ＶＰ）３３１ｉ、仮想Ｉ／Ｏ装置３３２ｉ及び仮想的なメモリ装置（図示せず）のような仮想ＨＷ群を含む。ＶＭＭ３１は、論理的にこれらの仮想ＨＷをエミュレートして、上述の仮想計算機実行環境３２ｉを実現する。ＶＭＭ３１は、この仮想計算機実行環境３２ｉ内のゲストＯＳ実行環境３４ｉに、当該ゲストＯＳ実行環境３４ｉで動作するＯＳをゲストＯＳ３５ｉ（＃ｉ）としてロードする。ゲストＯＳ実行環境３４ｉにロードされたゲストＯＳ３５ｉ（＃ｉ）は、当該ゲストＯＳ実行環境３４ｉ内で実行される。
【００３９】
ＶＭＭ３１は、仮想ＨＷ環境３３ｉに含まれる仮想的なメモリ装置（仮想メモリ装置）にゲストＯＳ３５ｉ（＃ｉ）のコードを展開し、その実行コードを仮想プロセッサ３３１ｉのエミュレートという形で実行する。これによりＶＭＭ３１は、ゲストＯＳ３５ｉの処理を進める。ゲストＯＳ３５ｉからのＩ／Ｏ要求は、ＶＭＭ３１が仮想Ｉ／Ｏ装置３３２ｉのエミュレートを行うことにより処理する。
【００４０】
図２は、図１に示されるＶＭＭ３１の構成を示すブロック図である。ＶＭＭ３１は、スケジューラ３１１、ディスパッチャ３１２、ゲストＯＳ間通信サービス機構３１３、通信状態テーブル３１４及び相互通信ゲストＯＳテーブル３１５を含む。
【００４１】
スケジューラ３１１は、各ゲストＯＳ３５ｉ（＃ｉ）のスケジュールを決定する。スケジューラ３１１が適用するスケジューリングポリシとして種々考えられるが、ここでは単純なラウンドロビン方式によるスケジューリングが適用されるものとする。即ちスケジューラ３１１は、基本的には、タイムクオンタム（τ）と呼ばれる時間単位毎に、各ゲストＯＳ３５ｉ（＃ｉ）を順番に実行するように、ディスパッチャ３１２に指示する。但し本実施形態では、スケジューラ３１１は、タイムクオンタムの値を状況により変える指示もディスパッチャ３１２に送る。
【００４２】
ディスパッチャ３１２は、スケジューラ３１１の指示に従って実際にゲストＯＳ３５ｉ（＃ｉ）にプロセッサ（実プロセッサ１１）をディスパッチする。ディスパッチャ３１２はまた、スケジューラ３１１によって指示されたタイムクオンタムの時間が経過したならば、ゲストＯＳ３５ｉ（＃ｉ）からプロセッサ（実プロセッサ１１）を取り上げて、次のゲストＯＳに当該プロセッサを割り当てる。ディスパッチャ３１２は、これらの処理を繰り返す。
【００４３】
ゲストＯＳ間通信サービス機構３１３は、各ＯＳ３５ｉ（＃ｉ）からＶＭＭ３１に要求される、ゲストＯＳ間通信要求を処理するゲストＯＳ間通信手段として機能する。ゲストＯＳ間通信は、ＶＭＭ３１に対するＨｙｐｅｒｖｉｓｏｒ呼び出し（システムコール）の形で発行される。この呼び出しでは、送り先のゲストＯＳ及びメッセージデータが指定される。ゲストＯＳ間通信サービス機構３１３は、指定されたゲストＯＳに対して指定されたメッセージを届けると共に、受信割り込みを設定する。この受信割り込みは、その後、送信先のゲストＯＳにプロセッサがディスパッチされた時点で当該送信先のゲストＯＳに入る。このとき、送信先のゲストＯＳは、ゲストＯＳ間通信サービス機構３１３によって送られたメッセージデータを受信データとして参照することができる。
【００４４】
通信状態テーブル３１４は、ゲストＯＳ間通信サービス機構３１３が処理したメッセージ送信に関する情報を保持するのに用いられる。更に詳細に述べるならば、通信状態テーブル３１４は、ゲストＯＳ３５ｉを送信元、ゲストＯＳ３５ｊ（ｊ≠ｉ）を送信先とする、メッセージ送信に関する情報を保持するのに用いられる。なお、以下の説明では、ゲストＯＳ３５Ａ，３５Ｂ，３５Ｃ，３５Ｄ，３５ｉ及び３５ｊを、それぞれゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ，＃Ｄ，＃ｉ及び＃ｊのように表現する。
【００４５】
相互通信ゲストＯＳテーブル３１５は、後述する１スケジュール周期内に受信されるメッセージを互いに送信しているゲストＯＳの対を相互通信ゲストＯＳ対として保持するのに用いられる。
【００４６】
図３は図１に示す計算機システム１によって実現されるＶＭシステム（仮想計算機システム）のシステム状態の一例を示す。ここでは、ＶＭＭ３１が構築する仮想計算機実行環境３２Ａ，３２Ｂ，３２Ｃ及び３２Ｄ（図１参照）で、それぞれゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ及び＃Ｄが稼動している。図３に示すシステム状態では、ゲストＯＳ＃Ａ中の「プロセス＃ａ」とゲストＯＳ＃Ｃ中の「プロセス＃ｃ」とが互いに送受信しながら処理を進めている。更に具体的に述べるならば、ゲストＯＳ＃Ａ中の「プロセス＃ａ」とゲストＯＳ＃Ｃ中の「プロセス＃ｃ」の間で、［発明が解決しようとする課題］の欄に記載されたような４つの処理（ａ１，ｃ１，ｃ２及びａ２）が繰り返し実行されている。
【００４７】
図４は、この４つの処理が繰り返される場合の動作シーケンスを、再スケジューリングの前後で対比して示す。図４において、同図（ａ）は再スケジューリング前の動作を示す動作シーケンス、同図（ｂ）は再スケジューリング後の動作を示す動作シーケンスである。図４において、下向きの矢印は送信メッセージを示し、上向きの矢印は受信メッセージを示す。また、矢印の数はメッセージ数を示す。更に、上向きの矢印（受信メッセージ）の下に付されているτを含む符号は、対応するメッセージがそのτを含む符号で示される時間（例えば２τであれば２τの時間）で送られことを示す。また、τを含む符号の下に記載された括弧内の英記号は、対応するメッセージがその英記号で示されるゲストＯＳ（例えば（Ａ）であればゲストＯＳ＃Ａ）から送られたことを示す。
【００４８】
図５は、図２に示される通信状態テーブル３１４の一例を、スケジュール対象となるゲストＯＳがゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ，＃Ｄである場合について示す。通信状態テーブル３１４は、ゲストＯＳ＃ｉ（ｉ＝Ａ，Ｂ，Ｃ，Ｄ）を送信元、ゲストＯＳ＃ｊ（ｊ＝Ａ，Ｂ，Ｃ，Ｄ、但しｊ≠ｉ）を送信先とする全ての組み合わせについて、メッセージ送信に関する情報（以下、通信状態情報と称する）を保持するエントリ＃ｉｊを有している。
【００４９】
通信状態情報は、１スケジュール周期中に発行されたメッセージ数及びメッセージ受信までに要した平均時間の値を含む。図５の例では、平均時間は括弧内に記述されている。
【００５０】
「１スケジュール周期」は、
τ×（そのときの）スケジュール対象のゲストＯＳ数
で表されるものとする。つまり１スケジュール周期は、本実施形態のように単純なラウンドロビンがクオンタムτで行われている場合には、各ゲストＯＳにプロセッサがディスパッチされた時点から次のディスパッチ時点までの時間となる。図４では、例えばｔn+1〜ｔn+5が１スケジュール周期であり、４τである。
【００５１】
ゲストＯＳ＃ｉを送信元、ゲストＯＳ＃ｊを送信先とする通信状態情報は、ゲストＯＳ間通信サービス機構３１３によって作成される。通信状態テーブル３１４のエントリ＃ｉｊの情報は、この作成された通信状態情報に更新される。スケジューラ３１１は、通信状態テーブル３１４内の更新された通信状態情報（各通信状態情報）を、各スケジュール周期の完了時点で参照することが可能となる。
【００５２】
図５の通信状態テーブル３１４は、図４（ａ）の動作シーケンスで示されるメッセージ送信の状況（通信状態）を表している。例えば、送信元ゲストＯＳ＃Ａ及び送信先ゲストＯＳ＃Ｃに対応する、通信状態テーブル３１４のエントリには、ゲストＯＳ＃Ａ及び＃Ｃ間の最近の１スケジュール周期あたりのメッセージ送信に関する通信状態情報として、「３（２τ）」が保持されている。値「３」は、「１スケジュール周期時間よりも短い時間以内に受信されたメッセージの個数」を表し、括弧内の値「２τ」は、ゲストＯＳ＃Ａ及び＃Ｃ間でメッセージを送信する際に要した平均時間を表す。
【００５３】
本実施形態では、スケジューラ３１１は、スケジュール周期毎にクオンタムを調整する処理（クオンタム調整処理）を次のように行う。まずスケジューラ３１１は、通信状態テーブル３１４を参照して、各ゲストＯＳ間での通信発生状況から、密に相互通信を行っている「ゲストＯＳの対」を探す。スケジューラ３１１は、目的とするゲストＯＳの対が見つかったなら、それらのゲストＯＳに対するプロセッサ割り当て粒度を小さくすることにより、メッセージ送信の遅延の改善を行う。スケジューラ３１１は以上の処理（クオンタム調整処理）をスケジュール周期毎に実行する。なお、クオンタム調整処理が複数スケジュール周期毎に実行されても構わない。
【００５４】
以下、スケジューラ３１１によるクオンタム調整処理の手順について、図６のフローチャートを参照して説明する。まずスケジューラ３１１は、密に相互に通信しているゲストＯＳ（相互通信ゲストＯＳ）の対を全て検出する（ステップＳ１１）。具体的に述べるならば、スケジューラ３１１は、図５に示される通信状態テーブル３１４を参照することにより、１スケジュール周期内に受信されるようなメッセージを互いに送信しているゲストＯＳ＃ｉ，＃ｊの対を全て探し求める。ここで探し求められるゲストＯＳ＃ｉ，＃ｊの対とは、１スケジュール周期内にゲストＯＳ＃ｊで受信されるようなメッセージの送信を行うゲストＯＳ＃ｉと、当該ゲストＯＳ＃ｉで当該１スケジュール周期と同一周期で受信されるようなメッセージの送信を行うゲストＯＳ＃ｊとの対（ゲストＯＳ＃ｉ，＃ｊの対）である。
【００５５】
本実施形態では、上記ステップＳ１１において、通信状態テーブル３１４によって示されるゲストＯＳの組み合わせ毎のメッセージ数が参照されて、メッセージ数が０でない（非０である）ゲストＯＳの組み合わせ（ゲストＯＳ対）が、目的のゲストＯＳの組み合わせ（相互通信ゲストＯＳ対）として検索される。そして検索された全てのゲストＯＳ対のリスト（リスト“Ｌ”）が作成される。図５の通信状態テーブル３１４の例では、ゲストＯＳ＃Ａ及び＃Ｃの対のみを要素として含むリスト“Ｌ”が作成される。
【００５６】
スケジューラ３１１は、作成されたリスト“Ｌ”と相互通信ゲストＯＳテーブル３１５とを比較して、当該テーブル３１５に未登録のゲストＯＳ対（を示す情報）がリスト“Ｌ”に含まれているならば、そのゲストＯＳ対（を示す情報）を当該テーブル３１５に追加登録する（ステップＳ１２）。
【００５７】
またスケジューラ３１１は、リスト“Ｌ”に存在しないが相互通信ゲストＯＳテーブル３１５に既に登録されているゲストＯＳ対が存在するならば、つまりリスト“Ｌ”に存在しないゲストＯＳ対のエントリが相互通信ゲストＯＳテーブル３１５にあるならば、そのエントリ（の情報）を当該相互通信ゲストＯＳテーブル３１５から削除する（ステップＳ１３）。このステップＳ１３の処理で削除されるゲストＯＳの対は、以前に相互に通信し合っていたが、最近になって通信しなくなったゲストＯＳの対である。
【００５８】
図７はステップＳ１２及びＳ１３が実行された後の相互通信ゲストＯＳテーブル３１５の一例を示す。図７の例では、相互通信ゲストＯＳテーブル３１５の先頭エントリに、相互通信ゲストＯＳの対（相互通信ゲストＯＳ＃ｉ及び＃ｊの対）として、ゲストＯＳ＃Ａ及び＃Ｃの対が登録されている。
【００５９】
次にスケジューラ３１１は、相互通信ゲストＯＳテーブル３１５を参照して「密連結ゲストＯＳグループ」を作成する（ステップＳ１４）。「密連結ゲストＯＳグループ」とは、相互通信ゲストＯＳテーブル３１５に登録されているゲストＯＳの対の集合（つまりゲストＯＳの組）であって、あるゲストＯＳと対をなすゲストＯＳ以外に、当該あるゲストＯＳとの間で相互通信をしている別のゲストＯＳが存在する場合には、当該別のゲストＯＳを含めたゲストＯＳの集合（ゲストＯＳの組）である。そこで、相互通信ゲストＯＳテーブル３１５の各エントリは、ゲストＯＳの対を登録するための欄に加えて、この欄に登録されたゲストＯＳが属するグループのＩＤ（グループＩＤ）を登録するための欄を含む。
【００６０】
図７の相互通信ゲストＯＳテーブル３１５の例では、ゲストＯＳ＃Ａ及び＃Ｃのみが密連結ゲストＯＳグループを形成する。しかし、通信状態テーブル３１４が例えば図９のような場合には、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄが密連結ゲストＯＳグループを形成する。つまり密連結ゲストＯＳグループとは、相互に頻繁にメッセージを授受しているゲストＯＳの集合である。
【００６１】
上記ステップＳ１４においてスケジューラ３１１は、作成された密連結ゲストＯＳグループ毎にユニークなＩＤ（例えば番号）をグループＩＤとして付与し、当該ＩＤを相互通信ゲストＯＳテーブルのグループＩＤ欄に記入する。
【００６２】
スケジューラ３１１はステップＳ１４を実行するとステップＳ１５の処理に進む。ステップＳ１５においてスケジューラ３１１は、各密連結ゲストＯＳグループに関して、当該グループに属するゲストＯＳが元々クオンタムτの単位でスケジューリングされていた時間帯を、当該グループに属するゲストＯＳの再スケジューリングのためにτ／ｎの長さに分割する。このｎを分割定数と呼ぶ。本実施形態において分割定数ｎの値は、予め定められた一定値であり、２であるものとする。但し、このｎの値は、後述するように動的に変更された方が良い。スケジューラ３１１は、ステップＳ１５において更に、再スケジューリングの対象となる各ゲストＯＳをτ／ｎの時間単位で順に実行させる新しいスケジュール（を表すスケジュール表）を作成（決定）する。
【００６３】
次にスケジューラ３１１は、作成された新しいスケジュール（スケジュール表）の情報をディスパッチャ３１２に渡して、当該スケジュールに基づく再スケジューリングをディスパッチャ３１２に指示する（ステップＳ１６）。これによりディスパッチャ３１２は、スケジューラ３１１から渡された新しいスケジュールに従って、実際にゲストＯＳ（ゲストＯＳ＃Ａ及び＃Ｃ）にプロセッサをディスパッチする再スケジューリングを行う。
【００６４】
「クオンタム調整処理」の結果、上述したように、ゲストＯＳ＃Ａ及び＃Ｃが相互にメッセージを授受している本実施形態では、これらのゲストＯＳ＃Ａ及び＃Ｃが、同一の「密連結ゲストＯＳグループ」に属すこととなる。その結果、ゲストＯＳ＃Ａ及び＃Ｃに関して、τ／２の時間単位でのプロセッサ割り当てが再スケジューリングされ、その結果、図４（ｂ）のような実行状態となる。ここで、密連結ゲストＯＳグループに属さないゲストＯＳ＃Ｂ及び＃Ｄは、依然としてτの時間単位で１スケジュール周期（＝４τ）毎にプロセッサ割り当てがスケジューリングされる。つまり本実施形態では、密連結ゲストＯＳグループに属するゲストＯＳを対象とする再スケジューリングが、他のゲストＯＳのスケジューリングに影響を及ぼすことはない。
【００６５】
図４（ｂ）の例では、ゲストＯＳ＃ＡからゲストＯＳ＃Ｃへのメッセージ送信の平均時間、及びゲストＯＳ＃ＣからゲストＯＳ＃Ａへのメッセージ送信の平均時間は、それぞれ、ほぼ０．５τ及び１．５τとなる。この場合、一連の前述の４つの処理（ａ１，ｃ１，ｃ２及びａ２）の周期（平均処理周期）は、図４（ａ）に示される４τから図４（ｂ）に示される２τに改善される。
【００６６】
このように本実施形態においては、ゲストＯＳ間で相互に通信を行いながら連携して処理を行う場合に、そのゲストＯＳの実行スケジュールにおけるクオンタムだけを短くすることにより、このような通信で従来は発生する通信遅延による性能劣化を、他のゲストＯＳに何ら影響を及ぼすことなく改善することができる。特に、仮想計算機システムのゲストＯＳ間通信は、メモリベースで実装されることが多く、それ自体オーバヘッドが小さいものであ。このため仮想計算機システムのゲストＯＳ間通信は、実ネットワークでの通信に比べて非常に遅延時間（レイテンシ）が小さいものとして使用できる可能性がある。よって本実施形態においては、仮想計算機システムの高速なゲストＯＳ間通信機構の性能を十分引き出すことができ、従来に比べてシステム全体で性能が高い仮想計算機システムを実現できる。
【００６７】
図４の例では、ゲストＯＳ＃Ａ及び＃Ｃによってそれぞれ実行される処理＃ａ及び＃ｃ以外の処理は考慮されていない。このため、実際には、常に図４（ｂ）のような結果になる保証はない。しかしながら、図４（ａ）の状況では、ゲストＯＳ＃Ａ及び＃Ｃがどのような負荷状況にあったとしても、当該図４（ａ）に示される以上のスループットは得られない。本実施形態では、図４（ｂ）に示されるように、負荷状態によっては効率良く処理されるように改善される。
【００６８】
次に、本実施形態における再スケジューリングによる処理効率の他の改善例を、ゲストＯＳ＃Ａ（中のプロセス＃ａ）、ゲストＯＳ＃Ｃ（中のプロセス＃ｃ）及びゲストＯＳ＃Ｄ（中のプロセス＃ｄ）が互いに送受信しながら処理を進める場合について、再スケジューリング前と対比して図８に示す。図８において、同図（ａ）は再スケジューリング前の動作を示す動作シーケンス、同図（ｂ）は再スケジューリング後の動作を示す動作シーケンスである。この例でも、ｎが２であるものとする。
【００６９】
図８の例では、１スケジュール周期毎に、以下に挙げる６つの処理が行われる。
（１）ゲストＯＳ＃Ａ（プロセス＃ａ）は３つのメッセージ（ネットワークパケット）の２つをゲストＯＳ＃Ｃに、１つをゲストＯＳ＃Ｄに、それぞれ送る（処理ａ′１）
（２）ゲストＯＳ＃Ｃ（プロセス＃ｃ）はゲストＯＳ＃Ａから送られた２つのメッセージを受信して処理する（処理ｃ′１）。
（３）ゲストＯＳ＃Ｃ（プロセス＃ｃ）は受信メッセージの処理の結果、新たなメッセージ１つを生成して、そのメッセージをゲストＯＳ＃Ｄに送る（処理ｃ′２）。
（４）ゲストＯＳ＃Ｄ（プロセス＃ｄ）はゲストＯＳ＃Ｃから送られた１つのメッセージを受信して処理する（処理ｄ′１）。
【００７０】
（５）ゲストＯＳ＃Ｄ（プロセス＃ｄ）は受信メッセージの処理の結果、新たなメッセージ１つを生成して、そのメッセージをゲストＯＳ＃Ａに送る（処理ｄ′２）。
（６）ゲストＯＳ＃Ａ（プロセス＃ａ）はゲストＯＳ＃Ｃ及び＃Ｄから送られたメッセージを受信して処理する（処理ａ′２）。
【００７１】
ここで、処理（送信処理）ａ′１及びｃ′２、並びに処理（送信処理）ａ′１及びｄ′２は、それぞれａ′１→ｃ′２、ａ′１→ｄ′２のように、順番に処理される必要がある。
【００７２】
図８（ａ）の状態における通信状態テーブル３１４の例を図９に示す。また、図９に示される通信状態テーブル３１４の状態に基づいて「クオンタム調整処理」が行われた結果としての相互通信ゲストＯＳテーブル３１５の一例を図１０に示す。図８（ｂ）は、図１０に示される相互通信ゲストＯＳテーブル３１５に基づいて作成される新しいスケジュールに従って、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄにプロセッサがディスパッチされた場合（つまり再スケジューリング後）の動作シーケンスを示す。
【００７３】
図１０に示される相互通信ゲストＯＳテーブル３１５の例では、「密連結ゲストＯＳグループ」がゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄから構成されている。この場合、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄに関して、τ／２の時間単位でのプロセッサ割り当てが再スケジューリングされる。この再スケジューリングにより、これら３つのゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄに対する時間割り当て粒度が小さくなる。これにより、前述の６つの処理（ａ′１，ｃ′１，ｃ′２，ｄ′１，ｄ′２，ａ′２）の動作シーケンスは、図８（ａ）に示される状態から図８（ｂ）に示される状態に改善される。ここで、密連結ゲストＯＳグループに属さないゲストＯＳ＃Ｂは、依然としてτの時間単位で１スケジュール周期（＝４τ）毎にプロセッサ割り当てがスケジューリングされる。
【００７４】
図８（ａ）における平均処理周期は４τ、図８（ｂ）における平均処理周期は２τである。これにより、図８（ｂ）における平均処理周期は、図８（ａ）の４τから２τ改善されたことがわかる。図８（ｂ）の状態における通信状態テーブル３１４の例を図１１に示す。
【００７５】
［変形例］
上記実施形態では、ｎの値が予め定められた一定値（ｎ＝２）である場合を想定している。このｎは、ゲストＯＳの割り当て時間単位を決める値（パラメータ値）である。上記実施形態では、τ×（１／ｎ）、つまりτ／ｎの時間単位で、プロセッサが割り当てられる。しかし、メッセージ通信に要する時間は、この割り当て時間τ／ｎにより影響を受ける。このため、ｎの値を適切に設定する必要がある。
【００７６】
そこで、ｎの値を適切に決める処理（ｎ値決定処理）を含むクオンタム調整処理がスケジューラ３１１によって実行される、上記実施形態の変形例について説明する。
【００７７】
図１２は本変形例で適用されるＶＭＭ３１の構成を示すブロック図である。図１２において、図２と同様の要素には便宜的に同一参照符号を付してある。図１２に示すＶＭＭ３１が、図２に示すＶＭＭ３１と相違するのは、ｎ値定義テーブル３１６及び平均通信時間テーブル３１７を含む点である。テーブル３１６及び３１７については後述する。
【００７８】
次に、ｎ値決定処理を含むクオンタム調整処理の概要について説明する。
（ａ）スケジューラ３１１は、密連結ＯＳグループ毎に別々のｎの値を使い、必要に応じてτの値を変える。密連結ＯＳグループＧｉのｎの値をｎiで表すと、スケジューラ３１１は、密連結ＯＳグループＧｉに属する各ゲストＯＳに対するプロセッサ割り当て時間が、再スケジューリング前の割り当て時間の１／ｎiになるように再スケジューリングする。
【００７９】
（ｂ）ｎの値は、取り得る値が予め決められているものとする。本変形例では、ｎの値は、ｄ0，ｄ1，ｄ2及びｄ3の４種類の値のいずれかとなる。ｄ0〜ｄ3の具体的な値は、ｎ値定義テーブル３１６によって定義される。
【００８０】
図１３は、ｎ値定義テーブル３１６の例を示す。図１３の例では、ｄ0〜ｄ3はｎの値（ｎ値）１〜４に対応する。このｎ値定義テーブル３１６の内容を変えるならば、つまりｄ0〜ｄ3の定義を変えるならば、種々のｎの値を定義することができる。
【００８１】
本変形例では、ｄ0〜ｄ3で示される値は、このｄ0〜ｄ3の順に大きくなる（つまり、クオンタムがより細かく分割される）ように定められているものとする。また、ｄ0（つまりｎの値の最小値）は１であるものとする。更に、本変形例において定義される最大のｎの値をｄmaxと表記するものとする。つまり本変形例では、ｄmax＝ｄ3である。
【００８２】
（ｃ）本変形例で適用されるｎ値決定処理を含むクオンタム調整処理では、ｄiで定義されるｎiの値が決定されてから、当該クオンタム調整処理がＡ回呼び出される間は実質的な決定処理は何も行われない。つまり本変形例においては、一度ｎ値決定処理でｎiの値が決まってからクオンタム調整処理がＡ回呼び出される間は、ｎiの値が変更されないようにしている。これにより、頻繁にｎiの値が変わることによる処理増加によるオーバヘッドの増加を防ぐことが可能となる。
【００８３】
本変形例においても、上記実施形態と同様に、スケジューラ３１１が、スケジュール周期毎にクオンタム調整処理を行う。つまりスケジューラ３１１は、通信状態テーブル３１４を参照して、各ゲストＯＳ間での通信発生状況から、密に相互通信を行っている（つまり１スケジュール周期内に受信されるようなメッセージを互いに送信している）ゲストＯＳの対を探す。そのようなゲストＯＳの対が見つかったなら、スケジューラ３１１は、それらゲストＯＳに対するプロセッサ割り当て粒度を小さくすることにより、メッセージ送信の遅延の改善を行う。但し、本変形例においてスケジューラ３１１は、密連結ＯＳグループ毎にｎの値を動的に変えることにより、当該グループ毎にプロセッサ割り当て粒度を調整する。なお、クオンタム調整処理が複数スケジュール周期毎に実行されても構わない。
【００８４】
次に、ｎ値決定処理を含むクオンタム調整処理の手順について、図１４Ａ及び図１４Ｂのフローチャートを参照して説明する。まずスケジューラ３１１は、クオンタム調整処理を繰り返し実行する前に、変数ＷＡＩＴ＿ＣＮＴを予め０に初期化する。この変数ＷＡＩＴ＿ＣＮＴは、クオンタム調整処理が行われるタイミングを調整するのに用いられる。
【００８５】
スケジューラ３１１はクオンタム調整処理が呼び出されると、変数ＷＡＩＴ＿ＣＮＴを参照して当該変数が０であるかを判定する（ステップＳ２１）。変数ＷＡＩＴ＿ＣＮＴが０でない場合、スケジューラ３１１は当該変数ＷＡＩＴ＿ＣＮＴを１デクリメントして（ステップＳ２２）、そのままクオンタム調整処理を終了する。
【００８６】
一方、変数ＷＡＩＴ＿ＣＮＴが０の場合には、スケジューラ３１１は密連結ＯＳグループ毎にプロセッサ割り当て粒度の調整処理を次のように行う。まずスケジューラ３１１は、上記実施形態におけるステップＳ１１乃至Ｓ１４に相当するステップＳ２３乃至２６を実行する。即ちスケジューラ３１１は、相互通信ゲストＯＳ対の検出及び相互通信ゲストＯＳ対のリスト“Ｌ”の作成（ステップＳ２３）、相互通信ゲストＯＳテーブルに存在しない新規検出相互通信ゲストＯＳ対の相互通信ゲストＯＳテーブル３１５への登録（ステップＳ２４）、リスト“Ｌ”に存在しないゲストＯＳ対のエントリの相互通信ゲストＯＳテーブル３１５からの削除（ステップＳ２５）、並びに密連結ゲストＯＳグループの作成（ステップＳ２６）を行う。
【００８７】
スケジューラ３１１は、ステップＳ２３乃至Ｓ２６を実行するとステップＳ２７の処理に進む。ステップＳ２７においてスケジューラ３１１は、平均通信時間テーブル３１７に、今回新規に検出された密連結ゲストＯＳグループのためのエントリ（の情報）を追加する。また、ステップＳ２７においてスケジューラ３１１は、前回までに検出されて平均通信時間テーブル３１７に登録されていた密連結ゲストＯＳグループのためのエントリであって、今回検出されなかった密連結ゲストＯＳグループのためのエントリ（の情報）を、当該平均通信時間テーブル３１７から削除する。
【００８８】
図１５は平均通信時間テーブル３１７の一例を示す。平均通信時間テーブル３１７は、密連結ゲストＯＳグループ毎のエントリを有する。平均通信時間テーブル３１７のエントリは、対応する密連結ゲストＯＳグループのｄ0〜ｄ3で定義されるｎの値毎の平均通信時間の測定値を登録するのに用いられる。この平均通信時間については後述する。
【００８９】
上記ステップＳ２７で、平均通信時間テーブル３１７に、新規に検出された密連結ゲストＯＳグループのためのエントリが追加された時点では、当該エントリの情報は初期化されている。ここでは、追加されたエントリで示されるｄ0〜ｄ3で定義されるｎの値毎の平均通信時間の情報が、「未定義（有効な値なし）」の状態（記号−で示される状態）に設定される。
【００９０】
スケジューラ３１１は、ステップＳ２７を実行すると、ｎ値決定処理（ステップＳ２８乃至Ｓ３６）を次のように実行する。まずスケジューラ３１１は、相互通信ゲストＯＳテーブル３１５に登録されている全ての密連結ゲストＯＳグループについてｎ値決定処理を実行したかを判定する（ステップＳ２８）。もし、ｎ値決定処理が未実行（未処理）の密連結ゲストＯＳグループが存在するならば、スケジューラ３１１は相互通信ゲストＯＳテーブル３１５から未処理の密連結ゲストＯＳグループを１つ密連結ゲストＯＳグループＧｉとして選択する（ステップＳ２９）。
【００９１】
スケジューラ３１１は、選択された密連結ゲストＯＳグループＧｉに対応する平均通信時間テーブル３１７のエントリの情報、つまり密連結ゲストＯＳグループＧｉの平均通信時間を更新する（ステップＳ３０）。平均通信時間とは、ｄk（ｋ＝０〜３）で定義されるｎの値が適用されている状態で、密連結ゲストＯＳグループＧｉに属するゲストＯＳが送信したメッセージのうち、１スケジュール周期内に送信先のゲストＯＳで受信されたメッセージに関して、それらメッセージが送信されてから受信されるまでに要した時間の平均である。ここで送信時より１スケジュール周期を越えて受信されたメッセージは、平均通信時間算出の対象から除かれる。
【００９２】
よって、密連結ゲストＯＳグループＧｉの平均通信時間は、当該グループＧｉに属するゲストＯＳ間で直近の１スケジュール周期内で授受されるメッセージの通信時間の総和（Σ（メッセージの通信時間）をメッセージ総数で除した値によって表される。つまり、密連結ゲストＯＳグループＧｉの平均通信時間は、次式
（Σ（メッセージの通信時間））／メッセージ総数 （１）
で表される。但し式（１）におけるメッセージとは、密連結ゲストＯＳグループＧｉに属する全てのゲストＯＳが送信したメッセージのうち、１スケジュール周期内に送信先のゲストＯＳで受信されるメッセージを指す。
【００９３】
このように本変形例において、平均通信時間の算定の対象とする期間は、直近の１スケジュール周期である。しかし、複数スケジュール周期で評価してそれらの平均を取って１スケジュール周期当たりの平均通信時間としても良い。
【００９４】
ここで、平均通信時間算出の具体例について、図８（ａ）の場合を例に説明する。図８（ａ）の例では、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄが１つの密連結ゲストＯＳグループを構成する。この密連結ゲストＯＳグループのグループＩＤを１とし、当該グループをＧ１、つまりＧｉ＝Ｇ１（ｉ＝１）と呼ぶことにする。ここで、クォンタムはτなので、ｎ＝１、つまりｄk＝ｄ0（ｋ＝０）のケースであり、通信状態テーブル３１４の内容は図９のようになる。
【００９５】
この場合の密連結ゲストＯＳグループＧｉ（Ｇ１）の平均通信時間は
（Σ（メッセージの通信時間））／メッセージ総数
＝（２×２τ＋１×３τ＋１×２τ＋１×τ）／５
＝２τ
のように求められる。
【００９６】
ステップＳ３０においてスケジューラ３１１は、求められた平均通信時間をＴとする。この例では、Ｔ＝２τである。ステップＳ３０においてスケジューラ３１１は、密連結ゲストＯＳグループＧｉ（Ｇ１）に対応する平均通信時間テーブル３１７のエントリに含まれているｄ0〜ｄ3の各欄のうち、現在適用されているｄk＝ｄ0（ｋ＝０）の欄に、求められた平均通信時間Ｔ（＝２τ）を設定する。つまりスケジューラ３１１は、ｄk＝ｄ0（ｋ＝０）の欄の旧設定情報を平均通信時間Ｔ（＝２τ）に更新する。ここで、更新後の平均通信時間Ｔは、密連結ゲストＯＳグループＧｉ（Ｇ１）及びｄk＝ｄ0（ｋ＝０）に関連する。そこで、更新後の平均通信時間ＴをＴi,kと表現する。ここでは、Ｔi,k＝Ｔ1,0（ｉ＝１，ｋ＝０）＝２τである。
【００９７】
次にスケジューラ３１１は、密連結ゲストＯＳグループＧｉの現在のｎの値（つまりｎiの値）をｄkとするとき、その値が最小値（１）であるか、つまりｄ0（ｋ＝０）であるかを判定する（ステップＳ３１）。もし、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）でないならば、スケジューラ３１１は今回求められた（ｄkにおける）平均通信時間Ｔi,kが０であるかを判定する（ステップＳ３２）。もし、平均通信時間Ｔi,kが０でないならば、スケジューラ３１１は当該平均通信時間Ｔi,kがｄk-1における平均通信時間Ｔi,k-1よりも小さいかを判定する（ステップＳ３３）。
【００９８】
もし、平均通信時間Ｔi,kがＴi,k-1よりも小さいならば、スケジューラ３１１は新しいｎ（＝ｎi）の値を現在の値ｄkよりも１段階大きいｄk+1に設定する（ステップＳ３４）。つまりスケジューラ３１１は、ＣＰＵ割り当て時間単位を現在よりも１段階細かくする。但し、ｄk+1が定義されていないならば、つまり現在の値ｄkがｎ値定義テーブル３１６によって定義される最大のｎの値ｄmaxであるならば、それ以上大きなｎの値を設定できない。このような場合、スケジューラ３１１は新しいｎ（＝ｎi）の値を現在の値ｄk、つまりｄmaxとする。スケジューラ３１１はステップＳ３４を実行すると、上記ステップＳ２８の処理に戻る。
【００９９】
一方、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）であるならば、つまり現在の値ｄkがｄ0（ｋ＝０）であるならば（ステップＳ３１）、スケジューラ３１１は平均通信時間Ｔi,k（ｋ＝０）が０でない限りにおいて（ステップＳ３５）、ｎ（＝ｎi）の値を現在の値ｄkよりも１段階大きいｄk+1とする（ステップＳ３４）。ここではｋ＝０であることから、ｎ（＝ｎi）の値がｄ0（＝１）からｄ1（＝２）に変更される。
【０１００】
次に、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）でなく、且つ今回求められた（ｄkにおける）平均通信時間Ｔi,kが０でないものの、当該平均通信時間Ｔi,kがｄk-1における平均通信時間Ｔi,k-1よりも大きいか等しいものとする（ステップＳ３１〜Ｓ３３）。この場合、スケジューラ３１１は新しいｎ（＝ｎi）の値を、現在の値ｄkよりも１段階小さいｄk-1とする（ステップＳ３６）。つまりスケジューラ３１１は、ＣＰＵ割り当て時間単位を現在よりも１段階大きくする。スケジューラ３１１はステップＳ３６を実行すると、上記ステップＳ２８の処理に戻る。
【０１０１】
さて図１４Ａ及び図１４Ｂのフローチャートでは、平均通信時間Ｔi,kが０の場合も考慮されている（ステップＳ３２及びＳ３５）。しかし、Ｔi,kが０の密連結ゲストＯＳグループは前記ステップＳ２３，Ｓ２４において相互通信ゲストＯＳテーブル３１５に登録されない。したがって本変形例では、平均通信時間Ｔi,kが０の場合は発生しない。図１４Ａ及び図１４Ｂのフローチャートでは、一般的な処理手順とするためにＴi,kが０の場合の処理も含めている。ここでは、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）でなく、且つ今回求められた（ｄkにおける）平均通信時間Ｔi,kが０であるならば（ステップＳ３１，Ｓ３２）、スケジューラ３１１は新しいｎ（＝ｎi）の値を、現在の値ｄkよりも１段階小さいｄk-1とする（ステップＳ３６）。また、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）であり、且つ今回求められた平均通信時間Ｔi,kが０であるならば（ステップＳ３１，Ｓ３５）、スケジューラ３１１はｎ（＝ｎi）を操作せずにステップＳ２８の処理に戻る。
【０１０２】
スケジューラ３１１はステップＳ２８から始まる上述の処理（ｎ値決定処理）を、全ての密連結ゲストＯＳグループについて実行する。そして全ての密連結ゲストＯＳグループについてｎ値決定処理を実行し終えると（ステップＳ２８）、スケジューラ３１１は変数ＷＡＩＴ＿ＣＮＴに初期値Ａを設定する（ステップＳ３７）。
【０１０３】
次にスケジューラ３１１は、ｎ値決定処理で密連結ゲストＯＳグループＧｉ毎に決定（設定）されたｎiの値を当該グループＧｉに適用することにより、当該グループＧｉに属する各ゲストＯＳをτ／ｎiの時間単位で順に実行させる新しいスケジュールを作成する（ステップＳ３８）。スケジューラ３１１は、作成された新しいスケジュールの情報をディスパッチャ３１２に渡して、当該スケジュールに基づく再スケジューリングをディスパッチャ３１２に指示する（ステップＳ３９）。以降、図１４Ａ及び図１４Ｂのフローチャートに示される処理がＡ回呼ばれる間は、変数ＷＡＩＴ＿ＣＮＴが１ずつデクリメントされるだけである（ステップＳ２１，Ｓ２２）。このため、同じｎiで各密連結ゲストＯＳグループＧｉがスケジューリングされる。
【０１０４】
図８（ａ）の例の場合、ｎ値決定処理（ステップＳ２８乃至Ｓ３６）の結果、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄによって構成される密連結ゲストＯＳグループＧ１（Ｇｉ＝Ｇ１）のｎ1（ｎi＝ｎ1）の値は、ｄ0からｄ1に変更される。つまりｎ1の値は１から２に変更される。この結果、密連結ゲストＯＳグループＧ１の新たな時間割り当て単位はτからτ／２となる。これによりゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄは、図８（ｂ）に示すように、新たな時間割り当て単位で再スケジューリングされる。
【０１０５】
前述したように、図９は、図８（ｂ）の状態における通信状態テーブル３１４の例を示す。この通信状態テーブル３１４に基づき、密連結ゲストＯＳグループＧ１に関する平均通信時間を計算すると、
（Σ（メッセージの通信時間））／メッセージ総数
＝（４×τ／２＋１×２τ＋１×τ＋１×τ＋１×２τ＋２×τ／２）／１０
＝０．９τ
となる。
【０１０６】
この計算結果から、平均通信時間が２τから０．９τに改善したことが分かる。次回、図１４Ａ及び図１４Ｂのフローチャートに従う処理が行われるときには、図１５に示されるように、平均通信時間テーブル３１７の密連結ゲストＯＳグループＧ１に対応するエントリのｄ１の欄に、「０．９τ」が記録される。すると、ｎiの値が更にｄ1（＝２）からｄ2（＝３）に変更されて、割り当て時間単位がより細分化される。このようにして、効果が得られる間（つまりｄkにおける新しい平均通信時間Ｔi,kが、ｄk-1における平均通信時間Ｔi,k-1よりも小さい間）はｎiの値を小さくし、効果が得られない場合にはｎiの値をｄkから直前の値ｄk-1に戻すような制御が行われる。これにより、結果的に各密連結ゲストＯＳグループに対して最適なｎiの値が定められる。
【０１０７】
前述の説明では省略されているが、前記ステップＳ２７で平均通信時間テーブル３１７から削除された密連結ゲストＯＳグループの各ゲストＯＳは、ｎの値がｄ0（＝１）に戻されてτの時間単位で再スケジューリングされる。
【０１０８】
上記実施形態及びその変形例では、ＶＭＭ３１が、ＯＳ２０上で動作する１つのアプリケーション（ＶＭアプリケーション３０）として実装される場合を想定している。しかし本発明は、ＶＭＭ（仮想計算機マネージャ）が、計算機システムの実ＨＷ上にＶＭＭ機構として実装される場合にも、同様に適用可能である。
【０１０９】
なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。
【図面の簡単な説明】
【０１１０】
【図１】本発明の一実施形態に係る仮想計算機システムを実現する計算機システムの構成を示すブロック図。
【図２】図１に示されるＶＭＭ（仮想計算機モニタ）の構成を示すブロック図。
【図３】同実施形態における仮想計算機システムのシステム状態の一例を、２つのゲストＯＳが互いに送受信しながら処理を進める場合について示す図。
【図４】図３のシステム状態における動作シーケンスを、再スケジューリングの前後で対比して示す図。
【図５】図４（ａ）の状態における通信状態テーブルの一例を示す図。
【図６】同実施形態におけるクオンタム調整処理の手順を示すフローチャート。
【図７】相互通信ゲストＯＳテーブルの一例を示す図。
【図８】３つのゲストＯＳが互いに送受信しながら処理を進める場合の動作シーケンスを、再スケジューリングの前後で対比して示す図。
【図９】図８（ａ）の状態における通信状態テーブルの一例を示す図。
【図１０】図９に示される通信状態テーブルの状態に基づいてクオンタム調整処理が行われた場合の相互通信ゲストＯＳテーブルの一例を示す図。
【図１１】図８（ｂ）の状態における通信状態テーブルの一例を示す図。
【図１２】同実施形態の変形例で適用されるＶＭＭ（仮想計算機モニタ）の構成を示すブロック図。
【図１３】ｎ値定義テーブルの一例を示す図。
【図１４Ａ】同実施形態の変形例におけるクオンタム調整処理の手順を示すフローチャート。
【図１４Ｂ】同実施形態の変形例におけるクオンタム調整処理の手順を示すフローチャート。
【図１５】平均通信時間テーブルの一例を示す図。
【符号の説明】
【０１１１】
３１…ＶＭＭ（仮想計算機モニタ）、３２Ａ〜３２Ｄ…仮想計算機実行環境、３５Ａ〜３５Ｄ…ゲストＯＳ、３１１…スケジューラ、３１２…ディスパッチャ、３１３…ゲストＯＳ間通信サービス機構、３１４…通信状態テーブル、３１５…相互通信ゲストＯＳテーブル、３１６…ｎ値定義テーブル、３１７…平均通信時間テーブル。
【技術分野】
【０００１】
本発明は、仮想的な計算機実行環境を提供する仮想計算機システムに係り、特に当該仮想的な計算機実行環境で実行されるゲストＯＳ間の通信状況に基づいてゲストＯＳの実行スケジュールを切り替えるゲストＯＳスケジューリング方法及び仮想計算機モニタに関する。
【背景技術】
【０００２】
近年、パーソナルコンピュータのような計算機システムにおいても、仮想計算機（Virtual Machine：ＶＭ）の技術を応用した研究や開発が行われている（例えば、特許文献１参照）。また、ＶＭシステム（仮想計算機システム）を実現するための商用のアプリケーションプログラムが実際に広く利用されている。また、メインフレームで古くからハードウェア（ＨＷ）で構成されたＶＭ支援機構によるＶＭシステムも存在する。
【０００３】
一般に、パーソナルコンピュータのような計算機システムは、プロセッサ（実プロセッサ）、各種の入出力（Ｉ／Ｏ）装置（実Ｉ／Ｏ装置）及びメモリ（実メモリ）を含むＨＷ（実ＨＷ）で構成されている。この計算機システムでは、オペレーティングシステム（ＯＳ）が動作する。ＯＳ上では各種アプリケーションプログラム（アプリケーション）が実行される。そのアプリケーションの１つとしてＶＭアプリケーションが知られている。
【０００４】
ＶＭアプリケーションの内部には、仮想計算機モニタ（Virtual Machine Monitor：ＶＭＭ）が存在する。つまり、ＶＭアプリケーションの実行によりＶＭＭが実現される。ＶＭＭは、仮想計算機マネージャ（Virtual Machine Manager）と呼ばれることもある。ＶＭＭは、ＶＭシステムの管理を行い、また仮想ＨＷ装置を構成する。仮想ＨＷ装置は仮想プロセッサ、仮想Ｉ／Ｏ装置及び仮想的なメモリ装置（仮想メモリ）のような仮想ＨＷ群を含む。ＶＭＭは、論理的にこれらの仮想ＨＷをエミュレートして、仮想的な計算機実行環境（仮想計算機実行環境）、つまり仮想計算機システムの実行環境（仮想計算機システム環境）を実現する。この環境にゲストＯＳとして適切なＯＳがロードされ、当該ロードされたＯＳ（ゲストＯＳ）が動作する。
【０００５】
ＶＭＭは、仮想ＨＷとしてのメモリ装置にゲストＯＳのコードを展開し、その実行コードを仮想プロセッサのエミュレートという形で実行することでゲストＯＳの処理を進める。ゲストＯＳからのＩ／Ｏ要求は、ＶＭＭが仮想Ｉ／Ｏ装置のエミュレートを行うことにより処理する。
【０００６】
このように、ＶＭＭは一般的な計算機システム内で仮想計算機実行環境（仮想計算機システム環境）を構築して、その中で複数のゲストＯＳを実行させることができる。ここではＶＭＭは、上述のように、ＯＳ上で実行される１つのアプリケーションとして実装される。
【０００７】
この他に、ＶＭＭが計算機システムの実ＨＷ上に実装される構成も知られている。実ＨＷ上に実装されるＶＭＭはＶＭＭ機構と呼ばれ、実質的にＯＳとして機能する。ＶＭＭ機構は、実プロセッサ及び実Ｉ／Ｏ装置のような実ＨＷを仮想化して各ゲストＯＳに機能として提供する。ＶＭＭ機構の上には、仮想計算機実行環境が当該ＶＭＭ機構により構築される。ＶＭＭ機構は仮想プロセッサ及び仮想Ｉ／Ｏ装置のような仮想ＨＷをエミュレートする。或いはＶＭＭ機構は、実プロセッサ、実Ｉ／Ｏ装置及び実メモリ装置のような実ＨＷ（ＨＷリソース）を時間的及び領域的に、仮想プロセッサ、仮想Ｉ／Ｏ装置及び仮想メモリ装置のような仮想ＨＷに割り当てる。このようにしてＶＭＭ機構は、仮想計算機実行環境を構築する。ゲストＯＳは仮想計算機実行環境にロードされて、仮想プロセッサにより実行される。
【０００８】
仮想計算機実行環境内でゲストＯＳが実行される環境は、ゲストＯＳ実行環境と呼ばれる。一般に仮想計算機システムでは、複数のゲストＯＳが実行される。そこで、複数のゲストＯＳの各々が実行される実行環境においては、ゲストＯＳ間で通信を行うための通信手段があると便利である。そのためＶＭＭは、このような通信手段を提供する。
【０００９】
この通信手段の代表的な機能は、
（１）ゲストＯＳ間割り込み機能
（２）ゲストＯＳ間共有メモリ機能
（３）ゲストＯＳ間メッセージ送受信機能
である。
【００１０】
ゲストＯＳ間割り込み機能とは、ゲストＯＳから指定した他のゲストＯＳに割り込みを送る機能である。受信側には、この割り込みが、いずれのゲストＯＳから送られたものかを知る手段を、例えば割り込み要因情報により提供される。
【００１１】
ゲストＯＳ間共有メモリ機能とは、特定のゲストＯＳ間で、メモリ空間を共有する仕組みである。送信側となるゲストＯＳがデータを書き込んだ後、受信側となるゲストＯＳがそのデータを読み取ることでデータの授受が可能である。データの授受の同期化には、上記ゲストＯＳ間割り込みの仕組みを使えば良い。
【００１２】
ゲストＯＳ間メッセージ送受信機能とは、送信側のゲストＯＳが送信されるべきデータ（送信データ）と送信先（受信側）のゲストＯＳとを指定してＶＭＭに依頼すると、指定されたデータを当該ＶＭＭが送信先のゲストＯＳの受信バッファにコピーして、その後に受信割り込みを当該送信先のゲストＯＳに設定する機能である。
【００１３】
ゲストＯＳ間割り込み機能及びゲストＯＳ間共有メモリ機能を併用するか、或いはゲストＯＳ間メッセージ送受信機能を単独で使用することにより、基本的なゲストＯＳ間通信が実現できる。
【特許文献１】特開２００６−０３９７６３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
従来の仮想計算機システムにおいて、上述の通信機能をプリミティブな仕組みに使うことにより、ＶＭＭが提供する仮想計算機実行環境内で実行されるゲストＯＳ間で、例えばＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）のような通信プロトコルをゲストＯＳ間で実現することができる。そこで、複数のゲストＯＳが、上記の仕組みで互いに通信を行い協調しながらサービスを提供することが考えられる。例えば、外部の通信路（外部ネットワーク）に直接つながるゲストＯＳがファイヤーウォール（ＦＷ）となり、他のゲストＯＳが仮想ネットワーク経由でそのゲストＯＳに接続されるような利用形態が考えられる。
【００１５】
ところが、ゲストＯＳ間で通信をしながら処理を進めるような利用形態の場合に、通信の処理効率が良くならない場合がある。これについて、例を挙げて説明する。
【００１６】
まず、ＶＭＭが構築する仮想計算機実行環境で４つのゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ及び＃Ｄが稼動しており、これらのゲストＯＳのうちのゲストＯＳ＃Ａ及び＃Ｃが互いに通信しながら処理を進めるものとする。更に具体的に述べるならば、ゲストＯＳ＃Ａ中の「プロセス＃ａ」とゲストＯＳ＃Ｃ中の「プロセス＃ｃ」とが互いに送受信しながら処理を進めているものとする。
【００１７】
ＶＭＭは、前述のゲストＯＳ間の通信のための３つの機能、つまりゲストＯＳ間割り込み機能、ゲストＯＳ間共有メモリ機能及びゲストＯＳ間メッセージ送受信機能をサポートしている。ゲストＯＳ＃Ａ及び＃Ｃは、これらの機能を使って通信している。
【００１８】
例えば、プロセス＃ａ及び＃ｃがＴＰＣ／ＩＰのインターフェイスでそれぞれのゲストＯＳに送受信要求を行うものとする。この場合、各ゲストＯＳは、その送受信要求を受け取って処理し、ＶＭＭが提供するゲストＯＳ間通信手段で相手にメッセージ送信を行う。ＶＭＭの提供する代表的なゲストＯＳ間通信手段は、例えば「ゲストＯＳ間メッセージ送受信機能」である。
【００１９】
ゲストＯＳ＃Ａ及び＃Ｃの間で、次の４つの処理が繰り返されるものとする。
（１）ゲストＯＳ＃Ａ（プロセス＃ａ）は３つのメッセージ（ネットワークパケット）をゲストＯＳ＃Ｃに送る（処理ａ１）。
（２）ゲストＯＳ＃Ｃ（プロセス＃ｃ）はゲストＯＳ＃Ａから送られた３つのメッセージを受信して処理する（処理ｃ１）。
（３）ゲストＯＳ＃Ｃ（プロセス＃ｃ）は受信メッセージの処理の結果、新たなメッセージ１つを生成して、そのメッセージをゲストＯＳ＃Ａに送る（処理ｃ２）。
（４）ゲストＯＳ＃Ａ（プロセス＃ａ）はゲストＯＳ＃Ｃから送られたメッセージを受信して処理する（処理ａ２）。
【００２０】
この４つの処理が繰り返される場合の動作シーケンスを図４（ａ）に示す。この図では、処理ａ１及びａ２を合わせた処理が処理ａと表現され、処理ｃ１及び処理ｃ２を合わせた処理が処理ｃと表現されている。図４（ａ）において、横軸は時間の経過を示す。
【００２１】
「τ」はＶＭＭが各ゲストＯＳにプロセッサ（ＣＰＵ）を割り当てる時間の単位を示し、一般にクオンタム（タイムクオンタム）と呼ばれる。説明を簡単にするために、図４（ａ）の例では、クオンタムτの途中でゲストＯＳの切り替えが発生しないものとする。つまり図４（ａ）の例では、時刻ｔn+1，ｔn+2，ｔn+3及びｔn+4からそれぞれ始まるクオンタムτでは、ゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ及び＃Ｄにプロセッサが割り当てられる。同様に、時刻ｔn+5，ｔn+6，ｔn+7及びｔn+8からそれぞれ始まるクオンタムτでも、ゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ及び＃Ｄにプロセッサが割り当てられる。但し、実際の例では、割り込み発生のようなイベントにより、クオンタム途中でのゲストＯＳ切り替えも発生する。
【００２２】
図４（ａ）において、下向きの矢印は送信メッセージを示し、上向きの矢印は受信メッセージを示す。また、矢印の数はメッセージ数を示す。更に、上向きの矢印（受信メッセージ）の下に付されているτを含む符号は、対応するメッセージがそのτを含む符号で示される時間で送られことを示す。また、τを含む符号の下に記載された括弧内の英記号は、対応するメッセージがその英記号で示されるゲストＯＳから送られたことを示す。
【００２３】
図４（ａ）の例では、上述のように時刻ｔn+1でゲストＯＳ＃Ａにプロセッサがディスパッチされて当該ゲストＯＳ＃Ａが動き出す。そして、ゲストＯＳ＃Ａのプロセス＃ａが動き出して、処理ａ１を行う。これにより、３つのメッセージがゲストＯＳ＃Ｃに送られる。するとプロセス＃ａは、その時刻ｔｘ以降、少なくともゲストＯＳ＃Ｃからメッセージが返されるまでは、処理（処理ａ２）ができなくなる。また、ゲストＯＳ＃Ｃからメッセージが返されても、ゲストＯＳ＃Ａが動作可能でない場合には、当該ゲストＯＳ＃Ａが動作可能となるまでプロセス＃ａは処理（処理ａ２）ができなくなる。但し、処理ａ１と処理ａ２の処理時間の和がクオンタムτに対して小さいとすると、クオンタムτの残りの時間内で、ゲストＯＳ＃Ａのプロセス＃ａ以外の処理を行うことは可能である。
【００２４】
ＶＭＭは、ゲストＯＳ＃Ａのプロセス＃ａによって送信されたメッセージをゲストＯＳ＃Ｃに送る。しかし、この時点ではゲストＯＳ＃Ｃは未だ動いていない。図４（ａ）の例において、ゲストＯＳ＃Ｃが動くことができるのは時刻ｔn+3からである。このため、処理ａ１でゲストＯＳ＃Ｃに送られたメッセージは、当該ゲストＯＳ＃Ｃで直ちには受信されず、時刻ｔn+3になりようやく受信される。
【００２５】
ゲストＯＳ＃Ｃのプロセス＃ｃは、処理ｃ１及びｃ２に要する時間がτに対して小さいとするならば、当該処理ｃ１及びｃ２を行い、メッセージを１つゲストＯＳ＃Ａに送る。その後（時刻ｔｙ以降）、ゲストＯＳ＃Ｃのプロセス＃ｃの処理は継続できず、当該ゲストＯＳ＃Ｃ内の他のプロセスが処理される。
【００２６】
ゲストＯＳ＃Ａは、時刻ｔn+1から４τ後の時刻ｔn+5に再び動作可能となり、先にゲストＯＳ＃Ｃから送られたメッセージを受信して処理する（処理ａ２）。
【００２７】
このようにして、一連の処理ａ１，ｃ１，ｃ２及びａ２は４τの時間（周期）をかけて実行される。図４（ａ）からも明らかなように、このような状況はプロセス＃ａ及び＃ｃにとって非常に効率が悪い。
【００２８】
そこで、保留（ペンディング）しているゲストＯＳに割り込みに応じてプロセッサを優先的にディスパッチすることが考えられる。先に述べたように、ゲストＯＳ間通信は送信先への割り込みとして実現される。したがって、このディスパッチ手法を適用することにより、通信メッセージが送られるタイミングで送信先のゲストＯＳにプロセッサがディスパッチされる。
【００２９】
ところが、上述のディスクパッチ手法では、メッセージ送信のたびにゲストＯＳが切り替わることになる。すると、今度はゲストＯＳ切り替えのオーバヘッドが目立って大きなコストになりかねない。更に、上述の例のように複数のメッセージが送られないとプロセス＃ｃが次の処理を行えないような場合、次に述べるようにシステム性能の低下を招く可能性がある。
【００３０】
まず、プロセス＃ａの１つ目のメッセージ送信で制御を渡されただけでは、プロセス＃ｃは、残りの２つのメッセージがないので処理ｃ１を終えることができない。つまり、プロセス＃ｃは、再度ゲストＯＳ＃Ａがスケジューリングされて、当該ゲストＯＳ＃Ａから残りの全ての（２つの）メッセージが送られるのを待つ必要がある。このため、状況によっては、割り込みに伴うゲストＯＳの切り替えの結果、システム性能の低下を招く可能性がある。
【００３１】
更に他の手法として、クオンタムτをより小さい値に設定することが考えられる。τの値が小さいほど、各ゲストＯＳが実行される機会を増やすことができる。この場合、メッセージを送られた後、より短い時間でメッセージ送信先のゲストＯＳが動作可能となるため、メッセージ受信処理が早期に行われる。しかし、τを小さくすると「ゲストＯＳ切り替えコスト」が増加し、システム全体の効率が低下する。
【００３２】
一般にτは、対象となるシステムにおいて「システムのレスポンス時間が良好（τの値を小さくする方向）」で、且つ「ゲストＯＳの切り替えコストが目立たない（悪影響を及ぼさない）（τの値を大きくする方向）」ような最適な値に設定される。このため、本来最適な値に設定されているτの値を小さくすると、システム全体の効率が悪くなる虞がある。
【００３３】
本発明は上記事情を考慮してなされたものでその目的は、ゲストＯＳ間で通信をしながら処理を進める場合における通信処理効率の向上が図れるゲストＯＳスケジューリングを実現するゲストＯＳスケジューリング方法及び仮想計算機モニタを提供することにある。
【課題を解決するための手段】
【００３４】
本発明の１つの観点によれば、仮想計算機モニタによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行され、前記複数のゲストＯＳのうちの任意のゲストＯＳ間で前記仮想計算機モニタによって提供される通信機能を用いて相互に通信を行いながら処理が進められる仮想計算機システムに適用されるゲストＯＳスケジューリング方法が提供される。このゲストＯＳスケジューリング方法は、前記仮想計算機モニタが提供する通信機能を用いて相互に通信するゲストＯＳの組を前記仮想計算機モニタが特定するステップと、前記複数のゲストＯＳのうち、前記特定されたゲストＯＳの組に含まれる各ゲストＯＳの実行スケジュールにおけるクオンタムを前記仮想計算機モニタが短くするステップとを具備する。
【発明の効果】
【００３５】
本発明によれば、ゲストＯＳ間で相互に通信を行いながら連携して処理を行うような場合に、そのゲストＯＳの実行スケジュールにおけるクオンタムだけを短くすることにより、このような通信で従来は発生する通信遅延による性能劣化を、他のゲストＯＳに何ら影響を及ぼすことなく改善することが可能となる。
【発明を実施するための最良の形態】
【００３６】
以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る仮想計算機システム（ＶＭシステム）を実現する計算機システム１の構成を示すブロック図である。計算機システム１は、実計算機を構成するハードウェア（ＨＷ）１０を備えている。ＨＷ１０は、周知のように、実プロセッサ１１、Ｉ／Ｏ装置（入出力装置）１２及びメモリ（図示せず）を含む。ＨＷ１０上では、ホストＯＳと呼ばれるＯＳ２０が動作する。ＯＳ（ホストＯＳ）２０上では仮想計算機アプリケーション（ＶＭアプリケーション）３０を含む各種のアプリケーションが実行される。
【００３７】
ＶＭアプリケーション３０の内部には、仮想計算機モニタ（Virtual Machine Monitor：ＶＭＭ）３１が存在する。つまり、ＶＭアプリケーション３０の実行によりＶＭＭ３１が実現される。ＶＭＭ３１は、ＶＭシステムの管理を行い、仮想計算機システム（ＶＭシステム）の環境（仮想計算機実行環境）を構築する。図１では、４つの仮想計算機実行環境３２Ａ，３２Ｂ，３２Ｃ及び３２Ｄが構築されている例が示されている。
【００３８】
仮想計算機実行環境３２ｉ（ｉ＝Ａ，Ｂ，Ｃ，Ｄ）は、仮想ＨＷ環境（仮想ＨＷ装置）３３ｉ及びゲストＯＳ実行環境３４ｉからなる。仮想ＨＷ環境３３ｉは、仮想プロセッサ（ＶＰ）３３１ｉ、仮想Ｉ／Ｏ装置３３２ｉ及び仮想的なメモリ装置（図示せず）のような仮想ＨＷ群を含む。ＶＭＭ３１は、論理的にこれらの仮想ＨＷをエミュレートして、上述の仮想計算機実行環境３２ｉを実現する。ＶＭＭ３１は、この仮想計算機実行環境３２ｉ内のゲストＯＳ実行環境３４ｉに、当該ゲストＯＳ実行環境３４ｉで動作するＯＳをゲストＯＳ３５ｉ（＃ｉ）としてロードする。ゲストＯＳ実行環境３４ｉにロードされたゲストＯＳ３５ｉ（＃ｉ）は、当該ゲストＯＳ実行環境３４ｉ内で実行される。
【００３９】
ＶＭＭ３１は、仮想ＨＷ環境３３ｉに含まれる仮想的なメモリ装置（仮想メモリ装置）にゲストＯＳ３５ｉ（＃ｉ）のコードを展開し、その実行コードを仮想プロセッサ３３１ｉのエミュレートという形で実行する。これによりＶＭＭ３１は、ゲストＯＳ３５ｉの処理を進める。ゲストＯＳ３５ｉからのＩ／Ｏ要求は、ＶＭＭ３１が仮想Ｉ／Ｏ装置３３２ｉのエミュレートを行うことにより処理する。
【００４０】
図２は、図１に示されるＶＭＭ３１の構成を示すブロック図である。ＶＭＭ３１は、スケジューラ３１１、ディスパッチャ３１２、ゲストＯＳ間通信サービス機構３１３、通信状態テーブル３１４及び相互通信ゲストＯＳテーブル３１５を含む。
【００４１】
スケジューラ３１１は、各ゲストＯＳ３５ｉ（＃ｉ）のスケジュールを決定する。スケジューラ３１１が適用するスケジューリングポリシとして種々考えられるが、ここでは単純なラウンドロビン方式によるスケジューリングが適用されるものとする。即ちスケジューラ３１１は、基本的には、タイムクオンタム（τ）と呼ばれる時間単位毎に、各ゲストＯＳ３５ｉ（＃ｉ）を順番に実行するように、ディスパッチャ３１２に指示する。但し本実施形態では、スケジューラ３１１は、タイムクオンタムの値を状況により変える指示もディスパッチャ３１２に送る。
【００４２】
ディスパッチャ３１２は、スケジューラ３１１の指示に従って実際にゲストＯＳ３５ｉ（＃ｉ）にプロセッサ（実プロセッサ１１）をディスパッチする。ディスパッチャ３１２はまた、スケジューラ３１１によって指示されたタイムクオンタムの時間が経過したならば、ゲストＯＳ３５ｉ（＃ｉ）からプロセッサ（実プロセッサ１１）を取り上げて、次のゲストＯＳに当該プロセッサを割り当てる。ディスパッチャ３１２は、これらの処理を繰り返す。
【００４３】
ゲストＯＳ間通信サービス機構３１３は、各ＯＳ３５ｉ（＃ｉ）からＶＭＭ３１に要求される、ゲストＯＳ間通信要求を処理するゲストＯＳ間通信手段として機能する。ゲストＯＳ間通信は、ＶＭＭ３１に対するＨｙｐｅｒｖｉｓｏｒ呼び出し（システムコール）の形で発行される。この呼び出しでは、送り先のゲストＯＳ及びメッセージデータが指定される。ゲストＯＳ間通信サービス機構３１３は、指定されたゲストＯＳに対して指定されたメッセージを届けると共に、受信割り込みを設定する。この受信割り込みは、その後、送信先のゲストＯＳにプロセッサがディスパッチされた時点で当該送信先のゲストＯＳに入る。このとき、送信先のゲストＯＳは、ゲストＯＳ間通信サービス機構３１３によって送られたメッセージデータを受信データとして参照することができる。
【００４４】
通信状態テーブル３１４は、ゲストＯＳ間通信サービス機構３１３が処理したメッセージ送信に関する情報を保持するのに用いられる。更に詳細に述べるならば、通信状態テーブル３１４は、ゲストＯＳ３５ｉを送信元、ゲストＯＳ３５ｊ（ｊ≠ｉ）を送信先とする、メッセージ送信に関する情報を保持するのに用いられる。なお、以下の説明では、ゲストＯＳ３５Ａ，３５Ｂ，３５Ｃ，３５Ｄ，３５ｉ及び３５ｊを、それぞれゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ，＃Ｄ，＃ｉ及び＃ｊのように表現する。
【００４５】
相互通信ゲストＯＳテーブル３１５は、後述する１スケジュール周期内に受信されるメッセージを互いに送信しているゲストＯＳの対を相互通信ゲストＯＳ対として保持するのに用いられる。
【００４６】
図３は図１に示す計算機システム１によって実現されるＶＭシステム（仮想計算機システム）のシステム状態の一例を示す。ここでは、ＶＭＭ３１が構築する仮想計算機実行環境３２Ａ，３２Ｂ，３２Ｃ及び３２Ｄ（図１参照）で、それぞれゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ及び＃Ｄが稼動している。図３に示すシステム状態では、ゲストＯＳ＃Ａ中の「プロセス＃ａ」とゲストＯＳ＃Ｃ中の「プロセス＃ｃ」とが互いに送受信しながら処理を進めている。更に具体的に述べるならば、ゲストＯＳ＃Ａ中の「プロセス＃ａ」とゲストＯＳ＃Ｃ中の「プロセス＃ｃ」の間で、［発明が解決しようとする課題］の欄に記載されたような４つの処理（ａ１，ｃ１，ｃ２及びａ２）が繰り返し実行されている。
【００４７】
図４は、この４つの処理が繰り返される場合の動作シーケンスを、再スケジューリングの前後で対比して示す。図４において、同図（ａ）は再スケジューリング前の動作を示す動作シーケンス、同図（ｂ）は再スケジューリング後の動作を示す動作シーケンスである。図４において、下向きの矢印は送信メッセージを示し、上向きの矢印は受信メッセージを示す。また、矢印の数はメッセージ数を示す。更に、上向きの矢印（受信メッセージ）の下に付されているτを含む符号は、対応するメッセージがそのτを含む符号で示される時間（例えば２τであれば２τの時間）で送られことを示す。また、τを含む符号の下に記載された括弧内の英記号は、対応するメッセージがその英記号で示されるゲストＯＳ（例えば（Ａ）であればゲストＯＳ＃Ａ）から送られたことを示す。
【００４８】
図５は、図２に示される通信状態テーブル３１４の一例を、スケジュール対象となるゲストＯＳがゲストＯＳ＃Ａ，＃Ｂ，＃Ｃ，＃Ｄである場合について示す。通信状態テーブル３１４は、ゲストＯＳ＃ｉ（ｉ＝Ａ，Ｂ，Ｃ，Ｄ）を送信元、ゲストＯＳ＃ｊ（ｊ＝Ａ，Ｂ，Ｃ，Ｄ、但しｊ≠ｉ）を送信先とする全ての組み合わせについて、メッセージ送信に関する情報（以下、通信状態情報と称する）を保持するエントリ＃ｉｊを有している。
【００４９】
通信状態情報は、１スケジュール周期中に発行されたメッセージ数及びメッセージ受信までに要した平均時間の値を含む。図５の例では、平均時間は括弧内に記述されている。
【００５０】
「１スケジュール周期」は、
τ×（そのときの）スケジュール対象のゲストＯＳ数
で表されるものとする。つまり１スケジュール周期は、本実施形態のように単純なラウンドロビンがクオンタムτで行われている場合には、各ゲストＯＳにプロセッサがディスパッチされた時点から次のディスパッチ時点までの時間となる。図４では、例えばｔn+1〜ｔn+5が１スケジュール周期であり、４τである。
【００５１】
ゲストＯＳ＃ｉを送信元、ゲストＯＳ＃ｊを送信先とする通信状態情報は、ゲストＯＳ間通信サービス機構３１３によって作成される。通信状態テーブル３１４のエントリ＃ｉｊの情報は、この作成された通信状態情報に更新される。スケジューラ３１１は、通信状態テーブル３１４内の更新された通信状態情報（各通信状態情報）を、各スケジュール周期の完了時点で参照することが可能となる。
【００５２】
図５の通信状態テーブル３１４は、図４（ａ）の動作シーケンスで示されるメッセージ送信の状況（通信状態）を表している。例えば、送信元ゲストＯＳ＃Ａ及び送信先ゲストＯＳ＃Ｃに対応する、通信状態テーブル３１４のエントリには、ゲストＯＳ＃Ａ及び＃Ｃ間の最近の１スケジュール周期あたりのメッセージ送信に関する通信状態情報として、「３（２τ）」が保持されている。値「３」は、「１スケジュール周期時間よりも短い時間以内に受信されたメッセージの個数」を表し、括弧内の値「２τ」は、ゲストＯＳ＃Ａ及び＃Ｃ間でメッセージを送信する際に要した平均時間を表す。
【００５３】
本実施形態では、スケジューラ３１１は、スケジュール周期毎にクオンタムを調整する処理（クオンタム調整処理）を次のように行う。まずスケジューラ３１１は、通信状態テーブル３１４を参照して、各ゲストＯＳ間での通信発生状況から、密に相互通信を行っている「ゲストＯＳの対」を探す。スケジューラ３１１は、目的とするゲストＯＳの対が見つかったなら、それらのゲストＯＳに対するプロセッサ割り当て粒度を小さくすることにより、メッセージ送信の遅延の改善を行う。スケジューラ３１１は以上の処理（クオンタム調整処理）をスケジュール周期毎に実行する。なお、クオンタム調整処理が複数スケジュール周期毎に実行されても構わない。
【００５４】
以下、スケジューラ３１１によるクオンタム調整処理の手順について、図６のフローチャートを参照して説明する。まずスケジューラ３１１は、密に相互に通信しているゲストＯＳ（相互通信ゲストＯＳ）の対を全て検出する（ステップＳ１１）。具体的に述べるならば、スケジューラ３１１は、図５に示される通信状態テーブル３１４を参照することにより、１スケジュール周期内に受信されるようなメッセージを互いに送信しているゲストＯＳ＃ｉ，＃ｊの対を全て探し求める。ここで探し求められるゲストＯＳ＃ｉ，＃ｊの対とは、１スケジュール周期内にゲストＯＳ＃ｊで受信されるようなメッセージの送信を行うゲストＯＳ＃ｉと、当該ゲストＯＳ＃ｉで当該１スケジュール周期と同一周期で受信されるようなメッセージの送信を行うゲストＯＳ＃ｊとの対（ゲストＯＳ＃ｉ，＃ｊの対）である。
【００５５】
本実施形態では、上記ステップＳ１１において、通信状態テーブル３１４によって示されるゲストＯＳの組み合わせ毎のメッセージ数が参照されて、メッセージ数が０でない（非０である）ゲストＯＳの組み合わせ（ゲストＯＳ対）が、目的のゲストＯＳの組み合わせ（相互通信ゲストＯＳ対）として検索される。そして検索された全てのゲストＯＳ対のリスト（リスト“Ｌ”）が作成される。図５の通信状態テーブル３１４の例では、ゲストＯＳ＃Ａ及び＃Ｃの対のみを要素として含むリスト“Ｌ”が作成される。
【００５６】
スケジューラ３１１は、作成されたリスト“Ｌ”と相互通信ゲストＯＳテーブル３１５とを比較して、当該テーブル３１５に未登録のゲストＯＳ対（を示す情報）がリスト“Ｌ”に含まれているならば、そのゲストＯＳ対（を示す情報）を当該テーブル３１５に追加登録する（ステップＳ１２）。
【００５７】
またスケジューラ３１１は、リスト“Ｌ”に存在しないが相互通信ゲストＯＳテーブル３１５に既に登録されているゲストＯＳ対が存在するならば、つまりリスト“Ｌ”に存在しないゲストＯＳ対のエントリが相互通信ゲストＯＳテーブル３１５にあるならば、そのエントリ（の情報）を当該相互通信ゲストＯＳテーブル３１５から削除する（ステップＳ１３）。このステップＳ１３の処理で削除されるゲストＯＳの対は、以前に相互に通信し合っていたが、最近になって通信しなくなったゲストＯＳの対である。
【００５８】
図７はステップＳ１２及びＳ１３が実行された後の相互通信ゲストＯＳテーブル３１５の一例を示す。図７の例では、相互通信ゲストＯＳテーブル３１５の先頭エントリに、相互通信ゲストＯＳの対（相互通信ゲストＯＳ＃ｉ及び＃ｊの対）として、ゲストＯＳ＃Ａ及び＃Ｃの対が登録されている。
【００５９】
次にスケジューラ３１１は、相互通信ゲストＯＳテーブル３１５を参照して「密連結ゲストＯＳグループ」を作成する（ステップＳ１４）。「密連結ゲストＯＳグループ」とは、相互通信ゲストＯＳテーブル３１５に登録されているゲストＯＳの対の集合（つまりゲストＯＳの組）であって、あるゲストＯＳと対をなすゲストＯＳ以外に、当該あるゲストＯＳとの間で相互通信をしている別のゲストＯＳが存在する場合には、当該別のゲストＯＳを含めたゲストＯＳの集合（ゲストＯＳの組）である。そこで、相互通信ゲストＯＳテーブル３１５の各エントリは、ゲストＯＳの対を登録するための欄に加えて、この欄に登録されたゲストＯＳが属するグループのＩＤ（グループＩＤ）を登録するための欄を含む。
【００６０】
図７の相互通信ゲストＯＳテーブル３１５の例では、ゲストＯＳ＃Ａ及び＃Ｃのみが密連結ゲストＯＳグループを形成する。しかし、通信状態テーブル３１４が例えば図９のような場合には、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄが密連結ゲストＯＳグループを形成する。つまり密連結ゲストＯＳグループとは、相互に頻繁にメッセージを授受しているゲストＯＳの集合である。
【００６１】
上記ステップＳ１４においてスケジューラ３１１は、作成された密連結ゲストＯＳグループ毎にユニークなＩＤ（例えば番号）をグループＩＤとして付与し、当該ＩＤを相互通信ゲストＯＳテーブルのグループＩＤ欄に記入する。
【００６２】
スケジューラ３１１はステップＳ１４を実行するとステップＳ１５の処理に進む。ステップＳ１５においてスケジューラ３１１は、各密連結ゲストＯＳグループに関して、当該グループに属するゲストＯＳが元々クオンタムτの単位でスケジューリングされていた時間帯を、当該グループに属するゲストＯＳの再スケジューリングのためにτ／ｎの長さに分割する。このｎを分割定数と呼ぶ。本実施形態において分割定数ｎの値は、予め定められた一定値であり、２であるものとする。但し、このｎの値は、後述するように動的に変更された方が良い。スケジューラ３１１は、ステップＳ１５において更に、再スケジューリングの対象となる各ゲストＯＳをτ／ｎの時間単位で順に実行させる新しいスケジュール（を表すスケジュール表）を作成（決定）する。
【００６３】
次にスケジューラ３１１は、作成された新しいスケジュール（スケジュール表）の情報をディスパッチャ３１２に渡して、当該スケジュールに基づく再スケジューリングをディスパッチャ３１２に指示する（ステップＳ１６）。これによりディスパッチャ３１２は、スケジューラ３１１から渡された新しいスケジュールに従って、実際にゲストＯＳ（ゲストＯＳ＃Ａ及び＃Ｃ）にプロセッサをディスパッチする再スケジューリングを行う。
【００６４】
「クオンタム調整処理」の結果、上述したように、ゲストＯＳ＃Ａ及び＃Ｃが相互にメッセージを授受している本実施形態では、これらのゲストＯＳ＃Ａ及び＃Ｃが、同一の「密連結ゲストＯＳグループ」に属すこととなる。その結果、ゲストＯＳ＃Ａ及び＃Ｃに関して、τ／２の時間単位でのプロセッサ割り当てが再スケジューリングされ、その結果、図４（ｂ）のような実行状態となる。ここで、密連結ゲストＯＳグループに属さないゲストＯＳ＃Ｂ及び＃Ｄは、依然としてτの時間単位で１スケジュール周期（＝４τ）毎にプロセッサ割り当てがスケジューリングされる。つまり本実施形態では、密連結ゲストＯＳグループに属するゲストＯＳを対象とする再スケジューリングが、他のゲストＯＳのスケジューリングに影響を及ぼすことはない。
【００６５】
図４（ｂ）の例では、ゲストＯＳ＃ＡからゲストＯＳ＃Ｃへのメッセージ送信の平均時間、及びゲストＯＳ＃ＣからゲストＯＳ＃Ａへのメッセージ送信の平均時間は、それぞれ、ほぼ０．５τ及び１．５τとなる。この場合、一連の前述の４つの処理（ａ１，ｃ１，ｃ２及びａ２）の周期（平均処理周期）は、図４（ａ）に示される４τから図４（ｂ）に示される２τに改善される。
【００６６】
このように本実施形態においては、ゲストＯＳ間で相互に通信を行いながら連携して処理を行う場合に、そのゲストＯＳの実行スケジュールにおけるクオンタムだけを短くすることにより、このような通信で従来は発生する通信遅延による性能劣化を、他のゲストＯＳに何ら影響を及ぼすことなく改善することができる。特に、仮想計算機システムのゲストＯＳ間通信は、メモリベースで実装されることが多く、それ自体オーバヘッドが小さいものであ。このため仮想計算機システムのゲストＯＳ間通信は、実ネットワークでの通信に比べて非常に遅延時間（レイテンシ）が小さいものとして使用できる可能性がある。よって本実施形態においては、仮想計算機システムの高速なゲストＯＳ間通信機構の性能を十分引き出すことができ、従来に比べてシステム全体で性能が高い仮想計算機システムを実現できる。
【００６７】
図４の例では、ゲストＯＳ＃Ａ及び＃Ｃによってそれぞれ実行される処理＃ａ及び＃ｃ以外の処理は考慮されていない。このため、実際には、常に図４（ｂ）のような結果になる保証はない。しかしながら、図４（ａ）の状況では、ゲストＯＳ＃Ａ及び＃Ｃがどのような負荷状況にあったとしても、当該図４（ａ）に示される以上のスループットは得られない。本実施形態では、図４（ｂ）に示されるように、負荷状態によっては効率良く処理されるように改善される。
【００６８】
次に、本実施形態における再スケジューリングによる処理効率の他の改善例を、ゲストＯＳ＃Ａ（中のプロセス＃ａ）、ゲストＯＳ＃Ｃ（中のプロセス＃ｃ）及びゲストＯＳ＃Ｄ（中のプロセス＃ｄ）が互いに送受信しながら処理を進める場合について、再スケジューリング前と対比して図８に示す。図８において、同図（ａ）は再スケジューリング前の動作を示す動作シーケンス、同図（ｂ）は再スケジューリング後の動作を示す動作シーケンスである。この例でも、ｎが２であるものとする。
【００６９】
図８の例では、１スケジュール周期毎に、以下に挙げる６つの処理が行われる。
（１）ゲストＯＳ＃Ａ（プロセス＃ａ）は３つのメッセージ（ネットワークパケット）の２つをゲストＯＳ＃Ｃに、１つをゲストＯＳ＃Ｄに、それぞれ送る（処理ａ′１）
（２）ゲストＯＳ＃Ｃ（プロセス＃ｃ）はゲストＯＳ＃Ａから送られた２つのメッセージを受信して処理する（処理ｃ′１）。
（３）ゲストＯＳ＃Ｃ（プロセス＃ｃ）は受信メッセージの処理の結果、新たなメッセージ１つを生成して、そのメッセージをゲストＯＳ＃Ｄに送る（処理ｃ′２）。
（４）ゲストＯＳ＃Ｄ（プロセス＃ｄ）はゲストＯＳ＃Ｃから送られた１つのメッセージを受信して処理する（処理ｄ′１）。
【００７０】
（５）ゲストＯＳ＃Ｄ（プロセス＃ｄ）は受信メッセージの処理の結果、新たなメッセージ１つを生成して、そのメッセージをゲストＯＳ＃Ａに送る（処理ｄ′２）。
（６）ゲストＯＳ＃Ａ（プロセス＃ａ）はゲストＯＳ＃Ｃ及び＃Ｄから送られたメッセージを受信して処理する（処理ａ′２）。
【００７１】
ここで、処理（送信処理）ａ′１及びｃ′２、並びに処理（送信処理）ａ′１及びｄ′２は、それぞれａ′１→ｃ′２、ａ′１→ｄ′２のように、順番に処理される必要がある。
【００７２】
図８（ａ）の状態における通信状態テーブル３１４の例を図９に示す。また、図９に示される通信状態テーブル３１４の状態に基づいて「クオンタム調整処理」が行われた結果としての相互通信ゲストＯＳテーブル３１５の一例を図１０に示す。図８（ｂ）は、図１０に示される相互通信ゲストＯＳテーブル３１５に基づいて作成される新しいスケジュールに従って、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄにプロセッサがディスパッチされた場合（つまり再スケジューリング後）の動作シーケンスを示す。
【００７３】
図１０に示される相互通信ゲストＯＳテーブル３１５の例では、「密連結ゲストＯＳグループ」がゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄから構成されている。この場合、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄに関して、τ／２の時間単位でのプロセッサ割り当てが再スケジューリングされる。この再スケジューリングにより、これら３つのゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄに対する時間割り当て粒度が小さくなる。これにより、前述の６つの処理（ａ′１，ｃ′１，ｃ′２，ｄ′１，ｄ′２，ａ′２）の動作シーケンスは、図８（ａ）に示される状態から図８（ｂ）に示される状態に改善される。ここで、密連結ゲストＯＳグループに属さないゲストＯＳ＃Ｂは、依然としてτの時間単位で１スケジュール周期（＝４τ）毎にプロセッサ割り当てがスケジューリングされる。
【００７４】
図８（ａ）における平均処理周期は４τ、図８（ｂ）における平均処理周期は２τである。これにより、図８（ｂ）における平均処理周期は、図８（ａ）の４τから２τ改善されたことがわかる。図８（ｂ）の状態における通信状態テーブル３１４の例を図１１に示す。
【００７５】
［変形例］
上記実施形態では、ｎの値が予め定められた一定値（ｎ＝２）である場合を想定している。このｎは、ゲストＯＳの割り当て時間単位を決める値（パラメータ値）である。上記実施形態では、τ×（１／ｎ）、つまりτ／ｎの時間単位で、プロセッサが割り当てられる。しかし、メッセージ通信に要する時間は、この割り当て時間τ／ｎにより影響を受ける。このため、ｎの値を適切に設定する必要がある。
【００７６】
そこで、ｎの値を適切に決める処理（ｎ値決定処理）を含むクオンタム調整処理がスケジューラ３１１によって実行される、上記実施形態の変形例について説明する。
【００７７】
図１２は本変形例で適用されるＶＭＭ３１の構成を示すブロック図である。図１２において、図２と同様の要素には便宜的に同一参照符号を付してある。図１２に示すＶＭＭ３１が、図２に示すＶＭＭ３１と相違するのは、ｎ値定義テーブル３１６及び平均通信時間テーブル３１７を含む点である。テーブル３１６及び３１７については後述する。
【００７８】
次に、ｎ値決定処理を含むクオンタム調整処理の概要について説明する。
（ａ）スケジューラ３１１は、密連結ＯＳグループ毎に別々のｎの値を使い、必要に応じてτの値を変える。密連結ＯＳグループＧｉのｎの値をｎiで表すと、スケジューラ３１１は、密連結ＯＳグループＧｉに属する各ゲストＯＳに対するプロセッサ割り当て時間が、再スケジューリング前の割り当て時間の１／ｎiになるように再スケジューリングする。
【００７９】
（ｂ）ｎの値は、取り得る値が予め決められているものとする。本変形例では、ｎの値は、ｄ0，ｄ1，ｄ2及びｄ3の４種類の値のいずれかとなる。ｄ0〜ｄ3の具体的な値は、ｎ値定義テーブル３１６によって定義される。
【００８０】
図１３は、ｎ値定義テーブル３１６の例を示す。図１３の例では、ｄ0〜ｄ3はｎの値（ｎ値）１〜４に対応する。このｎ値定義テーブル３１６の内容を変えるならば、つまりｄ0〜ｄ3の定義を変えるならば、種々のｎの値を定義することができる。
【００８１】
本変形例では、ｄ0〜ｄ3で示される値は、このｄ0〜ｄ3の順に大きくなる（つまり、クオンタムがより細かく分割される）ように定められているものとする。また、ｄ0（つまりｎの値の最小値）は１であるものとする。更に、本変形例において定義される最大のｎの値をｄmaxと表記するものとする。つまり本変形例では、ｄmax＝ｄ3である。
【００８２】
（ｃ）本変形例で適用されるｎ値決定処理を含むクオンタム調整処理では、ｄiで定義されるｎiの値が決定されてから、当該クオンタム調整処理がＡ回呼び出される間は実質的な決定処理は何も行われない。つまり本変形例においては、一度ｎ値決定処理でｎiの値が決まってからクオンタム調整処理がＡ回呼び出される間は、ｎiの値が変更されないようにしている。これにより、頻繁にｎiの値が変わることによる処理増加によるオーバヘッドの増加を防ぐことが可能となる。
【００８３】
本変形例においても、上記実施形態と同様に、スケジューラ３１１が、スケジュール周期毎にクオンタム調整処理を行う。つまりスケジューラ３１１は、通信状態テーブル３１４を参照して、各ゲストＯＳ間での通信発生状況から、密に相互通信を行っている（つまり１スケジュール周期内に受信されるようなメッセージを互いに送信している）ゲストＯＳの対を探す。そのようなゲストＯＳの対が見つかったなら、スケジューラ３１１は、それらゲストＯＳに対するプロセッサ割り当て粒度を小さくすることにより、メッセージ送信の遅延の改善を行う。但し、本変形例においてスケジューラ３１１は、密連結ＯＳグループ毎にｎの値を動的に変えることにより、当該グループ毎にプロセッサ割り当て粒度を調整する。なお、クオンタム調整処理が複数スケジュール周期毎に実行されても構わない。
【００８４】
次に、ｎ値決定処理を含むクオンタム調整処理の手順について、図１４Ａ及び図１４Ｂのフローチャートを参照して説明する。まずスケジューラ３１１は、クオンタム調整処理を繰り返し実行する前に、変数ＷＡＩＴ＿ＣＮＴを予め０に初期化する。この変数ＷＡＩＴ＿ＣＮＴは、クオンタム調整処理が行われるタイミングを調整するのに用いられる。
【００８５】
スケジューラ３１１はクオンタム調整処理が呼び出されると、変数ＷＡＩＴ＿ＣＮＴを参照して当該変数が０であるかを判定する（ステップＳ２１）。変数ＷＡＩＴ＿ＣＮＴが０でない場合、スケジューラ３１１は当該変数ＷＡＩＴ＿ＣＮＴを１デクリメントして（ステップＳ２２）、そのままクオンタム調整処理を終了する。
【００８６】
一方、変数ＷＡＩＴ＿ＣＮＴが０の場合には、スケジューラ３１１は密連結ＯＳグループ毎にプロセッサ割り当て粒度の調整処理を次のように行う。まずスケジューラ３１１は、上記実施形態におけるステップＳ１１乃至Ｓ１４に相当するステップＳ２３乃至２６を実行する。即ちスケジューラ３１１は、相互通信ゲストＯＳ対の検出及び相互通信ゲストＯＳ対のリスト“Ｌ”の作成（ステップＳ２３）、相互通信ゲストＯＳテーブルに存在しない新規検出相互通信ゲストＯＳ対の相互通信ゲストＯＳテーブル３１５への登録（ステップＳ２４）、リスト“Ｌ”に存在しないゲストＯＳ対のエントリの相互通信ゲストＯＳテーブル３１５からの削除（ステップＳ２５）、並びに密連結ゲストＯＳグループの作成（ステップＳ２６）を行う。
【００８７】
スケジューラ３１１は、ステップＳ２３乃至Ｓ２６を実行するとステップＳ２７の処理に進む。ステップＳ２７においてスケジューラ３１１は、平均通信時間テーブル３１７に、今回新規に検出された密連結ゲストＯＳグループのためのエントリ（の情報）を追加する。また、ステップＳ２７においてスケジューラ３１１は、前回までに検出されて平均通信時間テーブル３１７に登録されていた密連結ゲストＯＳグループのためのエントリであって、今回検出されなかった密連結ゲストＯＳグループのためのエントリ（の情報）を、当該平均通信時間テーブル３１７から削除する。
【００８８】
図１５は平均通信時間テーブル３１７の一例を示す。平均通信時間テーブル３１７は、密連結ゲストＯＳグループ毎のエントリを有する。平均通信時間テーブル３１７のエントリは、対応する密連結ゲストＯＳグループのｄ0〜ｄ3で定義されるｎの値毎の平均通信時間の測定値を登録するのに用いられる。この平均通信時間については後述する。
【００８９】
上記ステップＳ２７で、平均通信時間テーブル３１７に、新規に検出された密連結ゲストＯＳグループのためのエントリが追加された時点では、当該エントリの情報は初期化されている。ここでは、追加されたエントリで示されるｄ0〜ｄ3で定義されるｎの値毎の平均通信時間の情報が、「未定義（有効な値なし）」の状態（記号−で示される状態）に設定される。
【００９０】
スケジューラ３１１は、ステップＳ２７を実行すると、ｎ値決定処理（ステップＳ２８乃至Ｓ３６）を次のように実行する。まずスケジューラ３１１は、相互通信ゲストＯＳテーブル３１５に登録されている全ての密連結ゲストＯＳグループについてｎ値決定処理を実行したかを判定する（ステップＳ２８）。もし、ｎ値決定処理が未実行（未処理）の密連結ゲストＯＳグループが存在するならば、スケジューラ３１１は相互通信ゲストＯＳテーブル３１５から未処理の密連結ゲストＯＳグループを１つ密連結ゲストＯＳグループＧｉとして選択する（ステップＳ２９）。
【００９１】
スケジューラ３１１は、選択された密連結ゲストＯＳグループＧｉに対応する平均通信時間テーブル３１７のエントリの情報、つまり密連結ゲストＯＳグループＧｉの平均通信時間を更新する（ステップＳ３０）。平均通信時間とは、ｄk（ｋ＝０〜３）で定義されるｎの値が適用されている状態で、密連結ゲストＯＳグループＧｉに属するゲストＯＳが送信したメッセージのうち、１スケジュール周期内に送信先のゲストＯＳで受信されたメッセージに関して、それらメッセージが送信されてから受信されるまでに要した時間の平均である。ここで送信時より１スケジュール周期を越えて受信されたメッセージは、平均通信時間算出の対象から除かれる。
【００９２】
よって、密連結ゲストＯＳグループＧｉの平均通信時間は、当該グループＧｉに属するゲストＯＳ間で直近の１スケジュール周期内で授受されるメッセージの通信時間の総和（Σ（メッセージの通信時間）をメッセージ総数で除した値によって表される。つまり、密連結ゲストＯＳグループＧｉの平均通信時間は、次式
（Σ（メッセージの通信時間））／メッセージ総数 （１）
で表される。但し式（１）におけるメッセージとは、密連結ゲストＯＳグループＧｉに属する全てのゲストＯＳが送信したメッセージのうち、１スケジュール周期内に送信先のゲストＯＳで受信されるメッセージを指す。
【００９３】
このように本変形例において、平均通信時間の算定の対象とする期間は、直近の１スケジュール周期である。しかし、複数スケジュール周期で評価してそれらの平均を取って１スケジュール周期当たりの平均通信時間としても良い。
【００９４】
ここで、平均通信時間算出の具体例について、図８（ａ）の場合を例に説明する。図８（ａ）の例では、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄが１つの密連結ゲストＯＳグループを構成する。この密連結ゲストＯＳグループのグループＩＤを１とし、当該グループをＧ１、つまりＧｉ＝Ｇ１（ｉ＝１）と呼ぶことにする。ここで、クォンタムはτなので、ｎ＝１、つまりｄk＝ｄ0（ｋ＝０）のケースであり、通信状態テーブル３１４の内容は図９のようになる。
【００９５】
この場合の密連結ゲストＯＳグループＧｉ（Ｇ１）の平均通信時間は
（Σ（メッセージの通信時間））／メッセージ総数
＝（２×２τ＋１×３τ＋１×２τ＋１×τ）／５
＝２τ
のように求められる。
【００９６】
ステップＳ３０においてスケジューラ３１１は、求められた平均通信時間をＴとする。この例では、Ｔ＝２τである。ステップＳ３０においてスケジューラ３１１は、密連結ゲストＯＳグループＧｉ（Ｇ１）に対応する平均通信時間テーブル３１７のエントリに含まれているｄ0〜ｄ3の各欄のうち、現在適用されているｄk＝ｄ0（ｋ＝０）の欄に、求められた平均通信時間Ｔ（＝２τ）を設定する。つまりスケジューラ３１１は、ｄk＝ｄ0（ｋ＝０）の欄の旧設定情報を平均通信時間Ｔ（＝２τ）に更新する。ここで、更新後の平均通信時間Ｔは、密連結ゲストＯＳグループＧｉ（Ｇ１）及びｄk＝ｄ0（ｋ＝０）に関連する。そこで、更新後の平均通信時間ＴをＴi,kと表現する。ここでは、Ｔi,k＝Ｔ1,0（ｉ＝１，ｋ＝０）＝２τである。
【００９７】
次にスケジューラ３１１は、密連結ゲストＯＳグループＧｉの現在のｎの値（つまりｎiの値）をｄkとするとき、その値が最小値（１）であるか、つまりｄ0（ｋ＝０）であるかを判定する（ステップＳ３１）。もし、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）でないならば、スケジューラ３１１は今回求められた（ｄkにおける）平均通信時間Ｔi,kが０であるかを判定する（ステップＳ３２）。もし、平均通信時間Ｔi,kが０でないならば、スケジューラ３１１は当該平均通信時間Ｔi,kがｄk-1における平均通信時間Ｔi,k-1よりも小さいかを判定する（ステップＳ３３）。
【００９８】
もし、平均通信時間Ｔi,kがＴi,k-1よりも小さいならば、スケジューラ３１１は新しいｎ（＝ｎi）の値を現在の値ｄkよりも１段階大きいｄk+1に設定する（ステップＳ３４）。つまりスケジューラ３１１は、ＣＰＵ割り当て時間単位を現在よりも１段階細かくする。但し、ｄk+1が定義されていないならば、つまり現在の値ｄkがｎ値定義テーブル３１６によって定義される最大のｎの値ｄmaxであるならば、それ以上大きなｎの値を設定できない。このような場合、スケジューラ３１１は新しいｎ（＝ｎi）の値を現在の値ｄk、つまりｄmaxとする。スケジューラ３１１はステップＳ３４を実行すると、上記ステップＳ２８の処理に戻る。
【００９９】
一方、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）であるならば、つまり現在の値ｄkがｄ0（ｋ＝０）であるならば（ステップＳ３１）、スケジューラ３１１は平均通信時間Ｔi,k（ｋ＝０）が０でない限りにおいて（ステップＳ３５）、ｎ（＝ｎi）の値を現在の値ｄkよりも１段階大きいｄk+1とする（ステップＳ３４）。ここではｋ＝０であることから、ｎ（＝ｎi）の値がｄ0（＝１）からｄ1（＝２）に変更される。
【０１００】
次に、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）でなく、且つ今回求められた（ｄkにおける）平均通信時間Ｔi,kが０でないものの、当該平均通信時間Ｔi,kがｄk-1における平均通信時間Ｔi,k-1よりも大きいか等しいものとする（ステップＳ３１〜Ｓ３３）。この場合、スケジューラ３１１は新しいｎ（＝ｎi）の値を、現在の値ｄkよりも１段階小さいｄk-1とする（ステップＳ３６）。つまりスケジューラ３１１は、ＣＰＵ割り当て時間単位を現在よりも１段階大きくする。スケジューラ３１１はステップＳ３６を実行すると、上記ステップＳ２８の処理に戻る。
【０１０１】
さて図１４Ａ及び図１４Ｂのフローチャートでは、平均通信時間Ｔi,kが０の場合も考慮されている（ステップＳ３２及びＳ３５）。しかし、Ｔi,kが０の密連結ゲストＯＳグループは前記ステップＳ２３，Ｓ２４において相互通信ゲストＯＳテーブル３１５に登録されない。したがって本変形例では、平均通信時間Ｔi,kが０の場合は発生しない。図１４Ａ及び図１４Ｂのフローチャートでは、一般的な処理手順とするためにＴi,kが０の場合の処理も含めている。ここでは、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）でなく、且つ今回求められた（ｄkにおける）平均通信時間Ｔi,kが０であるならば（ステップＳ３１，Ｓ３２）、スケジューラ３１１は新しいｎ（＝ｎi）の値を、現在の値ｄkよりも１段階小さいｄk-1とする（ステップＳ３６）。また、密連結ゲストＯＳグループＧｉの現在のｎ（＝ｎi）の値ｄkが最小値（１）であり、且つ今回求められた平均通信時間Ｔi,kが０であるならば（ステップＳ３１，Ｓ３５）、スケジューラ３１１はｎ（＝ｎi）を操作せずにステップＳ２８の処理に戻る。
【０１０２】
スケジューラ３１１はステップＳ２８から始まる上述の処理（ｎ値決定処理）を、全ての密連結ゲストＯＳグループについて実行する。そして全ての密連結ゲストＯＳグループについてｎ値決定処理を実行し終えると（ステップＳ２８）、スケジューラ３１１は変数ＷＡＩＴ＿ＣＮＴに初期値Ａを設定する（ステップＳ３７）。
【０１０３】
次にスケジューラ３１１は、ｎ値決定処理で密連結ゲストＯＳグループＧｉ毎に決定（設定）されたｎiの値を当該グループＧｉに適用することにより、当該グループＧｉに属する各ゲストＯＳをτ／ｎiの時間単位で順に実行させる新しいスケジュールを作成する（ステップＳ３８）。スケジューラ３１１は、作成された新しいスケジュールの情報をディスパッチャ３１２に渡して、当該スケジュールに基づく再スケジューリングをディスパッチャ３１２に指示する（ステップＳ３９）。以降、図１４Ａ及び図１４Ｂのフローチャートに示される処理がＡ回呼ばれる間は、変数ＷＡＩＴ＿ＣＮＴが１ずつデクリメントされるだけである（ステップＳ２１，Ｓ２２）。このため、同じｎiで各密連結ゲストＯＳグループＧｉがスケジューリングされる。
【０１０４】
図８（ａ）の例の場合、ｎ値決定処理（ステップＳ２８乃至Ｓ３６）の結果、ゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄによって構成される密連結ゲストＯＳグループＧ１（Ｇｉ＝Ｇ１）のｎ1（ｎi＝ｎ1）の値は、ｄ0からｄ1に変更される。つまりｎ1の値は１から２に変更される。この結果、密連結ゲストＯＳグループＧ１の新たな時間割り当て単位はτからτ／２となる。これによりゲストＯＳ＃Ａ，＃Ｃ及び＃Ｄは、図８（ｂ）に示すように、新たな時間割り当て単位で再スケジューリングされる。
【０１０５】
前述したように、図９は、図８（ｂ）の状態における通信状態テーブル３１４の例を示す。この通信状態テーブル３１４に基づき、密連結ゲストＯＳグループＧ１に関する平均通信時間を計算すると、
（Σ（メッセージの通信時間））／メッセージ総数
＝（４×τ／２＋１×２τ＋１×τ＋１×τ＋１×２τ＋２×τ／２）／１０
＝０．９τ
となる。
【０１０６】
この計算結果から、平均通信時間が２τから０．９τに改善したことが分かる。次回、図１４Ａ及び図１４Ｂのフローチャートに従う処理が行われるときには、図１５に示されるように、平均通信時間テーブル３１７の密連結ゲストＯＳグループＧ１に対応するエントリのｄ１の欄に、「０．９τ」が記録される。すると、ｎiの値が更にｄ1（＝２）からｄ2（＝３）に変更されて、割り当て時間単位がより細分化される。このようにして、効果が得られる間（つまりｄkにおける新しい平均通信時間Ｔi,kが、ｄk-1における平均通信時間Ｔi,k-1よりも小さい間）はｎiの値を小さくし、効果が得られない場合にはｎiの値をｄkから直前の値ｄk-1に戻すような制御が行われる。これにより、結果的に各密連結ゲストＯＳグループに対して最適なｎiの値が定められる。
【０１０７】
前述の説明では省略されているが、前記ステップＳ２７で平均通信時間テーブル３１７から削除された密連結ゲストＯＳグループの各ゲストＯＳは、ｎの値がｄ0（＝１）に戻されてτの時間単位で再スケジューリングされる。
【０１０８】
上記実施形態及びその変形例では、ＶＭＭ３１が、ＯＳ２０上で動作する１つのアプリケーション（ＶＭアプリケーション３０）として実装される場合を想定している。しかし本発明は、ＶＭＭ（仮想計算機マネージャ）が、計算機システムの実ＨＷ上にＶＭＭ機構として実装される場合にも、同様に適用可能である。
【０１０９】
なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。
【図面の簡単な説明】
【０１１０】
【図１】本発明の一実施形態に係る仮想計算機システムを実現する計算機システムの構成を示すブロック図。
【図２】図１に示されるＶＭＭ（仮想計算機モニタ）の構成を示すブロック図。
【図３】同実施形態における仮想計算機システムのシステム状態の一例を、２つのゲストＯＳが互いに送受信しながら処理を進める場合について示す図。
【図４】図３のシステム状態における動作シーケンスを、再スケジューリングの前後で対比して示す図。
【図５】図４（ａ）の状態における通信状態テーブルの一例を示す図。
【図６】同実施形態におけるクオンタム調整処理の手順を示すフローチャート。
【図７】相互通信ゲストＯＳテーブルの一例を示す図。
【図８】３つのゲストＯＳが互いに送受信しながら処理を進める場合の動作シーケンスを、再スケジューリングの前後で対比して示す図。
【図９】図８（ａ）の状態における通信状態テーブルの一例を示す図。
【図１０】図９に示される通信状態テーブルの状態に基づいてクオンタム調整処理が行われた場合の相互通信ゲストＯＳテーブルの一例を示す図。
【図１１】図８（ｂ）の状態における通信状態テーブルの一例を示す図。
【図１２】同実施形態の変形例で適用されるＶＭＭ（仮想計算機モニタ）の構成を示すブロック図。
【図１３】ｎ値定義テーブルの一例を示す図。
【図１４Ａ】同実施形態の変形例におけるクオンタム調整処理の手順を示すフローチャート。
【図１４Ｂ】同実施形態の変形例におけるクオンタム調整処理の手順を示すフローチャート。
【図１５】平均通信時間テーブルの一例を示す図。
【符号の説明】
【０１１１】
３１…ＶＭＭ（仮想計算機モニタ）、３２Ａ〜３２Ｄ…仮想計算機実行環境、３５Ａ〜３５Ｄ…ゲストＯＳ、３１１…スケジューラ、３１２…ディスパッチャ、３１３…ゲストＯＳ間通信サービス機構、３１４…通信状態テーブル、３１５…相互通信ゲストＯＳテーブル、３１６…ｎ値定義テーブル、３１７…平均通信時間テーブル。
【特許請求の範囲】
【請求項１】
仮想計算機モニタによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行され、前記複数のゲストＯＳのうちの任意のゲストＯＳ間で前記仮想計算機モニタによって提供される通信機能を用いて相互に通信を行いながら処理が進められる仮想計算機システムに適用されるゲストＯＳスケジューリング方法であって、
前記仮想計算機モニタが提供する通信機能を用いて相互に通信するゲストＯＳの組を前記仮想計算機モニタが特定するステップと、
前記複数のゲストＯＳのうち、前記特定されたゲストＯＳの組に含まれる各ゲストＯＳの実行スケジュールにおけるクオンタムを前記仮想計算機モニタが短くするステップと
を具備することを特徴とするゲストＯＳスケジューリング方法。
【請求項２】
前記特定するステップにおいて、１スケジュール周期内に完了する通信が相互に行われるゲストＯＳの対が前記ゲストＯＳの組として特定されることを特徴とする請求項１記載のゲストＯＳスケジューリング方法。
【請求項３】
前記特定するステップにおいて、前記ゲストＯＳの対の一方との間で前記１スケジュール周期内に完了する通信が相互に行われる別のゲストＯＳが存在する場合、前記別のゲストＯＳも前記ゲストＯＳの組に属するとして扱われることを特徴とする請求項２記載のゲストＯＳスケジューリング方法。
【請求項４】
前記特定するステップ及び前記短くするステップが一定スケジューリング周期で繰り返されるように前記仮想計算機モニタが制御するステップと、
前記特定するステップが実行される都度、前記特定された前記ゲストＯＳの組毎に前記仮想計算機モニタが最新の平均通信時間を求めるステップと、
前記最新の平均通信時間と前回の平均通信時間とを前記仮想計算機モニタが比較するステップと
を更に具備し、
前記短くするステップにおいて、前記最新の平均通信時間が前記前回の平均通信時間よりも短い場合には、前記クオンタムが前回よりも短くされ、前記最新の平均通信時間が前記前回の平均通信時間よりも短くない場合には、前記クオンタムが前回よりも長くまたは前回と同一値にされる
ことを特徴とする請求項１記載のゲストＯＳスケジューリング方法。
【請求項５】
複数のゲストＯＳが時分割で実行される仮想計算機実行環境を構築する仮想計算機モニタにおいて、
前記複数のゲストＯＳのうちの任意のゲストＯＳ間の通信を当該ゲストＯＳからの要求に応じて実行するゲストＯＳ間通信手段と、
前記ゲストＯＳ間通信手段による前記ゲストＯＳ間の通信の状況を保持する通信状態テーブルと、
前記通信状態テーブルに基づいて、前記ゲストＯＳ間通信手段を用いて相互に通信するゲストＯＳの組を特定し、前記複数のゲストＯＳのうち、前記特定されたゲストＯＳの組に含まれる各ゲストＯＳの実行スケジュールにおけるクオンタムが短く設定された新たなスケジュールを作成するスケジューラと、
前記特定されたゲストＯＳの組に含まれる各ゲストＯＳを前記新たなスケジュールで実行させるディスパッチャと
を具備することを特徴とする仮想計算機モニタ。
【請求項１】
仮想計算機モニタによって提供される仮想計算機実行環境で複数のゲストＯＳが時分割で実行され、前記複数のゲストＯＳのうちの任意のゲストＯＳ間で前記仮想計算機モニタによって提供される通信機能を用いて相互に通信を行いながら処理が進められる仮想計算機システムに適用されるゲストＯＳスケジューリング方法であって、
前記仮想計算機モニタが提供する通信機能を用いて相互に通信するゲストＯＳの組を前記仮想計算機モニタが特定するステップと、
前記複数のゲストＯＳのうち、前記特定されたゲストＯＳの組に含まれる各ゲストＯＳの実行スケジュールにおけるクオンタムを前記仮想計算機モニタが短くするステップと
を具備することを特徴とするゲストＯＳスケジューリング方法。
【請求項２】
前記特定するステップにおいて、１スケジュール周期内に完了する通信が相互に行われるゲストＯＳの対が前記ゲストＯＳの組として特定されることを特徴とする請求項１記載のゲストＯＳスケジューリング方法。
【請求項３】
前記特定するステップにおいて、前記ゲストＯＳの対の一方との間で前記１スケジュール周期内に完了する通信が相互に行われる別のゲストＯＳが存在する場合、前記別のゲストＯＳも前記ゲストＯＳの組に属するとして扱われることを特徴とする請求項２記載のゲストＯＳスケジューリング方法。
【請求項４】
前記特定するステップ及び前記短くするステップが一定スケジューリング周期で繰り返されるように前記仮想計算機モニタが制御するステップと、
前記特定するステップが実行される都度、前記特定された前記ゲストＯＳの組毎に前記仮想計算機モニタが最新の平均通信時間を求めるステップと、
前記最新の平均通信時間と前回の平均通信時間とを前記仮想計算機モニタが比較するステップと
を更に具備し、
前記短くするステップにおいて、前記最新の平均通信時間が前記前回の平均通信時間よりも短い場合には、前記クオンタムが前回よりも短くされ、前記最新の平均通信時間が前記前回の平均通信時間よりも短くない場合には、前記クオンタムが前回よりも長くまたは前回と同一値にされる
ことを特徴とする請求項１記載のゲストＯＳスケジューリング方法。
【請求項５】
複数のゲストＯＳが時分割で実行される仮想計算機実行環境を構築する仮想計算機モニタにおいて、
前記複数のゲストＯＳのうちの任意のゲストＯＳ間の通信を当該ゲストＯＳからの要求に応じて実行するゲストＯＳ間通信手段と、
前記ゲストＯＳ間通信手段による前記ゲストＯＳ間の通信の状況を保持する通信状態テーブルと、
前記通信状態テーブルに基づいて、前記ゲストＯＳ間通信手段を用いて相互に通信するゲストＯＳの組を特定し、前記複数のゲストＯＳのうち、前記特定されたゲストＯＳの組に含まれる各ゲストＯＳの実行スケジュールにおけるクオンタムが短く設定された新たなスケジュールを作成するスケジューラと、
前記特定されたゲストＯＳの組に含まれる各ゲストＯＳを前記新たなスケジュールで実行させるディスパッチャと
を具備することを特徴とする仮想計算機モニタ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【公開番号】特開２００８−１６５４１０（Ｐ２００８−１６５４１０Ａ）
【公開日】平成２０年７月１７日（２００８．７．１７）
【国際特許分類】
【出願番号】特願２００６−３５２９４８（Ｐ２００６−３５２９４８）
【出願日】平成１８年１２月２７日（２００６．１２．２７）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【公開日】平成２０年７月１７日（２００８．７．１７）
【国際特許分類】
【出願日】平成１８年１２月２７日（２００６．１２．２７）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
[ Back to top ]