JP4358224B2 - ゲストosスケジューリング方法及び仮想計算機モニタ - Google Patents

ゲストosスケジューリング方法及び仮想計算機モニタ Download PDF

Info

Publication number
JP4358224B2
JP4358224B2 JP2006352948A JP2006352948A JP4358224B2 JP 4358224 B2 JP4358224 B2 JP 4358224B2 JP 2006352948 A JP2006352948 A JP 2006352948A JP 2006352948 A JP2006352948 A JP 2006352948A JP 4358224 B2 JP4358224 B2 JP 4358224B2
Authority
JP
Japan
Prior art keywords
guest os
guest
time
quantum
communication time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2006352948A
Other languages
English (en)
Other versions
JP2008165410A (ja
Inventor
聡 水野
Original Assignee
東芝ソリューション株式会社
株式会社東芝
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 東芝ソリューション株式会社, 株式会社東芝 filed Critical 東芝ソリューション株式会社
Priority to JP2006352948A priority Critical patent/JP4358224B2/ja
Publication of JP2008165410A publication Critical patent/JP2008165410A/ja
Application granted granted Critical
Publication of JP4358224B2 publication Critical patent/JP4358224B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45595Network integration; Enabling network access in virtual machine instances

Description

本発明は、仮想的な計算機実行環境を提供する仮想計算機システムに係り、特に当該仮想的な計算機実行環境で実行されるゲストOS間の通信状況に基づいてゲストOSの実行スケジュールを切り替えるゲストOSスケジューリング方法及び仮想計算機モニタに関する。

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

一般に、パーソナルコンピュータのような計算機システムは、プロセッサ(実プロセッサ)、各種の入出力(I/O)装置(実I/O装置)及びメモリ(実メモリ)を含むHW(実HW)で構成されている。この計算機システムでは、オペレーティングシステム(OS)が動作する。OS上では各種アプリケーションプログラム(アプリケーション)が実行される。そのアプリケーションの1つとしてVMアプリケーションが知られている。

VMアプリケーションの内部には、仮想計算機モニタ(Virtual Machine Monitor:VMM)が存在する。つまり、VMアプリケーションの実行によりVMMが実現される。VMMは、仮想計算機マネージャ(Virtual Machine Manager)と呼ばれることもある。VMMは、VMシステムの管理を行い、また仮想HW装置を構成する。仮想HW装置は仮想プロセッサ、仮想I/O装置及び仮想的なメモリ装置(仮想メモリ)のような仮想HW群を含む。VMMは、論理的にこれらの仮想HWをエミュレートして、仮想的な計算機実行環境(仮想計算機実行環境)、つまり仮想計算機システムの実行環境(仮想計算機システム環境)を実現する。この環境にゲストOSとして適切なOSがロードされ、当該ロードされたOS(ゲストOS)が動作する。

VMMは、仮想HWとしてのメモリ装置にゲストOSのコードを展開し、その実行コードを仮想プロセッサのエミュレートという形で実行することでゲストOSの処理を進める。ゲストOSからのI/O要求は、VMMが仮想I/O装置のエミュレートを行うことにより処理する。

このように、VMMは一般的な計算機システム内で仮想計算機実行環境(仮想計算機システム環境)を構築して、その中で複数のゲストOSを実行させることができる。ここではVMMは、上述のように、OS上で実行される1つのアプリケーションとして実装される。

この他に、VMMが計算機システムの実HW上に実装される構成も知られている。実HW上に実装されるVMMはVMM機構と呼ばれ、実質的にOSとして機能する。VMM機構は、実プロセッサ及び実I/O装置のような実HWを仮想化して各ゲストOSに機能として提供する。VMM機構の上には、仮想計算機実行環境が当該VMM機構により構築される。VMM機構は仮想プロセッサ及び仮想I/O装置のような仮想HWをエミュレートする。或いはVMM機構は、実プロセッサ、実I/O装置及び実メモリ装置のような実HW(HWリソース)を時間的及び領域的に、仮想プロセッサ、仮想I/O装置及び仮想メモリ装置のような仮想HWに割り当てる。このようにしてVMM機構は、仮想計算機実行環境を構築する。ゲストOSは仮想計算機実行環境にロードされて、仮想プロセッサにより実行される。

仮想計算機実行環境内でゲストOSが実行される環境は、ゲストOS実行環境と呼ばれる。一般に仮想計算機システムでは、複数のゲストOSが実行される。そこで、複数のゲストOSの各々が実行される実行環境においては、ゲストOS間で通信を行うための通信手段があると便利である。そのためVMMは、このような通信手段を提供する。

この通信手段の代表的な機能は、
(1)ゲストOS間割り込み機能
(2)ゲストOS間共有メモリ機能
(3)ゲストOS間メッセージ送受信機能
である。

ゲストOS間割り込み機能とは、ゲストOSから指定した他のゲストOSに割り込みを送る機能である。受信側には、この割り込みが、いずれのゲストOSから送られたものかを知る手段を、例えば割り込み要因情報により提供される。

ゲストOS間共有メモリ機能とは、特定のゲストOS間で、メモリ空間を共有する仕組みである。送信側となるゲストOSがデータを書き込んだ後、受信側となるゲストOSがそのデータを読み取ることでデータの授受が可能である。データの授受の同期化には、上記ゲストOS間割り込みの仕組みを使えば良い。

ゲストOS間メッセージ送受信機能とは、送信側のゲストOSが送信されるべきデータ(送信データ)と送信先(受信側)のゲストOSとを指定してVMMに依頼すると、指定されたデータを当該VMMが送信先のゲストOSの受信バッファにコピーして、その後に受信割り込みを当該送信先のゲストOSに設定する機能である。

ゲストOS間割り込み機能及びゲストOS間共有メモリ機能を併用するか、或いはゲストOS間メッセージ送受信機能を単独で使用することにより、基本的なゲストOS間通信が実現できる。
特開2006−039763号公報

従来の仮想計算機システムにおいて、上述の通信機能をプリミティブな仕組みに使うことにより、VMMが提供する仮想計算機実行環境内で実行されるゲストOS間で、例えばTCP(Transmission Control Protocol)/IP(Internet Protocol)のような通信プロトコルをゲストOS間で実現することができる。そこで、複数のゲストOSが、上記の仕組みで互いに通信を行い協調しながらサービスを提供することが考えられる。例えば、外部の通信路(外部ネットワーク)に直接つながるゲストOSがファイヤーウォール(FW)となり、他のゲストOSが仮想ネットワーク経由でそのゲストOSに接続されるような利用形態が考えられる。

ところが、ゲストOS間で通信をしながら処理を進めるような利用形態の場合に、通信の処理効率が良くならない場合がある。これについて、例を挙げて説明する。

まず、VMMが構築する仮想計算機実行環境で4つのゲストOS#A,#B,#C及び#Dが稼動しており、これらのゲストOSのうちのゲストOS#A及び#Cが互いに通信しながら処理を進めるものとする。更に具体的に述べるならば、ゲストOS#A中の「プロセス#a」とゲストOS#C中の「プロセス#c」とが互いに送受信しながら処理を進めているものとする。

VMMは、前述のゲストOS間の通信のための3つの機能、つまりゲストOS間割り込み機能、ゲストOS間共有メモリ機能及びゲストOS間メッセージ送受信機能をサポートしている。ゲストOS#A及び#Cは、これらの機能を使って通信している。

例えば、プロセス#a及び#cがTPC/IPのインターフェイスでそれぞれのゲストOSに送受信要求を行うものとする。この場合、各ゲストOSは、その送受信要求を受け取って処理し、VMMが提供するゲストOS間通信手段で相手にメッセージ送信を行う。VMMの提供する代表的なゲストOS間通信手段は、例えば「ゲストOS間メッセージ送受信機能」である。

ゲストOS#A及び#Cの間で、次の4つの処理が繰り返されるものとする。
(1)ゲストOS#A(プロセス#a)は3つのメッセージ(ネットワークパケット)をゲストOS#Cに送る(処理a1)。
(2)ゲストOS#C(プロセス#c)はゲストOS#Aから送られた3つのメッセージを受信して処理する(処理c1)。
(3)ゲストOS#C(プロセス#c)は受信メッセージの処理の結果、新たなメッセージ1つを生成して、そのメッセージをゲストOS#Aに送る(処理c2)。
(4)ゲストOS#A(プロセス#a)はゲストOS#Cから送られたメッセージを受信して処理する(処理a2)。

この4つの処理が繰り返される場合の動作シーケンスを図4(a)に示す。この図では、処理a1及びa2を合わせた処理が処理aと表現され、処理c1及び処理c2を合わせた処理が処理cと表現されている。図4(a)において、横軸は時間の経過を示す。

「τ」はVMMが各ゲストOSにプロセッサ(CPU)を割り当てる時間の単位を示し、一般にクオンタム(タイムクオンタム)と呼ばれる。説明を簡単にするために、図4(a)の例では、クオンタムτの途中でゲストOSの切り替えが発生しないものとする。つまり図4(a)の例では、時刻tn+1,tn+2,tn+3及びtn+4からそれぞれ始まるクオンタムτでは、ゲストOS#A,#B,#C及び#Dにプロセッサが割り当てられる。同様に、時刻tn+5,tn+6,tn+7及びtn+8からそれぞれ始まるクオンタムτでも、ゲストOS#A,#B,#C及び#Dにプロセッサが割り当てられる。但し、実際の例では、割り込み発生のようなイベントにより、クオンタム途中でのゲストOS切り替えも発生する。

図4(a)において、下向きの矢印は送信メッセージを示し、上向きの矢印は受信メッセージを示す。また、矢印の数はメッセージ数を示す。更に、上向きの矢印(受信メッセージ)の下に付されているτを含む符号は、対応するメッセージがそのτを含む符号で示される時間で送られことを示す。また、τを含む符号の下に記載された括弧内の英記号は、対応するメッセージがその英記号で示されるゲストOSから送られたことを示す。

図4(a)の例では、上述のように時刻tn+1でゲストOS#Aにプロセッサがディスパッチされて当該ゲストOS#Aが動き出す。そして、ゲストOS#Aのプロセス#aが動き出して、処理a1を行う。これにより、3つのメッセージがゲストOS#Cに送られる。するとプロセス#aは、その時刻tx以降、少なくともゲストOS#Cからメッセージが返されるまでは、処理(処理a2)ができなくなる。また、ゲストOS#Cからメッセージが返されても、ゲストOS#Aが動作可能でない場合には、当該ゲストOS#Aが動作可能となるまでプロセス#aは処理(処理a2)ができなくなる。但し、処理a1と処理a2の処理時間の和がクオンタムτに対して小さいとすると、クオンタムτの残りの時間内で、ゲストOS#Aのプロセス#a以外の処理を行うことは可能である。

VMMは、ゲストOS#Aのプロセス#aによって送信されたメッセージをゲストOS#Cに送る。しかし、この時点ではゲストOS#Cは未だ動いていない。図4(a)の例において、ゲストOS#Cが動くことができるのは時刻tn+3からである。このため、処理a1でゲストOS#Cに送られたメッセージは、当該ゲストOS#Cで直ちには受信されず、時刻tn+3になりようやく受信される。

ゲストOS#Cのプロセス#cは、処理c1及びc2に要する時間がτに対して小さいとするならば、当該処理c1及びc2を行い、メッセージを1つゲストOS#Aに送る。その後(時刻ty以降)、ゲストOS#Cのプロセス#cの処理は継続できず、当該ゲストOS#C内の他のプロセスが処理される。

ゲストOS#Aは、時刻tn+1から4τ後の時刻tn+5に再び動作可能となり、先にゲストOS#Cから送られたメッセージを受信して処理する(処理a2)。

このようにして、一連の処理a1,c1,c2及びa2は4τの時間(周期)をかけて実行される。図4(a)からも明らかなように、このような状況はプロセス#a及び#cにとって非常に効率が悪い。

そこで、保留(ペンディング)しているゲストOSに割り込みに応じてプロセッサを優先的にディスパッチすることが考えられる。先に述べたように、ゲストOS間通信は送信先への割り込みとして実現される。したがって、このディスパッチ手法を適用することにより、通信メッセージが送られるタイミングで送信先のゲストOSにプロセッサがディスパッチされる。

ところが、上述のディスクパッチ手法では、メッセージ送信のたびにゲストOSが切り替わることになる。すると、今度はゲストOS切り替えのオーバヘッドが目立って大きなコストになりかねない。更に、上述の例のように複数のメッセージが送られないとプロセス#cが次の処理を行えないような場合、次に述べるようにシステム性能の低下を招く可能性がある。

まず、プロセス#aの1つ目のメッセージ送信で制御を渡されただけでは、プロセス#cは、残りの2つのメッセージがないので処理c1を終えることができない。つまり、プロセス#cは、再度ゲストOS#Aがスケジューリングされて、当該ゲストOS#Aから残りの全ての(2つの)メッセージが送られるのを待つ必要がある。このため、状況によっては、割り込みに伴うゲストOSの切り替えの結果、システム性能の低下を招く可能性がある。

更に他の手法として、クオンタムτをより小さい値に設定することが考えられる。τの値が小さいほど、各ゲストOSが実行される機会を増やすことができる。この場合、メッセージを送られた後、より短い時間でメッセージ送信先のゲストOSが動作可能となるため、メッセージ受信処理が早期に行われる。しかし、τを小さくすると「ゲストOS切り替えコスト」が増加し、システム全体の効率が低下する。

一般にτは、対象となるシステムにおいて「システムのレスポンス時間が良好(τの値を小さくする方向)」で、且つ「ゲストOSの切り替えコストが目立たない(悪影響を及ぼさない)(τの値を大きくする方向)」ような最適な値に設定される。このため、本来最適な値に設定されているτの値を小さくすると、システム全体の効率が悪くなる虞がある。

本発明は上記事情を考慮してなされたものでその目的は、ゲストOS間で通信をしながら処理を進める場合における通信処理効率の向上が図れるゲストOSスケジューリングを実現するゲストOSスケジューリング方法及び仮想計算機モニタを提供することにある。

本発明の1つの観点によれば、仮想計算機モニタによって提供される仮想計算機実行環境で複数のゲストOSが時分割で実行され、前記複数のゲストOSのうちの任意のゲストOS間で前記仮想計算機モニタによって提供される通信機能を用いて相互に通信を行いながら処理が進められる仮想計算機システムに適用されるゲストOSスケジューリング方法が提供される。このゲストOSスケジューリング方法は、前記仮想計算機モニタが提供する通信機能を用いて相互に通信するゲストOSの組を前記仮想計算機モニタが特定するステップと、前記複数のゲストOSのうち、前記特定されたゲストOSの組に含まれる各ゲストOSの実行スケジュールにおけるクオンタムを前記仮想計算機モニタが短くするステップとを具備する。

本発明によれば、ゲストOS間で相互に通信を行いながら連携して処理を行うような場合に、そのゲストOSの実行スケジュールにおけるクオンタムだけを短くすることにより、このような通信で従来は発生する通信遅延による性能劣化を、他のゲストOSに何ら影響を及ぼすことなく改善することが可能となる。

以下、本発明の実施の形態につき図面を参照して説明する。
図1は本発明の一実施形態に係る仮想計算機システム(VMシステム)を実現する計算機システム1の構成を示すブロック図である。計算機システム1は、実計算機を構成するハードウェア(HW)10を備えている。HW10は、周知のように、実プロセッサ11、I/O装置(入出力装置)12及びメモリ(図示せず)を含む。HW10上では、ホストOSと呼ばれるOS20が動作する。OS(ホストOS)20上では仮想計算機アプリケーション(VMアプリケーション)30を含む各種のアプリケーションが実行される。

VMアプリケーション30の内部には、仮想計算機モニタ(Virtual Machine Monitor:VMM)31が存在する。つまり、VMアプリケーション30の実行によりVMM31が実現される。VMM31は、VMシステムの管理を行い、仮想計算機システム(VMシステム)の環境(仮想計算機実行環境)を構築する。図1では、4つの仮想計算機実行環境32A,32B,32C及び32Dが構築されている例が示されている。

仮想計算機実行環境32i(i=A,B,C,D)は、仮想HW環境(仮想HW装置)33i及びゲストOS実行環境34iからなる。仮想HW環境33iは、仮想プロセッサ(VP)331i、仮想I/O装置332i及び仮想的なメモリ装置(図示せず)のような仮想HW群を含む。VMM31は、論理的にこれらの仮想HWをエミュレートして、上述の仮想計算機実行環境32iを実現する。VMM31は、この仮想計算機実行環境32i内のゲストOS実行環境34iに、当該ゲストOS実行環境34iで動作するOSをゲストOS35i(#i)としてロードする。ゲストOS実行環境34iにロードされたゲストOS35i(#i)は、当該ゲストOS実行環境34i内で実行される。

VMM31は、仮想HW環境33iに含まれる仮想的なメモリ装置(仮想メモリ装置)にゲストOS35i(#i)のコードを展開し、その実行コードを仮想プロセッサ331iのエミュレートという形で実行する。これによりVMM31は、ゲストOS35iの処理を進める。ゲストOS35iからのI/O要求は、VMM31が仮想I/O装置332iのエミュレートを行うことにより処理する。

図2は、図1に示されるVMM31の構成を示すブロック図である。VMM31は、スケジューラ311、ディスパッチャ312、ゲストOS間通信サービス機構313、通信状態テーブル314及び相互通信ゲストOSテーブル315を含む。

スケジューラ311は、各ゲストOS35i(#i)のスケジュールを決定する。スケジューラ311が適用するスケジューリングポリシとして種々考えられるが、ここでは単純なラウンドロビン方式によるスケジューリングが適用されるものとする。即ちスケジューラ311は、基本的には、タイムクオンタム(τ)と呼ばれる時間単位毎に、各ゲストOS35i(#i)を順番に実行するように、ディスパッチャ312に指示する。但し本実施形態では、スケジューラ311は、タイムクオンタムの値を状況により変える指示もディスパッチャ312に送る。

ディスパッチャ312は、スケジューラ311の指示に従って実際にゲストOS35i(#i)にプロセッサ(実プロセッサ11)をディスパッチする。ディスパッチャ312はまた、スケジューラ311によって指示されたタイムクオンタムの時間が経過したならば、ゲストOS35i(#i)からプロセッサ(実プロセッサ11)を取り上げて、次のゲストOSに当該プロセッサを割り当てる。ディスパッチャ312は、これらの処理を繰り返す。

ゲストOS間通信サービス機構313は、各OS35i(#i)からVMM31に要求される、ゲストOS間通信要求を処理するゲストOS間通信手段として機能する。ゲストOS間通信は、VMM31に対するHypervisor呼び出し(システムコール)の形で発行される。この呼び出しでは、送り先のゲストOS及びメッセージデータが指定される。ゲストOS間通信サービス機構313は、指定されたゲストOSに対して指定されたメッセージを届けると共に、受信割り込みを設定する。この受信割り込みは、その後、送信先のゲストOSにプロセッサがディスパッチされた時点で当該送信先のゲストOSに入る。このとき、送信先のゲストOSは、ゲストOS間通信サービス機構313によって送られたメッセージデータを受信データとして参照することができる。

通信状態テーブル314は、ゲストOS間通信サービス機構313が処理したメッセージ送信に関する情報を保持するのに用いられる。更に詳細に述べるならば、通信状態テーブル314は、ゲストOS35iを送信元、ゲストOS35j(j≠i)を送信先とする、メッセージ送信に関する情報を保持するのに用いられる。なお、以下の説明では、ゲストOS35A,35B,35C,35D,35i及び35jを、それぞれゲストOS#A,#B,#C,#D,#i及び#jのように表現する。

相互通信ゲストOSテーブル315は、後述する1スケジュール周期内に受信されるメッセージを互いに送信しているゲストOSの対を相互通信ゲストOS対として保持するのに用いられる。

図3は図1に示す計算機システム1によって実現されるVMシステム(仮想計算機システム)のシステム状態の一例を示す。ここでは、VMM31が構築する仮想計算機実行環境32A,32B,32C及び32D(図1参照)で、それぞれゲストOS#A,#B,#C及び#Dが稼動している。図3に示すシステム状態では、ゲストOS#A中の「プロセス#a」とゲストOS#C中の「プロセス#c」とが互いに送受信しながら処理を進めている。更に具体的に述べるならば、ゲストOS#A中の「プロセス#a」とゲストOS#C中の「プロセス#c」の間で、[発明が解決しようとする課題]の欄に記載されたような4つの処理(a1,c1,c2及びa2)が繰り返し実行されている。

図4は、この4つの処理が繰り返される場合の動作シーケンスを、再スケジューリングの前後で対比して示す。図4において、同図(a)は再スケジューリング前の動作を示す動作シーケンス、同図(b)は再スケジューリング後の動作を示す動作シーケンスである。図4において、下向きの矢印は送信メッセージを示し、上向きの矢印は受信メッセージを示す。また、矢印の数はメッセージ数を示す。更に、上向きの矢印(受信メッセージ)の下に付されているτを含む符号は、対応するメッセージがそのτを含む符号で示される時間(例えば2τであれば2τの時間)で送られことを示す。また、τを含む符号の下に記載された括弧内の英記号は、対応するメッセージがその英記号で示されるゲストOS(例えば(A)であればゲストOS#A)から送られたことを示す。

図5は、図2に示される通信状態テーブル314の一例を、スケジュール対象となるゲストOSがゲストOS#A,#B,#C,#Dである場合について示す。通信状態テーブル314は、ゲストOS#i(i=A,B,C,D)を送信元、ゲストOS#j(j=A,B,C,D、但しj≠i)を送信先とする全ての組み合わせについて、メッセージ送信に関する情報(以下、通信状態情報と称する)を保持するエントリ#ijを有している。

通信状態情報は、1スケジュール周期中に発行されたメッセージ数及びメッセージ受信までに要した平均時間の値を含む。図5の例では、平均時間は括弧内に記述されている。

「1スケジュール周期」は、
τ×(そのときの)スケジュール対象のゲストOS数
で表されるものとする。つまり1スケジュール周期は、本実施形態のように単純なラウンドロビンがクオンタムτで行われている場合には、各ゲストOSにプロセッサがディスパッチされた時点から次のディスパッチ時点までの時間となる。図4では、例えばtn+1〜tn+5が1スケジュール周期であり、4τである。

ゲストOS#iを送信元、ゲストOS#jを送信先とする通信状態情報は、ゲストOS間通信サービス機構313によって作成される。通信状態テーブル314のエントリ#ijの情報は、この作成された通信状態情報に更新される。スケジューラ311は、通信状態テーブル314内の更新された通信状態情報(各通信状態情報)を、各スケジュール周期の完了時点で参照することが可能となる。

図5の通信状態テーブル314は、図4(a)の動作シーケンスで示されるメッセージ送信の状況(通信状態)を表している。例えば、送信元ゲストOS#A及び送信先ゲストOS#Cに対応する、通信状態テーブル314のエントリには、ゲストOS#A及び#C間の最近の1スケジュール周期あたりのメッセージ送信に関する通信状態情報として、「3(2τ)」が保持されている。値「3」は、「1スケジュール周期時間よりも短い時間以内に受信されたメッセージの個数」を表し、括弧内の値「2τ」は、ゲストOS#A及び#C間でメッセージを送信する際に要した平均時間を表す。

本実施形態では、スケジューラ311は、スケジュール周期毎にクオンタムを調整する処理(クオンタム調整処理)を次のように行う。まずスケジューラ311は、通信状態テーブル314を参照して、各ゲストOS間での通信発生状況から、密に相互通信を行っている「ゲストOSの対」を探す。スケジューラ311は、目的とするゲストOSの対が見つかったなら、それらのゲストOSに対するプロセッサ割り当て粒度を小さくすることにより、メッセージ送信の遅延の改善を行う。スケジューラ311は以上の処理(クオンタム調整処理)をスケジュール周期毎に実行する。なお、クオンタム調整処理が複数スケジュール周期毎に実行されても構わない。

以下、スケジューラ311によるクオンタム調整処理の手順について、図6のフローチャートを参照して説明する。まずスケジューラ311は、密に相互に通信しているゲストOS(相互通信ゲストOS)の対を全て検出する(ステップS11)。具体的に述べるならば、スケジューラ311は、図5に示される通信状態テーブル314を参照することにより、1スケジュール周期内に受信されるようなメッセージを互いに送信しているゲストOS#i,#jの対を全て探し求める。ここで探し求められるゲストOS#i,#jの対とは、1スケジュール周期内にゲストOS#jで受信されるようなメッセージの送信を行うゲストOS#iと、当該ゲストOS#iで当該1スケジュール周期と同一周期で受信されるようなメッセージの送信を行うゲストOS#jとの対(ゲストOS#i,#jの対)である。

本実施形態では、上記ステップS11において、通信状態テーブル314によって示されるゲストOSの組み合わせ毎のメッセージ数が参照されて、メッセージ数が0でない(非0である)ゲストOSの組み合わせ(ゲストOS対)が、目的のゲストOSの組み合わせ(相互通信ゲストOS対)として検索される。そして検索された全てのゲストOS対のリスト(リスト“L”)が作成される。図5の通信状態テーブル314の例では、ゲストOS#A及び#Cの対のみを要素として含むリスト“L”が作成される。

スケジューラ311は、作成されたリスト“L”と相互通信ゲストOSテーブル315とを比較して、当該テーブル315に未登録のゲストOS対(を示す情報)がリスト“L”に含まれているならば、そのゲストOS対(を示す情報)を当該テーブル315に追加登録する(ステップS12)。

またスケジューラ311は、リスト“L”に存在しないが相互通信ゲストOSテーブル315に既に登録されているゲストOS対が存在するならば、つまりリスト“L”に存在しないゲストOS対のエントリが相互通信ゲストOSテーブル315にあるならば、そのエントリ(の情報)を当該相互通信ゲストOSテーブル315から削除する(ステップS13)。このステップS13の処理で削除されるゲストOSの対は、以前に相互に通信し合っていたが、最近になって通信しなくなったゲストOSの対である。

図7はステップS12及びS13が実行された後の相互通信ゲストOSテーブル315の一例を示す。図7の例では、相互通信ゲストOSテーブル315の先頭エントリに、相互通信ゲストOSの対(相互通信ゲストOS#i及び#jの対)として、ゲストOS#A及び#Cの対が登録されている。

次にスケジューラ311は、相互通信ゲストOSテーブル315を参照して「密連結ゲストOSグループ」を作成する(ステップS14)。「密連結ゲストOSグループ」とは、相互通信ゲストOSテーブル315に登録されているゲストOSの対の集合(つまりゲストOSの組)であって、あるゲストOSと対をなすゲストOS以外に、当該あるゲストOSとの間で相互通信をしている別のゲストOSが存在する場合には、当該別のゲストOSを含めたゲストOSの集合(ゲストOSの組)である。そこで、相互通信ゲストOSテーブル315の各エントリは、ゲストOSの対を登録するための欄に加えて、この欄に登録されたゲストOSが属するグループのID(グループID)を登録するための欄を含む。

図7の相互通信ゲストOSテーブル315の例では、ゲストOS#A及び#Cのみが密連結ゲストOSグループを形成する。しかし、通信状態テーブル314が例えば図9のような場合には、ゲストOS#A,#C及び#Dが密連結ゲストOSグループを形成する。つまり密連結ゲストOSグループとは、相互に頻繁にメッセージを授受しているゲストOSの集合である。

上記ステップS14においてスケジューラ311は、作成された密連結ゲストOSグループ毎にユニークなID(例えば番号)をグループIDとして付与し、当該IDを相互通信ゲストOSテーブルのグループID欄に記入する。

スケジューラ311はステップS14を実行するとステップS15の処理に進む。ステップS15においてスケジューラ311は、各密連結ゲストOSグループに関して、当該グループに属するゲストOSが元々クオンタムτの単位でスケジューリングされていた時間帯を、当該グループに属するゲストOSの再スケジューリングのためにτ/nの長さに分割する。このnを分割定数と呼ぶ。本実施形態において分割定数nの値は、予め定められた一定値であり、2であるものとする。但し、このnの値は、後述するように動的に変更された方が良い。スケジューラ311は、ステップS15において更に、再スケジューリングの対象となる各ゲストOSをτ/nの時間単位で順に実行させる新しいスケジュール(を表すスケジュール表)を作成(決定)する。

次にスケジューラ311は、作成された新しいスケジュール(スケジュール表)の情報をディスパッチャ312に渡して、当該スケジュールに基づく再スケジューリングをディスパッチャ312に指示する(ステップS16)。これによりディスパッチャ312は、スケジューラ311から渡された新しいスケジュールに従って、実際にゲストOS(ゲストOS#A及び#C)にプロセッサをディスパッチする再スケジューリングを行う。

「クオンタム調整処理」の結果、上述したように、ゲストOS#A及び#Cが相互にメッセージを授受している本実施形態では、これらのゲストOS#A及び#Cが、同一の「密連結ゲストOSグループ」に属すこととなる。その結果、ゲストOS#A及び#Cに関して、τ/2の時間単位でのプロセッサ割り当てが再スケジューリングされ、その結果、図4(b)のような実行状態となる。ここで、密連結ゲストOSグループに属さないゲストOS#B及び#Dは、依然としてτの時間単位で1スケジュール周期(=4τ)毎にプロセッサ割り当てがスケジューリングされる。つまり本実施形態では、密連結ゲストOSグループに属するゲストOSを対象とする再スケジューリングが、他のゲストOSのスケジューリングに影響を及ぼすことはない。

図4(b)の例では、ゲストOS#AからゲストOS#Cへのメッセージ送信の平均時間、及びゲストOS#CからゲストOS#Aへのメッセージ送信の平均時間は、それぞれ、ほぼ0.5τ及び1.5τとなる。この場合、一連の前述の4つの処理(a1,c1,c2及びa2)の周期(平均処理周期)は、図4(a)に示される4τから図4(b)に示される2τに改善される。

このように本実施形態においては、ゲストOS間で相互に通信を行いながら連携して処理を行う場合に、そのゲストOSの実行スケジュールにおけるクオンタムだけを短くすることにより、このような通信で従来は発生する通信遅延による性能劣化を、他のゲストOSに何ら影響を及ぼすことなく改善することができる。特に、仮想計算機システムのゲストOS間通信は、メモリベースで実装されることが多く、それ自体オーバヘッドが小さいものであ。このため仮想計算機システムのゲストOS間通信は、実ネットワークでの通信に比べて非常に遅延時間(レイテンシ)が小さいものとして使用できる可能性がある。よって本実施形態においては、仮想計算機システムの高速なゲストOS間通信機構の性能を十分引き出すことができ、従来に比べてシステム全体で性能が高い仮想計算機システムを実現できる。

図4の例では、ゲストOS#A及び#Cによってそれぞれ実行される処理#a及び#c以外の処理は考慮されていない。このため、実際には、常に図4(b)のような結果になる保証はない。しかしながら、図4(a)の状況では、ゲストOS#A及び#Cがどのような負荷状況にあったとしても、当該図4(a)に示される以上のスループットは得られない。本実施形態では、図4(b)に示されるように、負荷状態によっては効率良く処理されるように改善される。

次に、本実施形態における再スケジューリングによる処理効率の他の改善例を、ゲストOS#A(中のプロセス#a)、ゲストOS#C(中のプロセス#c)及びゲストOS#D(中のプロセス#d)が互いに送受信しながら処理を進める場合について、再スケジューリング前と対比して図8に示す。図8において、同図(a)は再スケジューリング前の動作を示す動作シーケンス、同図(b)は再スケジューリング後の動作を示す動作シーケンスである。この例でも、nが2であるものとする。

図8の例では、1スケジュール周期毎に、以下に挙げる6つの処理が行われる。
(1)ゲストOS#A(プロセス#a)は3つのメッセージ(ネットワークパケット)の2つをゲストOS#Cに、1つをゲストOS#Dに、それぞれ送る(処理a′1)
(2)ゲストOS#C(プロセス#c)はゲストOS#Aから送られた2つのメッセージを受信して処理する(処理c′1)。
(3)ゲストOS#C(プロセス#c)は受信メッセージの処理の結果、新たなメッセージ1つを生成して、そのメッセージをゲストOS#に送る(処理c′2)。
(4)ゲストOS#D(プロセス#d)はゲストOS#から送られた1つのメッセージを受信して処理する(処理d′1)。
(5)ゲストOS#D(プロセス#d)は受信メッセージの処理の結果、新たなメッセージ1つを生成して、そのメッセージをゲストOS#Aに送る(処理d′2)。
(6)ゲストOS#A(プロセス#a)はゲストOS#C及び#Dから送られたメッセージを受信して処理する(処理a′2)。

(5)ゲストOS#D(プロセス#d)は受信メッセージの処理の結果、新たなメッセージ1つを生成して、そのメッセージをゲストOS#Aに送る(処理d′2)。
(6)ゲストOS#A(プロセス#a)はゲストOS#C及び#Dから送られたメッセージを受信して処理する(処理a′2)。

ここで、処理(送信処理)a′1及びc′2、並びに処理(送信処理)a′1及びd′2は、それぞれa′1→c′2、a′1→d′2のように、順番に処理される必要がある。

図8(a)の状態における通信状態テーブル314の例を図9に示す。また、図9に示される通信状態テーブル314の状態に基づいて「クオンタム調整処理」が行われた結果としての相互通信ゲストOSテーブル315の一例を図10に示す。図8(b)は、図10に示される相互通信ゲストOSテーブル315に基づいて作成される新しいスケジュールに従って、ゲストOS#A,#C及び#Dにプロセッサがディスパッチされた場合(つまり再スケジューリング後)の動作シーケンスを示す。

図10に示される相互通信ゲストOSテーブル315の例では、「密連結ゲストOSグループ」がゲストOS#A,#C及び#Dから構成されている。この場合、ゲストOS#A,#C及び#Dに関して、τ/2の時間単位でのプロセッサ割り当てが再スケジューリングされる。この再スケジューリングにより、これら3つのゲストOS#A,#C及び#Dに対する時間割り当て粒度が小さくなる。これにより、前述の6つの処理(a′1,c′1,c′2,d′1,d′2,a′2)の動作シーケンスは、図8(a)に示される状態から図8(b)に示される状態に改善される。ここで、密連結ゲストOSグループに属さないゲストOS#Bは、依然としてτの時間単位で1スケジュール周期(=4τ)毎にプロセッサ割り当てがスケジューリングされる。

図8(a)における平均処理周期は4τ、図8(b)における平均処理周期は2τである。これにより、図8(b)における平均処理周期は、図8(a)の4τから2τ改善されたことがわかる。図8(b)の状態における通信状態テーブル314の例を図11に示す。

[変形例]
上記実施形態では、nの値が予め定められた一定値(n=2)である場合を想定している。このnは、ゲストOSの割り当て時間単位を決める値(パラメータ値)である。上記実施形態では、τ×(1/n)、つまりτ/nの時間単位で、プロセッサが割り当てられる。しかし、メッセージ通信に要する時間は、この割り当て時間τ/nにより影響を受ける。このため、nの値を適切に設定する必要がある。

そこで、nの値を適切に決める処理(n値決定処理)を含むクオンタム調整処理がスケジューラ311によって実行される、上記実施形態の変形例について説明する。

図12は本変形例で適用されるVMM31の構成を示すブロック図である。図12において、図2と同様の要素には便宜的に同一参照符号を付してある。図12に示すVMM31が、図2に示すVMM31と相違するのは、n値定義テーブル316及び平均通信時間テーブル317を含む点である。テーブル316及び317については後述する。

次に、n値決定処理を含むクオンタム調整処理の概要について説明する。
(a)スケジューラ311は、密連結OSグループ毎に別々のnの値を使い、必要に応じてτの値を変える。密連結OSグループGiのnの値をniで表すと、スケジューラ311は、密連結OSグループGiに属する各ゲストOSに対するプロセッサ割り当て時間が、再スケジューリング前の割り当て時間の1/niになるように再スケジューリングする。

(b)nの値は、取り得る値が予め決められているものとする。本変形例では、nの値は、d0,d1,d2及びd3の4種類の値のいずれかとなる。d0〜d3の具体的な値は、n値定義テーブル316によって定義される。

図13は、n値定義テーブル316の例を示す。図13の例では、d0〜d3はnの値(n値)1〜4に対応する。このn値定義テーブル316の内容を変えるならば、つまりd0〜d3の定義を変えるならば、種々のnの値を定義することができる。

本変形例では、d0〜d3で示される値は、このd0〜d3の順に大きくなる(つまり、クオンタムがより細かく分割される)ように定められているものとする。また、d0(つまりnの値の最小値)は1であるものとする。更に、本変形例において定義される最大のnの値をdmaxと表記するものとする。つまり本変形例では、dmax=d3である。

(c)本変形例で適用されるn値決定処理を含むクオンタム調整処理では、diで定義されるniの値が決定されてから、当該クオンタム調整処理がA回呼び出される間は実質的な決定処理は何も行われない。つまり本変形例においては、一度n値決定処理でniの値が決まってからクオンタム調整処理がA回呼び出される間は、niの値が変更されないようにしている。これにより、頻繁にniの値が変わることによる処理増加によるオーバヘッドの増加を防ぐことが可能となる。

本変形例においても、上記実施形態と同様に、スケジューラ311が、スケジュール周期毎にクオンタム調整処理を行う。つまりスケジューラ311は、通信状態テーブル314を参照して、各ゲストOS間での通信発生状況から、密に相互通信を行っている(つまり1スケジュール周期内に受信されるようなメッセージを互いに送信している)ゲストOSの対を探す。そのようなゲストOSの対が見つかったなら、スケジューラ311は、それらゲストOSに対するプロセッサ割り当て粒度を小さくすることにより、メッセージ送信の遅延の改善を行う。但し、本変形例においてスケジューラ311は、密連結OSグループ毎にnの値を動的に変えることにより、当該グループ毎にプロセッサ割り当て粒度を調整する。なお、クオンタム調整処理が複数スケジュール周期毎に実行されても構わない。

次に、n値決定処理を含むクオンタム調整処理の手順について、図14A及び図14Bのフローチャートを参照して説明する。まずスケジューラ311は、クオンタム調整処理を繰り返し実行する前に、変数WAIT_CNTを予め0に初期化する。この変数WAIT_CNTは、クオンタム調整処理が行われるタイミングを調整するのに用いられる。

スケジューラ311はクオンタム調整処理が呼び出されると、変数WAIT_CNTを参照して当該変数が0であるかを判定する(ステップS21)。変数WAIT_CNTが0でない場合、スケジューラ311は当該変数WAIT_CNTを1デクリメントして(ステップS22)、そのままクオンタム調整処理を終了する。

一方、変数WAIT_CNTが0の場合には、スケジューラ311は密連結OSグループ毎にプロセッサ割り当て粒度の調整処理を次のように行う。まずスケジューラ311は、上記実施形態におけるステップS11乃至S14に相当するステップS23乃至26を実行する。即ちスケジューラ311は、相互通信ゲストOS対の検出及び相互通信ゲストOS対のリスト“L”の作成(ステップS23)、相互通信ゲストOSテーブルに存在しない新規検出相互通信ゲストOS対の相互通信ゲストOSテーブル315への登録(ステップS24)、リスト“L”に存在しないゲストOS対のエントリの相互通信ゲストOSテーブル315からの削除(ステップS25)、並びに密連結ゲストOSグループの作成(ステップS26)を行う。

スケジューラ311は、ステップS23乃至S26を実行するとステップS27の処理に進む。ステップS27においてスケジューラ311は、平均通信時間テーブル317に、今回新規に検出された密連結ゲストOSグループのためのエントリ(の情報)を追加する。また、ステップS27においてスケジューラ311は、前回までに検出されて平均通信時間テーブル317に登録されていた密連結ゲストOSグループのためのエントリであって、今回検出されなかった密連結ゲストOSグループのためのエントリ(の情報)を、当該平均通信時間テーブル317から削除する。

図15は平均通信時間テーブル317の一例を示す。平均通信時間テーブル317は、密連結ゲストOSグループ毎のエントリを有する。平均通信時間テーブル317のエントリは、対応する密連結ゲストOSグループのd0〜d3で定義されるnの値毎の平均通信時間の測定値を登録するのに用いられる。この平均通信時間については後述する。

上記ステップS27で、平均通信時間テーブル317に、新規に検出された密連結ゲストOSグループのためのエントリが追加された時点では、当該エントリの情報は初期化されている。ここでは、追加されたエントリで示されるd0〜d3で定義されるnの値毎の平均通信時間の情報が、「未定義(有効な値なし)」の状態(記号−で示される状態)に設定される。

スケジューラ311は、ステップS27を実行すると、n値決定処理(ステップS28乃至S36)を次のように実行する。まずスケジューラ311は、相互通信ゲストOSテーブル315に登録されている全ての密連結ゲストOSグループについてn値決定処理を実行したかを判定する(ステップS28)。もし、n値決定処理が未実行(未処理)の密連結ゲストOSグループが存在するならば、スケジューラ311は相互通信ゲストOSテーブル315から未処理の密連結ゲストOSグループを1つ密連結ゲストOSグループGiとして選択する(ステップS29)。

スケジューラ311は、選択された密連結ゲストOSグループGiに対応する平均通信時間テーブル317のエントリの情報、つまり密連結ゲストOSグループGiの平均通信時間を更新する(ステップS30)。平均通信時間とは、dk(k=0〜3)で定義されるnの値が適用されている状態で、密連結ゲストOSグループGiに属するゲストOSが送信したメッセージのうち、1スケジュール周期内に送信先のゲストOSで受信されたメッセージに関して、それらメッセージが送信されてから受信されるまでに要した時間の平均である。ここで送信時より1スケジュール周期を越えて受信されたメッセージは、平均通信時間算出の対象から除かれる。

よって、密連結ゲストOSグループGiの平均通信時間は、当該グループGiに属するゲストOS間で直近の1スケジュール周期内で授受されるメッセージの通信時間の総和(Σ(メッセージの通信時間)をメッセージ総数で除した値によって表される。つまり、密連結ゲストOSグループGiの平均通信時間は、次式
(Σ(メッセージの通信時間))/メッセージ総数 (1)
で表される。但し式(1)におけるメッセージとは、密連結ゲストOSグループGiに属する全てのゲストOSが送信したメッセージのうち、1スケジュール周期内に送信先のゲストOSで受信されるメッセージを指す。

このように本変形例において、平均通信時間の算定の対象とする期間は、直近の1スケジュール周期である。しかし、複数スケジュール周期で評価してそれらの平均を取って1スケジュール周期当たりの平均通信時間としても良い。

ここで、平均通信時間算出の具体例について、図8(a)の場合を例に説明する。図8(a)の例では、ゲストOS#A,#C及び#Dが1つの密連結ゲストOSグループを構成する。この密連結ゲストOSグループのグループIDを1とし、当該グループをG1、つまりGi=G1(i=1)と呼ぶことにする。ここで、クォンタムはτなので、n=1、つまりdk=d0(k=0)のケースであり、通信状態テーブル314の内容は図9のようになる。

この場合の密連結ゲストOSグループGi(G1)の平均通信時間は
(Σ(メッセージの通信時間))/メッセージ総数
=(2×2τ+1×3τ+1×2τ+1×τ)/5
=2τ
のように求められる。

ステップS30においてスケジューラ311は、求められた平均通信時間をTとする。この例では、T=2τである。ステップS30においてスケジューラ311は、密連結ゲストOSグループGi(G1)に対応する平均通信時間テーブル317のエントリに含まれているd0〜d3の各欄のうち、現在適用されているdk=d0(k=0)の欄に、求められた平均通信時間T(=2τ)を設定する。つまりスケジューラ311は、dk=d0(k=0)の欄の旧設定情報を平均通信時間T(=2τ)に更新する。ここで、更新後の平均通信時間Tは、密連結ゲストOSグループGi(G1)及びdk=d0(k=0)に関連する。そこで、更新後の平均通信時間TをTi,kと表現する。ここでは、Ti,k=T1,0(i=1,k=0)=2τである。

次にスケジューラ311は、密連結ゲストOSグループGiの現在のnの値(つまりniの値)をdkとするとき、その値が最小値(1)であるか、つまりd0(k=0)であるかを判定する(ステップS31)。もし、密連結ゲストOSグループGiの現在のn(=ni)の値dkが最小値(1)でないならば、スケジューラ311は今回求められた(dkにおける)平均通信時間Ti,kが0であるかを判定する(ステップS32)。もし、平均通信時間Ti,kが0でないならば、スケジューラ311は当該平均通信時間Ti,kがdk-1における平均通信時間Ti,k-1よりも小さいかを判定する(ステップS33)。

もし、平均通信時間Ti,kがTi,k-1よりも小さいならば、スケジューラ311は新しいn(=ni)の値を現在の値dkよりも1段階大きいdk+1に設定する(ステップS34)。つまりスケジューラ311は、CPU割り当て時間単位を現在よりも1段階細かくする。但し、dk+1が定義されていないならば、つまり現在の値dkがn値定義テーブル316によって定義される最大のnの値dmaxであるならば、それ以上大きなnの値を設定できない。このような場合、スケジューラ311は新しいn(=ni)の値を現在の値dk、つまりdmaxとする。スケジューラ311はステップS34を実行すると、上記ステップS28の処理に戻る。

一方、密連結ゲストOSグループGiの現在のn(=ni)の値dkが最小値(1)であるならば、つまり現在の値dkがd0(k=0)であるならば(ステップS31)、スケジューラ311は平均通信時間Ti,k(k=0)が0でない限りにおいて(ステップS35)、n(=ni)の値を現在の値dkよりも1段階大きいdk+1とする(ステップS34)。ここではk=0であることから、n(=ni)の値がd0(=1)からd1(=2)に変更される。

次に、密連結ゲストOSグループGiの現在のn(=ni)の値dkが最小値(1)でなく、且つ今回求められた(dkにおける)平均通信時間Ti,kが0でないものの、当該平均通信時間Ti,kがdk-1における平均通信時間Ti,k-1よりも大きいか等しいものとする(ステップS31〜S33)。この場合、スケジューラ311は新しいn(=ni)の値を、現在の値dkよりも1段階小さいdk-1とする(ステップS36)。つまりスケジューラ311は、CPU割り当て時間単位を現在よりも1段階大きくする。スケジューラ311はステップS36を実行すると、上記ステップS28の処理に戻る。

さて図14A及び図14Bのフローチャートでは、平均通信時間Ti,kが0の場合も考慮されている(ステップS32及びS35)。しかし、Ti,kが0の密連結ゲストOSグループは前記ステップS23,S24において相互通信ゲストOSテーブル315に登録されない。したがって本変形例では、平均通信時間Ti,kが0の場合は発生しない。図14A及び図14Bのフローチャートでは、一般的な処理手順とするためにTi,kが0の場合の処理も含めている。ここでは、密連結ゲストOSグループGiの現在のn(=ni)の値dkが最小値(1)でなく、且つ今回求められた(dkにおける)平均通信時間Ti,kが0であるならば(ステップS31,S32)、スケジューラ311は新しいn(=ni)の値を、現在の値dkよりも1段階小さいdk-1とする(ステップS36)。また、密連結ゲストOSグループGiの現在のn(=ni)の値dkが最小値(1)であり、且つ今回求められた平均通信時間Ti,kが0であるならば(ステップS31,S35)、スケジューラ311はn(=ni)を操作せずにステップS28の処理に戻る。

スケジューラ311はステップS28から始まる上述の処理(n値決定処理)を、全ての密連結ゲストOSグループについて実行する。そして全ての密連結ゲストOSグループについてn値決定処理を実行し終えると(ステップS28)、スケジューラ311は変数WAIT_CNTに初期値Aを設定する(ステップS37)。

次にスケジューラ311は、n値決定処理で密連結ゲストOSグループGi毎に決定(設定)されたniの値を当該グループGiに適用することにより、当該グループGiに属する各ゲストOSをτ/niの時間単位で順に実行させる新しいスケジュールを作成する(ステップS38)。スケジューラ311は、作成された新しいスケジュールの情報をディスパッチャ312に渡して、当該スケジュールに基づく再スケジューリングをディスパッチャ312に指示する(ステップS39)。以降、図14A及び図14Bのフローチャートに示される処理がA回呼ばれる間は、変数WAIT_CNTが1ずつデクリメントされるだけである(ステップS21,S22)。このため、同じniで各密連結ゲストOSグループGiがスケジューリングされる。

図8(a)の例の場合、n値決定処理(ステップS28乃至S36)の結果、ゲストOS#A,#C及び#Dによって構成される密連結ゲストOSグループG1(Gi=G1)のn1(ni=n1)の値は、d0からd1に変更される。つまりn1の値は1から2に変更される。この結果、密連結ゲストOSグループG1の新たな時間割り当て単位はτからτ/2となる。これによりゲストOS#A,#C及び#Dは、図8(b)に示すように、新たな時間割り当て単位で再スケジューリングされる。

前述したように、図9は、図8(b)の状態における通信状態テーブル314の例を示す。この通信状態テーブル314に基づき、密連結ゲストOSグループG1に関する平均通信時間を計算すると、
(Σ(メッセージの通信時間))/メッセージ総数
=(4×τ/2+1×2τ+1×τ+1×τ+1×2τ+2×τ/2)/10
=0.9τ
となる。

この計算結果から、平均通信時間が2τから0.9τに改善したことが分かる。次回、図14A及び図14Bのフローチャートに従う処理が行われるときには、図15に示されるように、平均通信時間テーブル317の密連結ゲストOSグループG1に対応するエントリのd1の欄に、「0.9τ」が記録される。すると、niの値が更にd1(=2)からd2(=3)に変更されて、割り当て時間単位がより細分化される。このようにして、効果が得られる間(つまりdkにおける新しい平均通信時間Ti,kが、dk-1における平均通信時間Ti,k-1よりも小さい間)はniの値を小さくし、効果が得られない場合にはniの値をdkから直前の値dk-1に戻すような制御が行われる。これにより、結果的に各密連結ゲストOSグループに対して最適なniの値が定められる。

前述の説明では省略されているが、前記ステップS27で平均通信時間テーブル317から削除された密連結ゲストOSグループの各ゲストOSは、nの値がd0(=1)に戻されてτの時間単位で再スケジューリングされる。

上記実施形態及びその変形例では、VMM31が、OS20上で動作する1つのアプリケーション(VMアプリケーション30)として実装される場合を想定している。しかし本発明は、VMM(仮想計算機マネージャ)が、計算機システムの実HW上にVMM機構として実装される場合にも、同様に適用可能である。

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

本発明の一実施形態に係る仮想計算機システムを実現する計算機システムの構成を示すブロック図。 図1に示されるVMM(仮想計算機モニタ)の構成を示すブロック図。 同実施形態における仮想計算機システムのシステム状態の一例を、2つのゲストOSが互いに送受信しながら処理を進める場合について示す図。 図3のシステム状態における動作シーケンスを、再スケジューリングの前後で対比して示す図。 図4(a)の状態における通信状態テーブルの一例を示す図。 同実施形態におけるクオンタム調整処理の手順を示すフローチャート。 相互通信ゲストOSテーブルの一例を示す図。 3つのゲストOSが互いに送受信しながら処理を進める場合の動作シーケンスを、再スケジューリングの前後で対比して示す図。 図8(a)の状態における通信状態テーブルの一例を示す図。 図9に示される通信状態テーブルの状態に基づいてクオンタム調整処理が行われた場合の相互通信ゲストOSテーブルの一例を示す図。 図8(b)の状態における通信状態テーブルの一例を示す図。 同実施形態の変形例で適用されるVMM(仮想計算機モニタ)の構成を示すブロック図。 n値定義テーブルの一例を示す図。 同実施形態の変形例におけるクオンタム調整処理の手順を示すフローチャート。 同実施形態の変形例におけるクオンタム調整処理の手順を示すフローチャート。 平均通信時間テーブルの一例を示す図。

符号の説明

31…VMM(仮想計算機モニタ)、32A〜32D…仮想計算機実行環境、35A〜35D…ゲストOS、311…スケジューラ、312…ディスパッチャ、313…ゲストOS間通信サービス機構、314…通信状態テーブル、315…相互通信ゲストOSテーブル、316…n値定義テーブル、317…平均通信時間テーブル。

Claims (3)

  1. 仮想計算機モニタによって提供される仮想計算機実行環境で複数のゲストOSが時分割で実行され、前記複数のゲストOSのうちの任意のゲストOS間で前記仮想計算機モニタによって提供される通信機能を用いて相互に通信を行いながら処理が進められる仮想計算機システムに適用されるゲストOSスケジューリング方法であって、
    前記仮想計算機モニタが提供する通信機能を用いて相互に通信するゲストOSのうち、1スケジュール周期内に完了する通信が相互に行われるゲストOSの対をゲストOSの組として前記仮想計算機モニタが特定するステップと、
    前記複数のゲストOSのうち、前記特定されたゲストOSの組に含まれる各ゲストOSの実行スケジュールにおけるクオンタムを前記仮想計算機モニタが短くするステップと、
    前記特定するステップ及び前記短くするステップが前記スケジュール周期で繰り返されるように前記仮想計算機モニタが制御するステップと、
    前記特定するステップが実行される都度、前記特定されたゲストOSの組毎に前記仮想計算機モニタが最新の平均通信時間である第1の平均通信時間を求めるステップと、
    前記第1の平均通信時間と前記第1の平均通信時間を求める際のクオンタムよりも1段階長いクオンタムに設定された際の第2の平均通信時間とを前記仮想計算機モニタが比較するステップとを具備し、
    前記短くするステップにおいて、前記第1の平均通信時間が前記第2の平均通信時間よりも短い場合には、前記特定されたゲストOSの組に含まれる各ゲストOSの実行スケジュールにおけるクオンタムが前記第1の平均通信時間を求める際のクオンタムよりも1段階短く設定され、前記第1の平均通信時間が前記第2の平均通信時間よりも短くない場合には、前記特定されたゲストOSの組に含まれる各ゲストOSの実行スケジュールにおけるクオンタムが前記第1の平均通信時間を求める際のクオンタムよりも1段階長く設定される
    ことを特徴とするゲストOSスケジューリング方法。
  2. 前記特定するステップにおいて、前記ゲストOSの対の一方との間で前記1スケジュール周期内に完了する通信が相互に行われる別のゲストOSが存在する場合、前記別のゲストOSも前記ゲストOSの組に属するとして扱われることを特徴とする請求項1記載のゲストOSスケジューリング方法。
  3. 複数のゲストOSが時分割で実行される仮想計算機実行環境を構築する仮想計算機モニタにおいて、
    前記複数のゲストOSのうちの任意のゲストOS間の通信を当該ゲストOSからの要求に応じて実行するゲストOS間通信手段と、
    前記ゲストOS間通信手段による前記ゲストOS間の通信の状況を保持する通信状態テーブルと、
    前記通信状態テーブルに基づいて、前記ゲストOS間通信手段を用いて相互に通信するゲストOSのうち、1スケジュール周期内に完了する通信が相互に行われるゲストOSの対をゲストOSの組として特定し、前記複数のゲストOSのうち、前記特定されたゲストOSの組に含まれる各ゲストOSの実行スケジュールにおけるクオンタムが短く設定された新たなスケジュールを作成するスケジューラと、
    前記特定されたゲストOSの組に含まれる各ゲストOSを前記新たなスケジュールで実行させるディスパッチャとを具備し、
    前記スケジューラは、前記ゲストOSの組を特定する処理を前記スケジュール周期で繰り返し、前記ゲストOSの組を特定する都度、前記特定されたゲストOSの組毎に最新の平均通信時間である第1の平均通信時間を求め、前記第1の平均通信時間が前記第1の平均通信時間を求める際のクオンタムよりも1段階長いクオンタムに設定された際の第2の平均通信時間よりも短い場合には、前記特定されたゲストOSの組に含まれる各ゲストOSの実行スケジュールにおけるクオンタムを前記第1の平均通信時間を求める際のクオンタムよりも1段階短く設定し、前記第1の平均通信時間が前記第2の平均通信時間よりも短くない場合には、前記特定されたゲストOSの組に含まれる各ゲストOSの実行スケジュールにおけるクオンタムを前記第1の平均通信時間を求める際のクオンタムよりも1段階長く設定する
    ことを特徴とする仮想計算機モニタ。
JP2006352948A 2006-12-27 2006-12-27 ゲストosスケジューリング方法及び仮想計算機モニタ Active JP4358224B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006352948A JP4358224B2 (ja) 2006-12-27 2006-12-27 ゲストosスケジューリング方法及び仮想計算機モニタ

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2006352948A JP4358224B2 (ja) 2006-12-27 2006-12-27 ゲストosスケジューリング方法及び仮想計算機モニタ
US11/962,208 US8146081B2 (en) 2006-12-27 2007-12-21 Method of selecting one of execution schedules of guest OSes and virtual machine monitor employing the method
CN2007103004377A CN101211277B (zh) 2006-12-27 2007-12-27 选择子os的一个执行计划的方法与使用该方法的虚拟机监视器

Publications (2)

Publication Number Publication Date
JP2008165410A JP2008165410A (ja) 2008-07-17
JP4358224B2 true JP4358224B2 (ja) 2009-11-04

Family

ID=39585921

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006352948A Active JP4358224B2 (ja) 2006-12-27 2006-12-27 ゲストosスケジューリング方法及び仮想計算機モニタ

Country Status (3)

Country Link
US (1) US8146081B2 (ja)
JP (1) JP4358224B2 (ja)
CN (1) CN101211277B (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009110404A (ja) 2007-10-31 2009-05-21 Toshiba Corp 仮想計算機システム及び同システムにおけるゲストosスケジューリング方法
US8019837B2 (en) * 2009-01-14 2011-09-13 International Business Machines Corporation Providing network identity for virtual machines
EP2395430B1 (en) * 2009-02-09 2017-07-12 Fujitsu Limited Virtual computer allocation method, allocation program, and information processing device having a virtual computer environment
US8719823B2 (en) 2009-03-04 2014-05-06 Vmware, Inc. Managing latency introduced by virtualization
JP4862056B2 (ja) * 2009-03-16 2012-01-25 東芝ソリューション株式会社 仮想計算機管理機構及び仮想計算機システムにおけるcpu時間割り当て制御方法
JP4755702B2 (ja) * 2009-03-25 2011-08-24 株式会社エヌ・ティ・ティ・ドコモ 情報処理装置および通信方法
US20100262722A1 (en) * 2009-04-10 2010-10-14 Christophe Vauthier Dynamic Assignment of Graphics Processing Unit to a Virtual Machine
US8429648B2 (en) * 2009-05-28 2013-04-23 Red Hat, Inc. Method and apparatus to service a software generated trap received by a virtual machine monitor
US8813069B2 (en) * 2009-05-29 2014-08-19 Red Hat, Inc. Migration of functionalities across systems
US8868987B2 (en) * 2010-02-05 2014-10-21 Tripwire, Inc. Systems and methods for visual correlation of log events, configuration changes and conditions producing alerts in a virtual infrastructure
US8875129B2 (en) * 2010-02-05 2014-10-28 Tripwire, Inc. Systems and methods for monitoring and alerting events that virtual machine software produces in a virtual infrastructure
US8566823B2 (en) 2010-02-05 2013-10-22 Tripwire, Inc. Systems and methods for triggering scripts based upon an alert within a virtual infrastructure
CN102446119B (zh) * 2010-10-13 2013-04-24 中标软件有限公司 基于Passthrough I/O的虚拟机动态迁移方法
US9253100B2 (en) * 2010-12-10 2016-02-02 Alcatel Lucent Asynchronous virtual machine replication
DE102011018431A1 (de) 2011-04-21 2012-10-25 Giesecke & Devrient Gmbh Verfahren zur Anzeige von Informationen auf einer Anzeigeeinrichtung eines Endgeräts
DE102011115135A1 (de) 2011-10-07 2013-04-11 Giesecke & Devrient Gmbh Mikroprozessorsystem mit gesicherter Laufzeitumgebung
WO2013114620A1 (ja) * 2012-02-03 2013-08-08 富士通株式会社 仮想マシン制御プログラム、仮想マシン制御方法および情報処理装置
US8839447B2 (en) * 2012-02-27 2014-09-16 Ca, Inc. System and method for virtual image security in a cloud environment
US8954964B2 (en) 2012-02-27 2015-02-10 Ca, Inc. System and method for isolated virtual image and appliance communication within a cloud environment
WO2013162599A1 (en) 2012-04-27 2013-10-31 Empire Technology Development Llc Virtual machine switching based on measured network delay
US9122549B2 (en) * 2012-07-19 2015-09-01 Wind River Systems, Inc. Method and system for emulation of instructions and hardware using background guest mode processing
US9052956B2 (en) * 2012-08-30 2015-06-09 Hewlett-Packard Development Company, L.P. Selecting execution environments
US9389898B2 (en) 2012-10-02 2016-07-12 Ca, Inc. System and method for enforcement of security controls on virtual machines throughout life cycle state changes
US8700898B1 (en) 2012-10-02 2014-04-15 Ca, Inc. System and method for multi-layered sensitive data protection in a virtual computing environment
US9652270B2 (en) * 2014-03-21 2017-05-16 Intel Corporation Apparatus and method for virtualized computing
JP6347177B2 (ja) * 2014-08-22 2018-06-27 富士通株式会社 転送装置、制御装置、および、通信方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09114683A (ja) 1995-10-16 1997-05-02 Hitachi Ltd 計算機システムの制御方法
US7415708B2 (en) * 2003-06-26 2008-08-19 Intel Corporation Virtual machine management using processor state information
JP3889726B2 (ja) * 2003-06-27 2007-03-07 株式会社東芝 スケジューリング方法および情報処理システム
JP4028444B2 (ja) * 2003-06-27 2007-12-26 株式会社東芝 スケジューリング方法およびリアルタイム処理システム
JP2006039763A (ja) 2004-07-23 2006-02-09 Toshiba Corp ゲストosデバッグ支援方法及び仮想計算機マネージャ
US7840962B2 (en) * 2004-09-30 2010-11-23 Intel Corporation System and method for controlling switching between VMM and VM using enabling value of VMM timer indicator and VMM timer value having a specified time

Also Published As

Publication number Publication date
CN101211277B (zh) 2012-07-18
US8146081B2 (en) 2012-03-27
US20080163211A1 (en) 2008-07-03
CN101211277A (zh) 2008-07-02
JP2008165410A (ja) 2008-07-17

Similar Documents

Publication Publication Date Title
Tan et al. Online job dispatching and scheduling in edge-clouds
EP3098718B1 (en) Multilayer quality of service (qos) for network functions virtualization platforms
US9164755B2 (en) Personal and pooled virtual machine update
Akherfi et al. Mobile cloud computing for computation offloading: Issues and challenges
US9405571B2 (en) Method and system for abstracting virtual machines in a network comprising plurality of hypervisor and sub-hypervisors
Yang et al. A framework for partitioning and execution of data stream applications in mobile cloud computing
Colmenares et al. Tessellation: refactoring the OS around explicit resource containers with continuous adaptation
Xu et al. vturbo: Accelerating virtual machine i/o processing using designated turbo-sliced core
Yun et al. Memory access control in multiprocessor for real-time systems with mixed criticality
Henkel et al. Invasive manycore architectures
García-Valls et al. Challenges in real-time virtualization and predictable cloud computing
Schmidt et al. An overview of the real-time CORBA specification
US8386825B2 (en) Method and system for power management in a virtual machine environment without disrupting network connectivity
Ongaro et al. Scheduling I/O in virtual machine monitors
JP4374391B2 (ja) 複数のインスタンスアプリケーションに対し負荷分散装置を動作させるシステムおよび方法
US8826292B2 (en) Migrating virtual machines based on level of resource sharing and expected load per resource on candidate target host machines
JP4519098B2 (ja) 計算機の管理方法、計算機システム、及び管理プログラム
Fallenbeck et al. Xen and the art of cluster scheduling
US20140208331A1 (en) Methods of processing core selection for applications on manycore processors
US9934073B2 (en) Extension of resource constraints for service-defined containers
Wang et al. Implementing a general real-time scheduling framework in the RED-Linux real-time kernel
Cao et al. Agent-based grid load balancing using performance-driven task scheduling
US9424094B2 (en) Server consolidation using virtual machine resource tradeoffs
JP5284809B2 (ja) 複数の仮想マシンに対して動的にリソースを割当てる方法及び装置
KR100628492B1 (ko) 실시간 동작 수행방법 및 시스템

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090119

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090203

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090403

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090428

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090624

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090714

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090805

R150 Certificate of patent or registration of utility model

Ref document number: 4358224

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120814

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120814

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130814

Year of fee payment: 4

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350