(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0013】
以下、添付した図面を参照して、本発明の実施のための具体的な例を詳しく説明する。
【0014】
図1は、本発明の一実施形態による仮想マシンモニター(virtual machine monitor、VMM)を示す図である。
図1を参照すると、仮想マシンモニター100は、多数のドメイン101、102とハードウェアプラットホーム103との間に存在する。それぞれのドメイン101、102は、運用体制(operation system)または応用プログラム(application program)になりうる。ハードウェアプラットホーム103は、中央処理装置(central processing unit、CPU)、メモリ(memory)、入出力ポート(I/O port)のような物理的装置になりうる。
【0015】
仮想マシンモニター100は、ハードウェアプラットホーム103を仮想化(virtualization)させて多数のドメイン101、102を同時に動作可能にする。すなわち、それぞれのドメイン101、102は、仮想マシンモニター100の仮想化を通じて一つの物理的システムリソースを複数個の仮想化システムリソースとして使用しうる。
【0016】
ドメイン101、102は、ハードウェアプラットホーム103に直接アクセスすることができるホストドメイン101とホストドメイン101の助けを受けて間接的にハードウェアプラットホーム103を用いるゲストドメイン102とに区分することができる。それぞれのドメイン101、102は、多種のタスク104、105を含みうる。
【0017】
仮想マシンモニター100は、少なくとも一つの実行キュー110、多数のスケジューラ121、122、123、制御部130、及びテーブル保存部140を含む。
【0018】
実行キュー110は、ドメイン101、102から受信されたタスク104、105またはタスク104、105についての情報を保存する。本発明の一実施形態によって、タスク104、105は、スケジュール対象となる単位であるスケジュールエンティティ形態で実行キュー110に保存することができる。実行キュー110に保存されたタスクT1〜T3は、スケジューラ121、122、123のスケジュール対象となる。
【0019】
本発明の一実施形態によって、実行キュー110は、一つのみ形成されることもでき、複数個が形成されうる。複数個の実行キュー110が形成される場合、それぞれの実行キュー110は、
図6Aまたは
図6Bのようにハードウェアプラットホームの各CPUコアまたは各スケジューラ121、122、123とバインディング(binding)されうる。また、それぞれの実行キュー110は、
図8のように、2次元マトリックス形態でも管理されうる。
【0020】
図8は、本発明の一実施形態による実行キューを示す図である。
図8を参照すると、本実施形態による実行キュー800は、2次元マトリックス形態を有しうる。2次元マトリックス形態で管理される実行キュー800の場合、マトリックスの行または列の別に相異なる属性を有するタスクを保存することが可能である。例えば、属性Aを有するタスク1(T1)及びタスク2(T2)は、第1列801に保存され、属性Bを有するタスク3(T3)ないしタスク5(T5)は、第2列802に保存することができる。
【0021】
本実施形態によって属性とは、タスクをトリガー(trigger)するための条件を意味する。例えば、タスク1(T1)及びタスク2(T2)は、或るイベントによってトリガーされるタスクになり、タスク3(T3)ないしタスク5(T5)は、或るインタラプトによってトリガーされるタスクになりうる。このようなタスクの属性には、イベント、デッドライン、及び/またはインタラプトなどがあり得る。
【0022】
再び
図1で、スケジューラ121、122、123は、実行キュー110にあるタスクT1〜T3の実行順序を決定する。スケジューラ121、122、123は、相異なるスケジュールの特性を有する。例えば、第1スケジューラ121は、デッドラインファーストスケジューラ(deadline first scheduler)であり、第2スケジューラ122は、ラウンドロビンスケジューラ(round−robin scheduler)であり、第3スケジューラ123は、イベントファーストスケジューラ(event first scheduler)になりうる。しかし、スケジューラの種類が、これに限定されるものではない。
【0023】
実行キュー110にあるタスクT1〜T3は、任意の時点に多数のスケジューラ121、122、123のうちからリアルタイムの特性を達成するのに最も適したスケジューラ(例えば、121)によってスケジューリングされうる。
【0024】
制御部130は、それぞれのドメイン101、102からタスク104、105を受信し、該受信されたタスクを実行キュー110に挿入する。本発明の一実施形態によって、タスク104、105は、スケジュール対象となる単位であるスケジュールエンティティ形態で実行キュー110に挿入されうる。
【0025】
制御部130は、タスク104、105を実行キュー110に挿入する時、タスクの属性別に区別されるように実行キュー110に挿入することができる。例えば、
図8のように、実行キュー110を配列(matrix)形態で管理しながら特定の行または列によって、それぞれの属性別にタスク104、105を挿入することができる。ここで、タスクの属性は、タスクをトリガーするための条件を言うことで、電話の送/受信のようなイベントソース(event source)、デッドライン及び/またはインタラプトなどを含みうるということは前述した通りである。このようなタスク属性に関する情報は、ドメイン101、102に対応する運用体制(OS)を通じて収集されうる。
【0026】
また制御部130は、タスク104、105を実行キュー110に挿入する時、タスクの優先順位によって実行キュー110を調整することができる。この際、タスク属性がイベントである場合には、加重値テーブル141に基づいて優先順位を決定することができる。またタスク属性がイベントである場合には、加重値テーブル141によらずに、そのタスクの緊急処理の必要性またはリアルタイム処理の必要性によって優先順位を決定することもできる。緊急処理の必要性またはリアルタイム処理の必要性は、タスクのデッドラインに基づいて判断されうる。
【0027】
一例として、制御部130は、運用体制から収集された情報に基づいて、或るタスクが或るイベント類型によってトリガーされるか否かを把握することが可能であるが、加重値テーブル141には、このようなイベント類型による優先順位の加重値がスケジューラ121、122、123別に保存されている。例えば、タスク1(T1)及びタスク2(T2)いずれもタスク属性がイベントであるが、タスク1(T1)は、イベント類型Aによってトリガーされ、タスク2(T2)は、イベント類型Bによってトリガーされる場合、制御部130は、加重値テーブル141のトリガー条件と関連したタスク属性を参照して、タスク1(T1)とタスク2(T2)との優先順位を決定することができる。
【0028】
また、他の例として、タスク1(T1)及びタスク2(T2)いずれもタスク属性がイベントであり、タスク1(T1)及びタスク2(T2)いずれもイベント類型Aによってトリガーされる場合、制御部130は、タスクの緊急またはリアルタイム処理の必要性に基づいて、タスク1(T1)とタスク2(T2)との優先順位を決定することができる。例えば、タスク1(T1)が5秒のデッドラインを有し、タスク2(T2)が10秒のデッドラインを有する場合、タスク1(T1)がタスク2(T2)より緊急な処理が必要であるので、タスク1がさらに高い優先順位を有するようになる。
【0029】
また制御部130は、タスク104、105を実行キュー110に挿入し、テーブル保存部140のタイムテーブル142を生成または更新することができる。タイムテーブル142には、時間と関連したタスクの制約事項、例えば、実行制限時間がタスク別に保存することができる。例えば、制御部130が、時間制約をタスクの属性として有するタスク3(T3)を受信した場合、制御部130は、タスク3(T3)を実行キュー110に入れてタイムテーブル142にタスク3(T3)の実行制限時間を記録することが可能である。
【0030】
また制御部130は、発生したイベント情報に基づいて実行キュー110に挿入されたタスクT1〜T3をスケジューリングするスケジューラを多数のスケジューラ121、122、123のうちから選択する。本実施形態によって、イベントとは、仮想マシンモニターが搭載された機器の動作によって発生する各種のシステム関連のイベントになりうる。例えば、仮想マシンモニター100基盤のデータ処理装置が携帯電話に搭載された場合、イベントの類型は、携帯電話の電話送信、電話受信、カメラON/OFF、設定されたタイマー動作、設定された時間の到来などになりうる。イベント類型によって選択されるスケジューラは、テーブル保存部140のスケジューラリスト143に基づいて選択されうる。例えば、定められたデッドライン前まで実行されてリアルタイム性が保証されて初めて有意なイベントが発生する場合、制御部130は、多数のスケジューラ121、122、123のうちからデッドラインファーストスケジューラ(例えば、121)を選択することが可能である。
【0031】
また制御部130は、選択されたスケジューラ121を呼び出す。該呼び出されたスケジューラ121は、自身のスケジュールの政策によって実行キュー110にあるタスクT1〜T3をスケジューリングする。
【0032】
このように、仮想マシンモニター100は、スケジュールの特性が異なる多数のスケジューラ121、122、123を用いて特定の状況またはタスク属性に適したスケジューラによって実行キュー110のタスクT1〜T3をスケジューリングさせうる。
【0033】
図2は、本発明の一実施形態によるスケジューラリスト143を示す図である。
【0034】
図1及び
図2を参照すると、スケジューラリスト143は、イベント201及び各イベント201によって呼び出されるスケジューラ202を含む。制御部130は、スケジューラリスト143を参照して、発生したイベントに適したスケジューラを呼び出させうる。例えば、イベントE1とイベントE2とが発生した場合、スケジューラS1が呼び出され、イベントE3が発生した場合、スケジューラS2が呼び出されうる。ここで、それぞれのイベント201は、仮想マシンモニター100基盤システムの各種のシステムイベントになりうる。また、スケジューラS1とスケジューラS2は、相異なるスケジュールの特性または相異なるスケジュールの政策を有するスケジューラを表わす。
【0035】
図3は、本発明の一実施形態による加重値テーブル141を示す図である。
【0036】
図1及び
図3を参照すると、加重値テーブル141は、それぞれのタスク属性301による加重値302をスケジューラS1、S2別に有しうる。タスクの属性は、タスクをトリガーするための条件として電話の送/受信のようなイベントソース、デッドライン及び/またはインタラプトなどを含み、このようなタスク属性に関する情報は、制御部130がドメイン101、102に対応する運用体制(OS)を通じて収集することが可能である。
【0037】
タスク属性がイベントであるタスクT1〜T3が実行キュー110に挿入される時、制御部130は、加重値テーブル141を参照して、実行キュー110に挿入されるタスクT1〜T3の優先順位を決定することができる。例えば、イベントE1E1によってトリガーされるタスク1とイベントE2E2によってトリガーされるタスク2とが受信された場合、制御部130は、加重値テーブル141を参照して、タスク1の優先順位をタスク2より高く設定することが可能である。この際、それぞれの加重値は、スケジューラS1、S2別に異ならせて与えられうる。例えば、イベントE1E1及びイベントE2E2が、スケジューラS2のスケジュールの特性に何らの影響を及ぼさない場合、スケジューラS2では、加重値が同様に与えられうる。
【0038】
一方、例えば、タスク1及びタスク2いずれもタスク属性がイベントであり、またいずれもイベント類型E1によってトリガーされる場合、加重値テーブル141を参照すれば、タスク1とタスク2との優先順位が同じくなることもできるが、このような場合、制御部130は、タスクの緊急処理の必要性またはリアルタイム処理の必要性に基づいて、タスク1(T1)とタスク2(T2)との優先順位を決定することも可能である。
【0039】
図4は、本発明の一実施形態によるタイムテーブル142を示す図である。
【0040】
図1及び
図4を参照すると、タイムテーブル142は、タスク別に時間制約事項、例えば、実行制限時間が保存することができる。例えば、制御部130は、タスクを実行キュー110に挿入し、タイムテーブル142を周期的に更新することが可能である。
【0041】
図5A及び
図5Bは、本発明の一実施形態による仮想マシンモニターの選択的スケジューリング動作を示す図である。
【0042】
図1、
図5A及び
図5Bで、3つのタスクT1、T2、T3が受信され、タスクT1は、イベントE1によってトリガーされ、タスクT2は、イベントE2によってトリガーされ、タスクT3は、イベントE3によってトリガーされると仮定する。そして、イベントE3は、タイムインタラプトであり、スケジューラは、スケジューラS1とスケジューラS2の二つが存在すると仮定する。
【0043】
まず制御部130は、タスク属性を考慮してタスクT1、T2、T3の優先順位を決定して実行キュー110に挿入する。例えば、制御部130は、‘イベント’というタスクの属性を考慮した加重値テーブル141を用いてタスクT1〜T3の優先順位を調節し、既存に挿入されていたタスクの順序も再配置されうる。
【0044】
本実施形態において、加重値テーブル141は、各スケジューラによって異ならせて指定されているので、制御部130がタスクの優先順位を決定する時、或るスケジューラを基準にするのかによって実行キュー110に挿入されるタスクの優先順位が調節される。例えば、スケジューラS1を基準に優先順位を決定すれば、イベントE1によってトリガーされるタスクT1の優先順位が最も高く決定されうる。このような場合、
図5Aに示されたように、実行キュー110には、T1、T2、T3の順にタスクが挿入されうる。またスケジューラS2を基準に優先順位を決定すれば、イベントE3によってトリガーされるタスクT3の優先順位が最も高く決定されうる。このような場合、
図5Bに示されたように、実行キュー110には、T3、T1、T2の順にタスクが挿入されうる。
【0045】
一旦、タスクT1、T2、T3が実行キュー110に挿入されてから特定イベントが発生すれば、制御部130は、発生したイベント類型によって適切なスケジューラS1、S2を選択する。
【0046】
例えば、
図2及び
図5Aで、イベントE1が発生した場合、制御部130は、スケジューラリスト143を参照して、スケジューラS1を呼び出すことができる。また、
図2及び
図5Bで、イベントE3が発生した場合、制御部130は、スケジューラリスト143を参照して、スケジューラS2を呼び出すことができる。
【0047】
イベントE3がタイムインタラプトであり、スケジューラS2がデッドラインスケジューラである場合を説明すれば、制御部130は、時間制約を有するタスクを実行キュー110に挿入しながら、タイムテーブル142を更新し、タイムインタラプトが発生すれば、デッドラインスケジューラを活性化させて時間制約を有するタスクを先にスケジューリングさせうる。また、タイムインタラプトのない間には、他の適切なスケジューラを活性化させてタスクをその優先順位によってスケジューリングすることができる。
【0048】
図6Aは、本発明の他の実施形態による仮想マシンモニターを示す図である。
図6Aを参照すると、仮想マシンモニター100は、ハードウェアプラットホームの各CPUコアに対応して多数の実行キュー110−1、110−2、110−3を含む。
図6Aで、それぞれの実行キュー110−1、110−2、110−3は、ハードウェアプラットホーム103の3つのCPUコア(CPU#0〜CPU#2)にそれぞれマッピングされうる。制御部130は、タスク104、105が受信されれば、運用体制から伝達されたタスク属性を用いて受信されたタスク104、105が挿入されるに適した実行キューを決定することが可能である。
【0049】
図6Bは、本発明のまた他の実施形態による仮想マシンモニターを示す図である。
図6Bを参照すると、仮想マシンモニター100は、それぞれのタスク属性に対応して多数の実行キュー110−1、110−2、110−3を含む。
図6Bで、それぞれのタスク属性に対応する最適の実行キュー110−1、110−2、110−3は、それぞれのスケジューラ121、122、123にマッピングされうる。制御部130は、タスク104、105が受信されれば、運用体制から伝達されたタスク属性を用いて受信されたタスク104、105が挿入されるに適した実行キューを決定することが可能である。
【0050】
図7は、本発明の一実施形態による仮想マシンモニターのスケジューリング方法を示す図である。これは、
図1で示されたシステムに適用可能である。
【0051】
図1及び
図7を参照すると、仮想マシンモニター100は、ドメイン101、102から受信されたタスクを少なくとも一つの実行キュー110に挿入する(701)。本実施形態で、受信されたタスクは、加重値テーブル141またはタスクの緊急処理の必要性に基づいて判断された優先順位によって実行キュー110に挿入されうる。また、タスクが実行キュー110に挿入されながらタスクの実行制限時間が記録されたタイムテーブル142が生成または更新されうる。
【0052】
そして、仮想マシンモニター100は、イベントの類型によって実行キュー110に挿入されたタスクT1〜T3をスケジューリング、すなわち、ハードウェアプラットホームで実行される順序を決定するスケジューラを多数のスケジューラ121、122、123のうちから選択する(702)。例えば、制御部130が、テーブル保存部140に保存されたスケジューラリスト143を参照して、現在状況またはタスク属性に最も適したスケジューラを選択することが可能である。
【0053】
そして、仮想マシンモニター100は、選択されたスケジューラを呼び出す(703)。例えば、制御部130が選択されたスケジューラを呼び出し、該呼び出されたスケジューラによって実行キュー110にあるタスクT1〜T3が呼び出されたスケジューラのスケジュールの特性またはスケジュールの政策によってスケジューリングさせることが可能である。
【0054】
また、本発明の一実施形態によって、実行キュー110が複数個形成される場合、仮想マシンモニター100は、運用体制から伝達されたタスクの属性を用いてタスク属性に合う実行キューを選択し、該選択された実行キューにタスクを挿入することも可能である。
【0055】
図9は、仮想マシンモニター(VMM)の他の例を示す図である。
【0056】
リアルタイムドメイン(RT−DOMAIN)のタスク創造、例えば、承認制御(admission control)、タスク特性によるグルーピング、及びスケジューラ間の関係が提供されうる。これにより、多数のリアルタイムドメインが仮想マシンモニター(VMM)で実行される時、各リアルタイムドメインのタスク及びリアルタイムドメインのタスクに対してリアルタイムの特性が保証されうる。
【0057】
本実施形態は、VMMで多数の仮想マシン(RT_DOMAIN)が実行される時、タスクに関してリアルタイムの特性を提供することを含む。例えば、本実施形態は、VMMのスケジューリング単位でリアルタイムドメインのリアルタイムタスクを管理すること、多数のリアルタイムドメインのタスクの優先順位を管理すること、スケジュールエンティティをグルーピングすること、及びスケジューリングすること、などを含みうる。
【0058】
RT−DOMAINのタスクが生成されれば、タスクは、VMMのスケジュールフレームワーク/承認制御部(Schedule Framework/Admission Control unit)を通じてVMMのスケジュールエンティティに縛られ、
図1の実行キュー110または
図9のマルチレベル実行キューに挿入されうる。タスクが生成されれば、RT−DOMAINのリアルタイム運用体制(RTOS)は、デッドライン、周期、イベントソースなどのような情報をVMMによって提供されるインターフェースを通じて承認制御部(Admission Control unit)に伝達する。VMMの承認制御部は、このような情報に基づいてリアルタイムタスクをVMMのスケジュールエンティティに結合させてスケジュールエンティティを実行キューに挿入することができる。
【0059】
スケジュールエンティティの特性を考慮すれば、承認制御部は、多数の実行キューを維持し、スケジュールエンティティが挿入される時、対象実行キュー(target run queue)を決定することができる。実行キューは、タスクのデッドラインが高く評価される実行キュー及びタスクの相互作用(interactivity)が高く評価される実行キューを含みうる。
【0060】
スケジュールエンティティが実行キューに挿入されれば、承認制御部は、RTOSから伝達されたタスクの属性に基づいてスケジュールエンティティの優先順位を調節することができる。例えば、イベントソースによってトリガーされるタスクに対して、スケジュールエンティティの優先順位が、
図1の加重値テーブル141のようなイベント加重値テーブルの優先順位に対する調節値によって調整されうる。また他の例として、時間に対する制限を有しているタスクに対して、タイムチャートが承認制御部に維持されることもある。その結果、時間に対する制限を有しているタスクは、与えられた時間制限内で実行を再開することができる。
【0061】
イベント加重値テーブルは、システムから提供されるそれぞれの物理的イベントソースまたは論理的ソースに割り当てされる優先順位を有するテーブルになりうる。イベント加重値テーブルは、静的に提供され、システム実行によって動的にも更新されうる。タイムチャート、例えば、
図1のタイムテーブル142は、生成されたスケジュールエンティティのタイムスロット(slot)を維持するために提供されうる。
【0062】
実行キューに挿入されたスケジュールエンティティは、所定時間に最も適切なスケジューラを通じてスケジュールされうる。例えば、タイマーインタラプトが発生する度に、またはタイマーの設定が必要な度に、VMMはタイムチャートを更新し、時間制約を有するリアルタイムタスクをスケジュールするためにデッドラインスケジューラを実行することができる。またタイマーインタラプトが発生するものの以外に他の類型のイベントが発生する場合、VMMは、そのイベントに適切なスケジューラを通じてスケジュールエンティティをスケジュールすることができる。例えば、一般的な目的のドメイン(General−purpose domain、GP−DOMAIN)は、リアルタイムドメインより低い優先順位を有しうる。
【0063】
図10は、仮想マシンモニターの制御ロジックのための方法を示す図である。段階1010で、タスクを処理するための要請が受信される。段階1020で、受信されたタスクの種類が決定される。もし、周期的なタスク(periodic task)、例えば、任意の時間に実行されるタスクが受信された場合、段階1030で、空き時間スロットが利用可能か否か判断する。もし、空き時間スロットが存在すれば、段階1050で、空き時間スロットが得られる。段階1055で、周期的なタイマーがセッティングされうる。タスクは、段階1060で処理のために承認されうる。もし、空き時間スロットが段階1030で存在しない場合、タスクは、段階1070で拒絶されうる。
【0064】
もし、段階1020で、デッドラインタスク、すなわち、実行完了についての時間またはデッドラインが設定されているタスクが受信された場合、段階1040で、空き時間スロットが利用可能か否か判断する。もし、空き時間スロットが存在すれば、空き時間スロットが段階1090で得られる。段階1095で、スナップショットタイマーがセッティングされうる。もし、空き時間スロットが段階1040で存在しない場合、段階1080で受信されたタスクがタスクと関連したデッドラインに相応する時間スロットに既存在するタスクより優先順位が高いか否かが判断される。もし、そうでなければ、タスクは、段階1070で拒絶されうる。もし、受信されたタスクが高い優先順位を有する場合、所望の時間スロットが段階1085で分割されうる。そして、段階1095でスナップショットタイマーがセッティングされうる。タスクは、段階1060で実行のために承認されうる。
【0065】
開示された実施形態は、仮想環境でリアルタイムの特性を提供することができるシステム及び方法を含みうる。
【0066】
スケジューラの種類及び個数は、多様に適用可能である。VMMは、論理構成になることもできる。或るスケジューラは、他のスケジューラによって活性化されることもできる。例えば、インタラプト基盤のスケジューラと関連した特定キューのタスク実行が完了されれば、VMMは、キューを元々インタラプト基盤のスケジューラに戻すか、または他のスケジューラのキューで持続させることができる。また多数の実行時間キューが存在することもできる。タスクまたはイベントの緊急性(urgency)は、キューのタスク順序を変化させることができる。
【0067】
特定のスケジューラは、イベントがスケジューラの変化をトリガーしない場合、他のスケジューラの実行時間キュー(run time queue)を実行することができる。特定のスケジューラは、自身のキューの一部を処理し、他のスケジューラのキューに移動することもできる。例えば、デッドラインスケジューラ、例えば、スケジューラ121は、緊急処理するタスクのない場合、他のスケジューラのためのキューを処理することもできる。
【0068】
前述したように、仮想マシンモニター100は、スケジュールの特性が他の多数のスケジューラ121、122、123を運用しながらイベント状況に合うまたはタスク属性に合うスケジューラでタスクをスケジューリングすることが分かる。したがって、リアルタイムタスクのようにユーザ要求に敏感に反応するタスクを適切にスケジューリングすることが可能である。
【0069】
一方、本発明の実施形態は、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なコードとして具現することが可能である。コンピュータで読み取り可能な記録媒体は、コンピュータシステムによって読み取れるデータが保存されるあらゆる種類の記録装置を含む。
【0070】
コンピュータで読み取り可能な記録媒体の例としては、ROM、RAM、CD−ROM、磁気テープ、フロッピー(登録商標)ディスク、光データ保存装置などがあり、また、キャリアウェーブ(例えば、インターネットを通じる伝送)の形態で具現するものを含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークで連結されたコンピュータシステムに分散されて、分散方式でコンピュータで読み取り可能なコードとして保存されて実行可能である。そして、本発明を具現するための機能的な(functional)プログラム、コード及びコードセグメントは、本発明が属する技術分野のプログラマーによって容易に推論されうる。
【0071】
以上、本発明の実施のための具体的な例を説明した。前述した実施形態は、本発明を例示的に説明するためのものであって、これによって本発明の権利範囲が特定の実施形態に限定されるものではない。