特許第6383518号(P6383518)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 三星電子株式会社の特許一覧

特許6383518仮想マシンモニター及び仮想マシンモニターのスケジューリング方法
<>
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000002
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000003
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000004
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000005
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000006
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000007
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000008
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000009
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000010
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000011
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000012
  • 特許6383518-仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 図000013
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6383518
(24)【登録日】2018年8月10日
(45)【発行日】2018年8月29日
(54)【発明の名称】仮想マシンモニター及び仮想マシンモニターのスケジューリング方法
(51)【国際特許分類】
   G06F 9/48 20060101AFI20180820BHJP
   G06F 9/455 20060101ALI20180820BHJP
【FI】
   G06F9/48 300Z
   G06F9/455 150
【請求項の数】17
【全頁数】17
(21)【出願番号】特願2011-54346(P2011-54346)
(22)【出願日】2011年3月11日
(65)【公開番号】特開2011-192281(P2011-192281A)
(43)【公開日】2011年9月29日
【審査請求日】2014年3月5日
【審判番号】不服2016-14865(P2016-14865/J1)
【審判請求日】2016年10月4日
(31)【優先権主張番号】10-2010-0022495
(32)【優先日】2010年3月12日
(33)【優先権主張国】KR
(73)【特許権者】
【識別番号】390019839
【氏名又は名称】三星電子株式会社
【氏名又は名称原語表記】Samsung Electronics Co.,Ltd.
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100091214
【弁理士】
【氏名又は名称】大貫 進介
(72)【発明者】
【氏名】徐 尚 範
(72)【発明者】
【氏名】柳 在 敏
【合議体】
【審判長】 石井 茂和
【審判官】 山崎 慎一
【審判官】 須田 勝巳
(56)【参考文献】
【文献】 特開2000−347883(JP,A)
【文献】 特開2001−117786(JP,A)
【文献】 特開平7−191863(JP,A)
【文献】 特開2000−137621(JP,A)
【文献】 米国特許第7296271(US,B1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F9/48
G06F9/455
(57)【特許請求の範囲】
【請求項1】
リアルタイムタスクのためのリアルタイムドメインおよび一般目的のタスクのための一般ドメインを含む複数のドメインのためのハードウェアを仮想化する、仮想マシンモニターを含むシステムであって,
前記仮想マシンモニターは,
実行キューと、
前記ハードウェア上のタスクの実行順を決定するように構成された、相異なるスケジュールの特性を有する複数のスケジューラと、
スケジューラリストと加重値テーブルとタイムテーブルとを格納するテーブル格納部と、
制御部と、
を含み、
前記スケジューラリストは、タスクを起動するイベント毎に、呼び出されるスケジューラが対応付けられて記録されており、
前記加重値テーブルは、スケジューラ毎に独立して、タスクの属性に応じたそれぞれ異なる加重値が記録されており、
前記タイムテーブルは、実行タイムリミットを有するそれぞれのタスクのための対応する実行タイムリミットが記録されており、
前記制御部は,プロセッサを含み、
前記リアルタイムドメインから受信されたタスクを前記実行キューに挿入し、
前記タスクをトリガーするイベントのイベント類型に基づいて、前記複数のスケジューラの中から、前記タスクをスケジューリングするのに適したスケジューラを選択し、
前記実行キューの中のタスクの実行順を、タスクの属性と前記タスクをトリガーするイベント類型に基づいて調整し、
前記実行キュー内のタスクの実行順を当該タスクの優先度の順位と前記加重値テーブルとに基づいて決定し、
前記複数のタスクは、その決定された実行順に基づいて実行されるためにスケジューリングされる、
ことを特徴とするシステム
【請求項2】
前記タスクの属性は、
前記タスクをトリガー(trigger)するためのイベントソースを含むことを特徴とする請求項に記載のシステム
【請求項3】
前記優先度の順位の加重値は、
前記スケジューラの種類別に独立した値を有することを特徴とする請求項に記載のシステム
【請求項4】
前記制御部は、
受信されたタスクの緊急処理の必要性またはリアルタイム処理の必要性によって、前記タスクの優先度の順位を決定することを特徴とする請求項に記載のシステム
【請求項5】
前記制御部は、
前記タイムテーブルを生成または更新することを特徴とする請求項に記載のシステム
【請求項6】
前記制御部は、選択されたスケジューラを呼び出し、
前記実行キューに挿入されたタスクは、呼び出されたスケジューラのスケジュールの特性によってスケジューリングされることを特徴とする請求項1に記載のシステム
【請求項7】
前記実行キューは、
多数個が形成されることを特徴とする請求項1に記載のシステム
【請求項8】
それぞれの実行キューは、
前記仮想マシンモニターによって管理される多数の物理資源にそれぞれマッピングされることを特徴とする請求項に記載のシステム
【請求項9】
それぞれの実行キューは、
前記多数のスケジューラにそれぞれマッピングされることを特徴とする請求項に記載のシステム
【請求項10】
前記制御部は、
前記受信されたタスクの属性によって、前記タスクが挿入される実行キューを決定することを特徴とする請求項に記載のシステム
【請求項11】
前記実行キューは、行と列とを有するマトリックス形態を有し、
前記制御部は、前記受信されたタスクの属性によって、前記タスクが挿入される実行キューの行または列を決定することを特徴とする請求項1に記載のシステム
【請求項12】
前記スケジューラは、デッドラインスケジューラを含み、
前記制御部は、前記イベントの類型でタイムインタラプトが発生した場合、前記デッドラインスケジューラを呼び出すことを特徴とする請求項1に記載のシステム
【請求項13】
リアルタイムタスクのためのリアルタイムドメインおよび一般目的のタスクのための一般ドメインを含む複数のドメインのためのハードウェアを仮想化する、仮想マシンモニターを含むシステムにおける、前記仮想マシンモニターのスケジューリング方法であって
相異なるスケジュールの特性を有する複数のスケジューラを前記ハードウェア上のタスクの実行順を決定するように構成する段階と、
スケジューラリストと加重値テーブルとタイムテーブルとを格納する段階と、を含み、
前記スケジューラリストは、タスクを起動するイベント毎に、呼び出されるスケジューラが対応付けられて記録されており、
前記加重値テーブルは、スケジューラ毎に独立して、タスクの属性に応じたそれぞれ異なる加重値が記録されており、
前記タイムテーブルは、実行タイムリミットを有するそれぞれのタスクのための対応する実行タイムリミットが記録されており、
さらに、
前記リアルタイムドメインから受信されたタスクを実行キューに挿入し、
前記タスクをトリガーするイベントのイベント類型に基づいて、前記複数のスケジューラの中から、前記タスクをスケジューリングするのに適したスケジューラを選択し、
前記実行キューの中のタスクの実行順を、タスクの属性と前記タスクをトリガーするイベント類型に基づいて調整し、
前記実行キュー内のタスクの実行順を当該タスクの優先度の順位と前記加重値テーブルとに基づいて決定し、
前記複数のタスクを、その決定された実行順に基づいて実行するようにスケジューリングする、
段階を含む、
ことを特徴とするスケジューリング方法。
【請求項14】
前記タスクを挿入する段階は、
前記タスクの実行制限時間が記録されたタイムテーブルを生成または更新する過程を含むことを特徴とする請求項13に記載のスケジューリング方法。
【請求項15】
前記タスクを挿入する段階は、
前記受信されたタスクの属性によって、前記タスクが挿入される実行キューを決定する過程を含むことを特徴とする請求項13に記載のスケジューリング方法。
【請求項16】
前記選択されたスケジューラを呼び出す段階をさらに含み、
前記実行キューに挿入されたタスクは、呼び出されたスケジューラのスケジュールの特性によってスケジューリングされることを特徴とする請求項13に記載のスケジューリング方法。
【請求項17】
リアルタイムタスクのためのリアルタイムドメインおよび一般目的のタスクのための一般ドメインを含む複数のドメインのためのハードウェアを仮想化する、仮想マシンモニターを含むシステムにおける、前記仮想マシンモニターのスケジュール方法が記録されたコンピュータで読取り可能な記録媒体であって、
前記仮想マシンモニターにより、相異なるスケジュールの特性を有する複数のスケジューラを前記ハードウェア上のタスクの実行順を決定するように構成する段階と、
前記仮想マシンモニターにより、スケジューラリストと加重値テーブルとタイムテーブルとを格納する段階と、を含み、
前記スケジューラリストは、タスクを起動するイベント毎に、呼び出されるスケジューラが対応付けられて記録されており、
前記加重値テーブルは、スケジューラ毎に独立して、タスクの属性に応じたそれぞれ異なる加重値が記録されており、
前記タイムテーブルは、実行タイムリミットを有するそれぞれのタスクのための対応する実行タイムリミットが記録されており、
さらに、前記仮想マシンモニターにより、
前記リアルタイムドメインから受信されたタスクを実行キューに挿入し、
前記タスクをトリガーするイベントのイベント類型に基づいて、前記複数のスケジューラの中から、前記タスクをスケジューリングするのに適したスケジューラを選択し、
前記実行キューの中のタスクの実行順を、タスクの属性と前記タスクをトリガーするイベント類型に基づいて調整し、
前記実行キュー内のタスクの実行順を当該タスクの優先度の順位と前記加重値テーブルとに基づいて決定し、
前記複数のタスクを、その決定された実行順に基づいて実行さるようにスケジューリングする、
段階を含む、
ことを特徴とするコンピュータで読取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、多数の運用体制を同時に駆動するための仮想化技術及びリアルタイム保証のためのスケジューリング技術に関する。
【背景技術】
【0002】
仮想化(virtualization)とは、自体の運用体制を有している多数の仮想マシン(virtual machine)が一つのホストコンピュータ上で動作できるようにする技術を言う。
【0003】
このような仮想化によってホストコンピュータは、仮想マシンモニター(virtual machine monitor)を実行し、該実行された仮想マシンモニターは、複数個の仮想マシンを生成する。該生成された仮想マシンは、同時に実行されることが可能であり、それぞれの仮想マシンは、仮想化されたハードウェア資源を有する。例えば、それぞれの仮想マシンは、物理CPUを仮想化した1つ以上のvirtual CPU(VCPU)を有し、メモリ領域の一部を占有することができる。
【0004】
仮想化環境でスケジューリングは、VCPU単位からなるためにスケジューリング時にただVCPUに割り当てられたTime Quantumのみを考慮してスケジューリングをする。したがって、リアルタイム応用を支援するのに適しない。
【発明の概要】
【発明が解決しようとする課題】
【0005】
本発明は、仮想マシンモニター及び仮想マシンモニターのスケジューリング方法を提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明の一態様による仮想マシンモニターは、少なくとも二つのドメインを駆動する仮想マシンモニターにおいて、少なくとも一つの実行キューと、相異なるスケジュールの特性を有する多数のスケジューラと、ドメインから受信されたタスクを実行キューに挿入し、イベントの類型によって実行キューに挿入されたタスクをスケジューリングするスケジューラを多数のスケジューラのうちから選択する制御部と、を含む。
【0007】
また、仮想マシンモニターは、イベントの類型によるタスクの優先順位の加重値が記録された加重値テーブルと、タスクの実行制限時間が記録されたタイムテーブルと、イベント類型によって選択されるスケジューラが記録されたスケジューラリストのうち少なくとも一つ以上を保存するテーブル保存部と、をさらに含みうる。
【0008】
また、制御部は、受信されたタスクを実行キューに挿入し、タスクの属性及び加重値テーブルを用いてタスクの優先順位を決定することが可能である。
【0009】
また、制御部は、受信されたタスクを前記実行キューに挿入し、タイムテーブルを生成または更新することが可能である。
【0010】
また、制御部は、選択されたスケジューラを呼び出し、実行キューに挿入されたタスクは、呼び出されたスケジューラのスケジュールの特性によってスケジューリングされうる。
【0011】
一方、本発明の一態様による仮想マシンモニターのスケジューリング方法は、少なくとも二つのドメインを駆動する仮想マシンモニターのスケジューリング方法において、ドメインから受信されたタスクを少なくとも一つの実行キューに挿入する段階と、イベントの類型によって実行キューに挿入されたタスクをスケジューリングするスケジューラを多数のスケジューラのうちから選択する段階と、を含む。
【図面の簡単な説明】
【0012】
図1】本発明の一実施形態による仮想マシンモニターを示す図である。
図2】本発明の一実施形態によるスケジューラリストを示す図である。
図3】本発明の一実施形態による加重値テーブルを示す図である。
図4】本発明の一実施形態によるタイムテーブルを示す図である。
図5A】本発明の一実施形態による仮想マシンモニターの動作を示す図である。
図5B】本発明の他の実施形態による仮想マシンモニターの動作を示す図である。
図6A】本発明の他の実施形態による仮想マシンモニターを示す図である。
図6B】本発明のまた他の実施形態による仮想マシンモニターを示す図である。
図7】本発明の一実施形態による仮想マシンモニターのスケジューリング方法を示す図である。
図8】本発明の一実施形態による実行キューを示す図である。
図9】本発明の他の実施形態による仮想マシンモニターを示す図である。
図10】本発明の一実施形態による仮想マシンモニトウル制御するためのフローチャートを示す図である。
【発明を実施するための形態】
【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】
以上、本発明の実施のための具体的な例を説明した。前述した実施形態は、本発明を例示的に説明するためのものであって、これによって本発明の権利範囲が特定の実施形態に限定されるものではない。
【産業上の利用可能性】
【0072】
本発明は、多数の運用体制を同時に駆動するための仮想化技術及びリアルタイム保証のためのスケジューリング技術分野に適用されうる。
【符号の説明】
【0073】
100 仮想マシンモニター
101 ホストドメイン
102 ゲストドメイン
103 ハードウェアプラットホーム
104、105 タスク
110、110−1、110−2、110−3、800 実行キー
121、122、123 第1〜第3スケジューラ
130 制御部
140 テーブル保存部
141 加重値テーブル
142 タイムテーブル
143 スケジューラリスト
201 イベント
202 スケジューラ
301 タスク属性
302 加重値
図1
図2
図3
図4
図5A
図5B
図6A
図6B
図7
図8
図9
図10