JP5624084B2 - 計算機、仮想化機構、及びスケジューリング方法 - Google Patents

Description

本発明は、複数の仮想計算機を実行する物理的な計算機等に関し、複数の仮想計算機の処理に共通する共通処理のスケジューリング技術に関する。

近年、高性能な計算機のハードウェアリソースを分割してＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）と称する単位のパーティションにし、このパーティションをそれぞれ１台のサーバとして運用するサーバ仮想化が実用化されている。サーバ仮想化は、ＶＭの動作環境によって、ハイパバイザ型とホストＯＳ型とに分類される。前者は、複数のＶＭをベアマシン上に存在する特殊な管理プログラム（ハイパバイザ）上で動作させる方法である。後者は、一般的なＯＳ上（ホストＯＳ）で管理プログラムを一つのアプリケーションとして稼動させ、その上でＶＭを動作させる方法である。何れの方法に関わらずサーバ分割には、ＶＭＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）と呼ばれる制御部（仮想計算機制御部）と、その上で動作するＶＭが存在する。ＶＭは、「仮想計算機」と呼ばれ、その上で動作するＯＳは「ゲストＯＳ」と呼ばれる。ゲストＯＳの動作は、サーバ分割していないサーバ上での動作と機能的に同じものとなる。

ＶＭＭは、主として「命令エミュレーション」、「メモリ管理」、「Ｉ／Ｏ制御」、「プロセススケジューリング」の処理を司る。ＶＭは、物理計算機のリソースを共有して使用するので、ＶＭＭが司る処理には、各ＶＭから必要とされる共通処理が存在する。一般に、このような共通処理は、各ＶＭの処理よりも優先して処理しなければならない。共通処理を優先して処理するためのスケジューリング方法としては、イベントドリブン方法が一般的である。イベントドリブン方法では、共通処理は通常待ち状態にあり、イベント通知を受けて起動し、要求された処理を完了すると、再び待ち状態に戻る。

ＶＭＭが司る共通処理に対するスケジューリング方法においては、全ての物理ＣＰＵがＶＭやＶＭＭの処理を実行中であるＲＵＮ状態にあるときに、共通処理を実行する物理ＣＰＵをどのように選択するのかという課題がある。物理ＣＰＵの選択を正しく行わないと、ＶＭＭの共通処理が、ＶＭ処理用に割り当てられている物理ＣＰＵのリソースを長時間独占してしまい、これによってＶＭの処理が続行できなくなってしまう可能性がある。

この問題を解決するための方法として、特許文献１には、ＶＭＭの共通処理にタイムシェアリング方式を導入し、さらに物理ＣＰＵを選択するための情報として、ＶＭＭの共通処理がＲＵＮ状態の物理ＣＰＵで走行した回数を使用することで、全ての物理ＣＰＵで均等にＶＭＭの共通処理を実行する方法が示されている。なお、物理ＣＰＵで処理が実行されることは、処理が物理ＣＰＵで（走る）走行するともいう。

特開２００８−１８６１３６号公報

ここで、図面を参照して、発明が解決しようとする課題について説明する。

図９は、ＶＭＭプロセスのスケジューリング動作を表した概念図である。図９（ａ１）は、特許文献１に示された、タイムシェアリング方式を導入するとともに、ＶＭＭプロセス（ＶＭＭの共通処理）がＲＵＮ状態の物理ＣＰＵで走行した回数情報を使用して物理ＣＰＵを選択するスケジューリング動作を示している。

ここで、図９においては、逆三角形は、ＶＶＭイベント通知（要求）を示し、逆三角形の上の数字は、ＶＭＭイベントの要求番号を示し、逆三角形内部の数字は、ＶＭＭ処理の長さ（処理を実行するのに必要な時間の長さ）を示す。同図では、例えば、長さ１は、タイムシェアリングにおけるタイムスライスの１つ分であることを示す。また、ＳＷが記載された矩形は、プロセス（処理）の切り替えを示す。網掛け矩形は、ＶＭＭイベントの要求に対する処理（共通処理）を示し、網掛け矩形中の数字は、要求番号を示す。また、同図においては、前提として、計算機には、３つの物理ＣＰＵ（物理ＣＰＵ０、物理ＣＰＵ１、物理ＣＰＵ２）が存在し、３つの物理ＣＰＵは、共にＶＭの処理を実行中であるＲＵＮ状態であり、物理ＣＰＵ０で占有的に走行しているＶＭが、ＶＭＭプロセス（共通処理）のイベント通知を発行するものとする。

イベント通知８００（要求１）に対するＶＭＭの共通処理は、物理ＣＰＵ０で実行され、タイムシェアリングの単位時間（タイムスライス）が経過すると、物理ＣＰＵ０から物理ＣＰＵ１に切り替えられて実行され、その後終了する。ここで、ＶＭＭの共通処理が物理ＣＰＵ０から物理ＣＰＵ１に切り替えて実行される場合には、物理ＣＰＵ０においてＶＭＭの共通処理からＶＭの処理への切り替えが発生するとともに、物理ＣＰＵ１においてＶＭの処理からＶＭＭの共通処理への切り替えが行われる。イベント通知８０１（要求２）に対するＶＭＭの共通処理は、ＲＵＮ状態の物理ＣＰＵの中の共通処理が走行した回数が最も少ない物理ＣＰＵで走行を開始するので、物理ＣＰＵ２で実行が開始される。要求２に対するＶＭＭの共通処理は、タイムシェアリングのタイムスライスが経過すると、物理ＣＰＵ２から物理ＣＰＵ１に切り替えられて実行され、同様にして、物理ＣＰＵ１から物理ＣＰＵ２に切り替えられて実行され、物理ＣＰＵ２から物理ＣＰＵ０に切り替えられて実行され、その後終了する。また、イベント通知８０２（要求３）に対するＶＭＭの共通処理は、ＲＵＮ状態の物理ＣＰＵの中の共通処理が走行した回数が最も少ない物理ＣＰＵで走行を開始するので、物理ＣＰＵ１で実行が開始される。要求３に対するＶＭＭの共通処理は、タイムシェアリングのタイムスライスが経過すると、物理ＣＰＵ１から物理ＣＰＵ２に切り替えられて実行され、同様にして、物理ＣＰＵ２から物理ＣＰＵ０に切り替えられて実行され、その後終了する。

共通処理を実行する物理ＣＰＵを切り替えるためには、切り替え前の物理ＣＰＵと、切り替え後の物理ＣＰＵとにおいて、ＶＭの処理とＶＭＭの共通処理との処理を切り替えるためのコストが発生する。タイムシェアリングにおいては、物理ＣＰＵで共通処理がタイムスライスだけ走行すると、切り替えが行われることとなるが、共通処理を次に走行する物理ＣＰＵに引き継ぐための選択のコスト、および処理の切り替えのコストがその都度発生してしまう。すなわち、特許文献１の技術では、優先度の高いＶＭＭの共通処理がタイムシェアリングで中断されるので、ＶＭの処理とＶＭＭの共通処理とを切り替えるためのコストや、ＶＭＭの共通処理を次の物理ＣＰＵに引き継ぐためのコストが発生し、性能面で必ずしも有効な技術とはいえない。

本発明は、上記課題に鑑みなされたものであり、その目的は、複数の物理ＣＰＵがＲＵＮ状態にある状況において、ＶＭＭの共通処理がこれら物理ＣＰＵのリソースを使用する時間の均等性を保障しつつ、ＶＭの処理とＶＭＭの共通処理との切り替えのコストを抑えることのできる技術を提供することにある。

計算機は、複数の物理ＣＰＵと、複数の物理ＣＰＵのいずれかが割り当てられ、所定の処理を実行する複数の仮想計算機と、複数の仮想計算機を管理する仮想計算機制御部とを有し、複数の仮想計算機から必要とされる共通処理を、仮想計算機制御部によって複数の物理ＣＰＵに実行させることができる。

仮想計算機制御部は、（Ａ）仮想計算機の処理が実行状態である物理ＣＰＵで、共通処理を実行させる場合に、物理ＣＰＵで共通処理を実行した実行時間を測定し、物理ＣＰＵ毎に、実行時間を累積した累積実行時間を管理し、（Ｂ）（Ａ）以降に、共通処理を実行させる場合において、累積実行時間が最小である物理ＣＰＵを、共通処理を実行する物理ＣＰＵとして選択する。

複数の物理ＣＰＵがＲＵＮ状態にある状況において、ＶＭの処理よりも優先度の高いＶＭＭの共通処理が、少ないコストで、複数の物理ＣＰＵで均等に実行される。これにより、物理ＣＰＵに割り当てられたＶＭの処理が長時間走行できなくなることを防ぐことができ、ＶＭＭの処理に関わる余分なコストを削減できる。

図１は、実施形態に係る計算機の構成図である。 図２は、実施形態に係るプロセス制御ブロックの構成図である。 図３は、実施形態に係るスケジューリング制御テーブルの構成図である。 図４は、実施形態に係るプロセススケジューリングのＣＰＵ占有モードを説明する図である。 図５は、実施形態に係るプロセススケジューリングのＣＰＵ共有モードを説明する図である。 図６は、実施形態に係るＶＭプロセスのＶＭＭ内部処理を表すフローチャートである。 図７は、実施形態に係るイベント通知処理を表すフローチャートである。 図８は、実施形態に係るイベント通知先ＶＭＭプロセスの処理を表すフローチャートである。 図９は、ＶＭＭプロセスのスケジューリング動作を表した概念図である。

本発明の実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

なお、以下の説明では、「ａａａテーブル」、「ａａａブロック」の表現にて各種情報を説明することがあるが、各種情報は、テーブル、ブロック以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａブロック」を「ａａａ情報」と呼ぶことができる。

また、以後の説明では、プログラム（又はその一部の機能部）を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えば物理ＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）、や通信制御装置（例えばポート）を用いながら行うため、処理の主語がプロセッサとされても良い。また、プログラムを主語として説明された処理は、プロセッサ或いはそのプロセッサを有するデバイス（例えば、計算機等）が行う処理としても良い。また、プログラムの一部又は全ては専用ハードウェアによって実現されても良い。また、コンピュータプログラムは、プログラムソースから各デバイスにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。

まず、実施形態の概要について説明する。

実施形態においては、ＶＭＭの共通処理を走行させるための物理ＣＰＵのスケジューリング（選択）方法として、ＲＵＮ状態の物理ＣＰＵで走行した回数ではなく、ＲＵＮ状態の物理ＣＰＵで走行した累積の走行時間（累積奪い取り走行時間）を使用する。これにより、複数の物理ＣＰＵがＲＵＮ状態にある計算機において、ＶＭの処理よりも優先度の高いＶＭＭの共通処理が、少ないコストで、複数の物理ＣＰＵで均等に実行される。これにより、物理ＣＰＵに割り当てられたＶＭの処理が長時間走行できなくなることを防ぐことができ、ＶＭＭの処理に関わるコストを削減できる。

次に、更なる課題について図９（ｂ１）を用いて説明する。

図９（ｂ１）は、図９（ａ１）に示すスケジューリング動作に対して、物理ＣＰＵの選択、および処理の切り替えのコストを抑えるために、タイムシェアリング方式を用いない場合におけるスケジューリング動作を示している。なお、ＶＭＭの共通処理が物理ＣＰＵのリソースを使用する時間の均等性の確保するために、ＶＭＭの共通処理がＲＵＮ状態の物理ＣＰＵで走行した累積時間（累積奪い取り走行時間）が最も小さい物理ＣＰＵを、ＶＭＭの共通処理を実行する物理ＣＰＵとして選択するものとする。

イベント通知９００（要求１）に対するＶＭＭの共通処理は、物理ＣＰＵ０で実行が開始され、処理が終了するまで継続して実行される。イベント通知９０１（要求２）に対するＶＭＭの共通処理は、物理ＣＰＵ１で実行が開始され、処理が終了するまで継続して実行される。イベント通知９０２（要求３）に対するＶＭＭの共通処理は、物理ＣＰＵ２で実行が開始され、処理が終了するまで継続して実行される。イベント通知９０３（要求４）に対するＶＭＭの共通処理は、ＶＭＭの共通処理がＲＵＮ状態の物理ＣＰＵで走行した累積時間が最も小さい物理ＣＰＵ０で実行が開始され、共通処理が終了するまで継続して実行される。

ここで、ＶＭがイベント通知９０４（要求５）を発行すべきタイミングにおいて、物理ＣＰＵ０では要求４に対するＶＭＭの共通処理が実行中であるという状態が発生し得る。このとき、イベント通知９０４はＶＭが物理ＣＰＵ０で再び走行するタイミングまで発行が遅れてしまい、結果的にイベントが処理されるまでの時間も間延びしてしまう。すなわち、ＶＭＭの共通処理がＶＭの処理のイベント通知を受けて起動する場合、ＶＭＭの共通処理がＶＭの処理を妨げることで、次のＶＭＭの共通処理の要求の起動が遅れてしまい、性能の低下を招くこととなる。

そこで、本実施形態では、ＶＭＭの共通処理に対して、シリアル属性又はパラレル属性をそれぞれに付与し、属性によってＶＭＭの共通処理を走行させるための物理ＣＰＵ選択方法を変更するようにする。ここで、シリアル属性とは、通知元プロセスから一度のみイベント通知が発行されるＶＭＭの共通処理や、定期的にタイマで起動されるＶＭＭの共通処理であることを示し、パラレル属性とは、ＶＭから連続してイベント通知が発行されるＶＭＭの共通処理であることを示す。本実施形態では、パラレル属性のＶＭＭの共通処理については、イベント通知を行うＶＭを実行する物理ＣＰＵと異なる物理ＣＰＵを当該共通処理を実行する物理ＣＰＵとして選択する。これにより、ＶＭからのイベント通知を連続的に受けて起動されるＶＭＭの共通処理について、複数の物理ＣＰＵでイベント通知と、ＶＭＭの共通処理とをパラレルに実行することができ、イベント通知の発行および共通処理の起動に遅れが生じないようにでき、性能の向上を図ることができる。

図１は、実施形態に係る計算機の構成図である。

計算機（物理計算機）４００は、ハードウェア資源として、複数の物理ＣＰＵ４１０〜４１３、メモリ４２０、Ｉ／Ｏデバイス４３０、及び外部記憶ディスク４４０を有する。物理ＣＰＵ４１０〜４１３は、各種処理を実行する。メモリ４２０は、物理ＣＰＵ４１０〜４１３に実行される各種プログラムや、各種プログラムの実行に使用されるデータを記憶する。メモリ４２０は、例えば、ＶＭＭ３００を記憶する。Ｉ／Ｏデバイス４３０は、情報を入力するためのキーボード、マウス等の入力デバイスと、各種情報を出力するためのディスプレイ等の出力デバイスとを含む。外部記憶ディスク４４０は、各種データを記憶する。

ＶＭＭ３００は、計算機４００上で動作する、すなわち、物理ＣＰＵ４１０〜４１３により実行されるソフトウェアである。ＶＭＭ３００は、物理計算機４００のハードウェア資源を論理的に分割してＶＭ１００、２００を構築し、それらを管理・制御する機能をもつ。ＶＭＭ３００は、主に命令エミュレーション部３１０、メモリ管理部３２０、Ｉ／Ｏ制御部３３０、プロセススケジューリング制御部３４０といった機能部を有する。これらの機能部を物理ＣＰＵ４１０〜４１３が実行することによって、論理ＣＰＵ１２０、１２１、２２０、２２１、ＶＭ用の論理メモリ１３０、２３０、論理Ｉ／Ｏデバイス１４０、１４１等のＶＭ１００、２００の構成要素が構築される。これにより、各ＶＭ１００、２００上でゲストＯＳ１１０、２１０が動作できる。ＶＭＭ３００は、いわゆる仮想化機構である。

ここで、物理ＣＰＵの論理的な分割とは、一つもしくは複数の物理ＣＰＵを、複数の論理ＣＰＵで共有し、その複数の論理ＣＰＵ間で共有する物理ＣＰＵの使用を切り替えることである。

ＶＭＭ３００は、各論理ＣＰＵ１２０、１２１、２２０、２２１、およびＶＭＭ３００の共通処理をそれぞれ一つのプロセスとして扱い、このプロセス単位で、当該プロセスに物理ＣＰＵを割り当てるスケジューリングを行う。ここで、プロセスとは、物理ＣＰＵがプログラムを実行する処理単位である。このプロセスのスケジューリングを実現するために、ＶＭＭ３００のプロセススケジューリング制御部３４０は、プロセスごとにプロセス制御ブロック３５０、３５１、・・・を有するとともに、物理ＣＰＵごとに、スケジューリング制御テーブル３６０、３６１、・・・を有する。プロセス制御ブロック３５０、３５１、・・・及びスケジューリング制御テーブル３６０、３６１、・・・は、メモリ４２０におけるＶＭＭ用に確保されている領域に格納される。プロセススケジューリング処理部３７０は、これらのプロセス制御ブロック及びプロセススケジューリング制御テーブルを用いてプロセスのスケジューリングを制御する。

図２は、実施形態に係るプロセス制御ブロックの構成図である。

プロセス制御ブロック３５０、３５１、・・・は、それぞれ、プログラムを実行する処理単位であるプロセスに対応し、プロセスを具現化するデータ構造である。プロセスは、プログラムの実行に対して、アドレス空間と物理ＣＰＵとを提供する。プロセスには、仮想計算機のプログラムを実行し、ＶＭの仮想的なＣＰＵを具体化する論理ＣＰＵプロセス（３５０〜３５３）と、ＶＭＭ３００の共通処理を行うＶＭＭプロセス（３５４〜３５６）とがある（図４及び図５参照）。

ここでは、プロセス制御ブロック３５０について説明するが、他のプロセス制御ブロック３５１等も同様な構成である。プロセス制御ブロック３５０は、プロセス識別情報３５０−１と、ＶＭＭイベント通知フラグ３５０−２と、動作状態３５０−３と、ＩＤＬＥスケジュールフラグ３５０−４と、走行開始時刻３５０−５と、１以上の累積奪い取り走行時間３５０−６−０、３５０−６−１、・・・とのフィールドを含む。累積奪い取り走行時間３５０−６−０、３５０−６−１、・・・は、物理ＣＰＵ毎に用意される。

プロセス識別情報３５０−１は、プロセスの種別を表す。プロセスの種別とは、大きくは、ＶＭの論理ＣＰＵプロセスであるか、ＶＭＭ３００の共通処理を行うＶＭＭプロセスであるかを示す種別である。ＶＭＭプロセスについては、更に、そのプロセスの動作の属性によって、シリアル属性と、パラレル属性とのいずれかの種別に分類される。

シリアル属性とパラレル属性とは、イベント通知に対し、このＶＭＭプロセスが、通知元プロセスを実行する物理ＣＰＵとは別の物理ＣＰＵで同時に（並行して）走行する動作となるか否かを示す属性である。シリアル属性は、通知元プロセスから一度のみイベント通知が発行されるプロセスや、通知元プロセスが存在せずに、定期的にタイマで起動されるプロセスが該当する属性である。パラレル属性は、通知元プロセスから連続してイベント通知が発行されるプロセスが該当する属性である。例えば、ＶＭの論理ＣＰＵプロセスがＶＧＡ描画のＩ／Ｏ命令を受けて、物理ＶＧＡ描画処理を行うＶＭＭプロセスに対して描画処理のイベント通知を発行する場合における、当該ＶＭＭプロセスがパラレル属性に該当する。

ＶＭＭイベント通知フラグ３５０−２は、ＶＭＭプロセスに対して、ＶＭＭ処理要求のイベント通知がされたか否かを表す。

動作状態３５０−３は、プロセス制御ブロック３５０に対応するプロセスが、いずれかの物理ＣＰＵ上で実行中であるか否かを表す。動作状態３５０−３は、プロセスがいずれかの物理ＣＰＵ上で実行中である、すなわち、プロセスがＲＵＮ状態である場合には、ＲＵＮとなり、いずれの物理ＣＰＵでも実行中でない場合には、ＩＤＬＥとなる。

ＩＤＬＥスケジュールフラグ３５０−４は、プロセス制御ブロック３５０に対応するプロセスがＩＤＬＥ状態の物理ＣＰＵにスケジュール（割り当て）されたか否かを表す。

走行開始時刻３５０−５は、プロセス制御ブロック３５０に対応するプロセスがスケジュールされて、その物理ＣＰＵで走行を開始した時刻を表す。この走行開始時刻３５０−５は、後述するように、プロセスの走行時間を算出する目的で使用される。

累積奪い取り走行時間３５０−６−０、３５０−６−１は、物理ＣＰＵごとに対するデータであり、プロセスがＲＵＮ状態の物理ＣＰＵを奪って走行した場合における、走行の開始から終了までの走行時間を、所定の時点から累積したものである。これら累積奪い取り走行時間３５０−６−０、３５０−６−１を参照することにより、物理ＣＰＵ毎の当該プロセスがＲＵＮ状態の物理ＣＰＵを奪って走行した累積奪い取り走行時間を把握することができる。

図３は、実施形態に係るスケジューリング制御テーブルの構成図である。

スケジューリング制御テーブル３６０、３６１、・・・は、物理ＣＰＵごとに設けられ、物理ＣＰＵのスケジュールに関する情報を記憶する。ここでは、スケジューリング制御テーブル３６０について説明するが、他のスケジューリング制御テーブル３６１等も同様な構成である。

スケジューリングモード３６０−１は、ＶＭの論理ＣＰＵプロセスを物理ＣＰＵに対してスケジュールするためのモードを表す。モードとしては、後述するＣＰＵ占有モードと、ＣＰＵ共有モードとがある。

動作状態３６０−２は、物理ＣＰＵ上でプロセスが実行中か否かを表す。物理ＣＰＵがプロセスを実行中である場合には、ＲＵＮとなり、物理ＣＰＵがプロセスを実行中でない場合には、ＩＤＬＥとなる。スケジューリング要求フラグ３６０−３は、物理ＣＰＵに対して、プロセスを切り替えるための要求がセットされているか否かを表す。

次に、ＣＰＵ占有モードと、ＣＰＵ共有モードとを説明する。

図４は、実施形態に係るプロセススケジューリングのＣＰＵ占有モードを説明する図である。図５は、実施形態に係るプロセススケジューリングのＣＰＵ共有モードを説明する図である。

図４及び図５の説明において、ＶＭ１の論理ＣＰＵ１２０、１２１に対応するプロセス３５０及び３５１は、ＣＰＵ占有モードでスケジュールされるように設定され、ＶＭ２の論理ＣＰＵ２２０、２２１に対応するプロセス３５２及び３５３は、ＣＰＵ共有モードでスケジュールされるように設定されている。

ＣＰＵ占有モードでスケジュールを行う場合には、論理ＣＰＵプロセスが、特定の一つの物理ＣＰＵに占有的にスケジュールされる。具体的には、図４に示すように、ＣＰＵ占有モードのＶＭ１の論理ＣＰＵプロセス３５０、３５１は、それぞれ物理ＣＰＵ４１０、４１１に占有的にスケジュールされる。ただし、ＣＰＵ占有モードでスケジュールされる場合であっても、ＶＭＭの共通処理を行うＶＭＭプロセス３５４〜３５６は、物理ＣＰＵの占有状態に関係なく、論理ＣＰＵプロセスより優先的に物理ＣＰＵ４１０、４１１にスケジュールされる。

一方、ＣＰＵ共有モードでスケジュールを行う場合には、論理ＣＰＵプロセスは、ＣＰＵ占有モードの論理ＣＰＵが排他的に使用する物理ＣＰＵを除く、物理ＣＰＵのうちのいずれか一つの物理ＣＰＵにスケジュールされる。ここで、図５においては、物理ＣＰＵ４１０、４１１がＣＰＵ占有モードで使用され、物理ＣＰＵ４１２、４１３がＣＰＵ共有モードとして使用されている。したがって、ＣＰＵ共有モードのＶＭ２の論理ＣＰＵプロセス３５２、３５３は、物理ＣＰＵ４１２、４１３に動的にスケジュールされる。なお、ＣＰＵ占有モードの場合と同じく、ＶＭＭの共通処理を行うＶＭＭプロセス３５４〜３５６は、論理ＣＰＵプロセスより優先的に物理ＣＰＵにスケジュールされる。

次に、実施形態に係る計算機の処理動作について説明する。

図６は、実施形態に係るＶＭプロセスのＶＭＭ内部処理を表すフローチャートである。

ＶＭ（１００又は２００）の論理ＣＰＵ上のゲストＯＳが、ハードウェアリソースを制御するような特権命令を発行した場合、物理ＣＰＵ（４１０〜４１３のいずれか）の仮想化支援機構により、ＶＭＭ３００に制御が移る（ＶＭ−Ｅｘｉｔ）（ステップ５００）。

ＶＭＭ３００の命令エミュレーション部３１０は、ＶＭ−Ｅｘｉｔの要因を解析し（ステップ５１０）、その要因に対応する処理を実行する（ステップ５２０、５３０〜５３２）。要因に対応する処理とは、例えば、要因が論理ＣＰＵの動作を休止するＨＡＬＴ命令である場合（ＨＡＬＴ命令）には、プロセススケジューリング処理部３７０が、プロセス切り替え処理を呼び出すことで、論理ＣＰＵプロセスのＲＵＮ状態を解除する（ステップ５３０）。また、例えば、要因がＶＧＡ描画のＩ／Ｏ命令である場合（ＶＧＡ描画Ｉ／Ｏ命令）には、命令エミュレーション部３１０が物理ＶＧＡ描画処理を行うＶＭＭプロセスに対して描画処理のイベント通知を発行する（ステップ５３１）。

ＶＭ−Ｅｘｉｔ要因に対応する処理を終えると、プロセススケジューリング処理部３７０は、論理ＣＰＵプロセスが走行中の物理ＣＰＵに対して、スケジューリング制御テーブル３６０、３６１等のスケジューリング要求フラグ（３６０−３等）がオンであるか否かを確認し（ステップ５４０）、スケジューリング要求フラグ（３６０−３等）がオンである場合（ステップ５４０でＹ）には、スケジューリング要求フラグをクリアにして（ステップ５５０）、プロセス切り替え処理を呼び出し（ステップ５６０）、処理をステップ５７０に進める。一方、スケジューリング要求フラグがオフである場合（ステップ５４０でＮ）は、プロセススケジューリング処理部３７０は、何もせずに、処理をステップＳ５７０に進める。ここで、スケジューリング要求フラグがオンとなるのは、例えば、イベント通知処理（図７参照）のステップ６６０で、ＶＭＭプロセスを動作させる物理ＣＰＵとして選択された場合である。

ステップ５７０では、ＶＭＭ３００が、ＶＭに制御を移す（ＶＭ−Ｅｎｔｒｙ）。

図７は、実施形態に係るイベント通知処理を表すフローチャートである。図７はＶＭＭ共通処理に対するイベント通知を発行するプロセスにおけるイベント通知処理を表している。例えば、図６のステップ５３１における物理ＶＧＡの描画処理のイベント通知を発行する処理がこのイベント通知処理に該当する。

プロセススケジューリング処理部３７０は、イベント通知先のＶＭＭプロセス（ＶＭＭの共通処理のプロセス）に対応するアクセス制御ブロック３５０の動作状態３５０−３を参照し、動作状態３５０−３がＲＵＮ状態であるか否かを判定する（ステップ６１０）。この結果、動作状態３５０−３がＲＵＮ状態である場合（ステップ６１０でＹ）には、現在いずれかの物理ＣＰＵでＶＭＭプロセスが走行中であるので、引き続きその物理ＣＰＵ上で、イベント通知先のＶＶＭプロセスの動作を継続できるように、イベント通知先のＶＭＭプロセスに対応するアクセス制御ブロック３５０のＶＭＭイベント通知フラグ３５０−２をオンにセットし（ステップ６７０）、イベント通知処理を終了する。

一方、動作状態３５０−３がＲＵＮ状態でなかった場合（ステップ６１０でＮ）には、プロセススケジューリング処理部３７０は、イベント通知先のＶＭＭプロセスを走行させる物理ＣＰＵを選択する処理に移行する。すなわち、プロセススケジューリング処理部３７０は、全ての物理ＣＰＵのスケジューリング制御テーブル３６０、３６１、・・・から、スケジューリングモード（３６０−１等）と、動作状態（３６０−２等）とを参照し、動作状態がＩＤＬＥ状態であり、且つ、ＣＰＵ共有モードである物理ＣＰＵがあるか否かを判定する（ステップ６２０）。

この判定の結果、ＩＤＬＥ状態であり、且つＣＰＵ共有モードである物理ＣＰＵがある場合（ステップ６２０でＹ）には、プロセススケジューリング処理部３７０は、イベント通知先のＶＭＭプロセスを走行させる物理ＣＰＵとして、ＩＤＬＥ状態であり、且つＣＰＵ共有モードの物理ＣＰＵの中から１つの物理ＣＰＵを選択し（ステップ６２１）、処理をステップ６６０に進める。

一方、ＩＤＬＥ状態であり、且つＣＰＵ共有モードである物理ＣＰＵがない場合（ステップ６２０でＮ）には、プロセススケジューリング処理部３７０は、ＩＤＬＥ状態であり、且つＣＰＵ占有モードである物理ＣＰＵがあるか否かを判定する（ステップ６３０）。

この判定の結果、ＩＤＬＥ状態であり、且つＣＰＵ占有モードの物理ＣＰＵがある場合（ステップ６３０でＹ）には、プロセススケジューリング処理部３７０は、イベント通知先のＶＭＭプロセスを走行させる物理ＣＰＵとして、ＩＤＬＥ状態であり、且つＣＰＵ占有モードの物理ＣＰＵの中から１つの物理ＣＰＵを選択し（ステップ６３１）、処理をステップ６６０に進める。

ここで、ＣＰＵ占有モードの物理ＣＰＵよりもＣＰＵ共有モードの物理ＣＰＵを、ＶＭＭプロセスを走行させる物理ＣＰＵとして優先して選択するのは、占有モードの物理ＣＰＵ上でイベント通知先のＶＭＭプロセスが走行することで、その物理ＣＰＵに占有的に割り付けられたＶＭの走行が妨げられないようにするためである。

一方、ＩＤＬＥ状態であり、且つＣＰＵ占有モードの物理ＣＰＵがない場合、すなわち、ＩＤＬＥ状態の物理ＣＰＵがない場合（ステップ６３０でＮ）には、ＲＵＮ状態の物理ＣＰＵのいずれかからＶＭＭプロセスを走行させる物理ＣＰＵを選択する必要があるので、プロセススケジューリング処理部３７０は、イベント通知先のＶＭＭプロセスに対応するプロセス制御ブロック（３５０等）のプロセス識別情報（３５０−１等）を参照し、プロセス識別情報がシリアル属性であるか否かを判定する（ステップ６４０）。

この結果、プロセス識別情報がシリアル属性の場合（ステップ６４０でＹ）には、イベント通知が連続して発生する可能性がなく、あえて他の物理ＣＰＵにＶＭＭの共通処理を依頼する必要はないので、プロセススケジューリング処理部３７０は、ＶＭＭプロセスにイベント通知を発行せずに、要求元プロセスがＶＭＭの共通処理を実行するようにし（ステップ６４１）、処理を終了する（ステップ６４２）。これにより、ＶＭＭの共通処理を他の物理ＣＰＵに実行させることにより発生するプロセス切り替えのコストを削減できる。

一方、プロセス識別情報がパラレル属性の場合（ステップ６４０でＮ）には、プロセススケジューリング処理部３７０は、イベント通知先のＶＭＭプロセスに対応するプロセス制御ブロック（３５０等）の各物理ＣＰＵに対する累積奪い取り走行時間（例えば、３５０−６−０、３５０−６−１等）を参照し、イベント通知先のＶＭＭプロセスを走行させる物理ＣＰＵとして、累積奪い取り走行時間が最小である物理ＣＰＵを選択し（ステップ６５０）、処理をステップ６６０に進める。

ステップ６６０では、ここまでにＶＭＭプロセスを走行させる物理ＣＰＵを選択しているので、プロセススケジューリング処理部３７０は、選択した物理ＣＰＵに対応するスケジューリング制御テーブル（３６０、３６１・・・のいずれか）のスケジューリング要求フラグ（３６０−３等）をオンにセットする。これにより、図６のステップ５６０で、プロセス切り替え処理が呼び出されることとなり、ＶＭＭプロセスが選択された物理ＣＰＵで走行を開始することとなる。

次いで、プロセススケジューリング処理部３７０は、イベント通知先のＶＭＭプロセスに対応するプロセス制御ブロック（３５０等）のＶＭＭイベント通知フラグ（３５０−２等）をオンにセットし（ステップ６７０）、イベント通知処理を終了する（ステップ６８０）。

図８は、実施形態に係るイベント通知先ＶＭＭプロセスにおける処理を表すフローチャートである。

図６のステップ５３０、ステップ５６０におけるプロセス切り替え処理の呼び出しによって、ＶＭＭプロセスが選択されて物理ＣＰＵで走行を開始する（７００）と、プロセススケジューリング処理部３７０は、ＶＭＭプロセスに対応するプロセス制御ブロック（３５０等、以下、この処理では、３５０であるとして説明する）の走行開始時刻３５０−５に、その時点の現在時刻をセットする（ステップ７１０）。

次いで、プロセススケジューリング処理部３７０は、ＶＭＭプロセスが走行を開始した物理ＣＰＵのスケジューリング制御テーブル（３６０、３６１、・・のいずれか）の動作状態（３６０−２）を参照して、動作状態がＩＤＬＥ状態であるか否かを判定し（ステップ７２０）、この判定の結果、動作状態がＩＤＬＥ状態である場合（ステップ７２０でＹ）には、ＶＭＭプロセスに対応するプロセス制御ブロック３５０のＩＤＬＥスケジュールフラグ３５０−４をオンにセットする（ステップ７２１）、一方、動作状態がＩＤＬＥ状態でない場合（ステップ７２０でＮ）には、プロセス制御ブロック３５０のＩＤＬＥスケジュールフラグ３５０−４をクリアする（ステップ７２２）。

次に、ＶＭＭプロセスは、自身のプロセス制御ブロック３５０のＶＭＭイベント通知フラグ３５０−２がオンにセットされているか否かを判定し（ステップ７３０）、判定の結果、ＶＭＭイベント通知フラグ３５０−２がオンにセットされている場合（ステップ７３０でＹ）には、ＶＭＭイベント通知フラグ３５０−２をクリアして（ステップ７３１）、イベントに対応する処理を実行し（ステップ７３２）、ステップ７３０に処理を進める。ここで、ＶＭＭプロセスがパラレル属性である場合に、イベントに対応する処理を実行している間に、図７のステップ６６０の処理が実行されて、自身のプロセス制御ブロック３５０のＶＭＭイベント通知フラグ３５０−２が再びオンにセットされることがある。したがって、ＶＭＭプロセスは、ステップ７３０の判定の結果、ＶＭＭイベント通知フラグ３５０−２がオンにセットされている場合には、ステップ７３１、７３２を繰り返し実行することとなる。

一方、ステップ７３０の判定の結果、ＶＭＭイベント通知フラグ３５０−２がオンにセットされていない場合（ステップ７３０でＮ）には、プロセススケジューリング処理部３７０は、ＶＭＭプロセスのプロセス制御ブロック３５０の走行開始時刻３５０−５と、現在時刻とから、ＶＭＭプロセスの走行時間を算出する（ステップ７４０）。

次いで、プロセススケジューリング処理部３７０は、ＶＭＭプロセスのプロセス制御ブロック３５０のＩＤＬＥスケジュールフラグ３５０−４を参照し、ＩＤＬＥスケジュールフラグ３５０−４がオンであるか否かを判定し（ステップ７５０）、ＩＤＬＥスケジュールフラグ３５０−４がオンの場合（ステップ７５０でＹ）には、ＶＭＭプロセスがＲＵＮ状態であった物理ＣＰＵで走行していないので、そのまま処理を終える（ステップ７７０）。一方、ＩＤＬＥスケジュールフラグ３５０−４がオフの場合（ステップ７５０でＮ）には、ＶＭＭプロセスがＲＵＮ状態であった物理ＣＰＵで走行したとして、ステップ７４０で算出した走行時間を、走行した物理ＣＰＵに対応する累積奪い取り走行時間（３５０−６−０、３５０−６−１、・・のいずれか）に加算し（ステップ７６０）、処理を終える（ステップ７７０）。これにより、ＶＭＭプロセスがＲＵＮ状態であった物理ＣＰＵで走行した場合における走行時間を適切に累積奪い取り走行時間に加算することができる。

次に、本実施形態による効果を、図９を参照して説明する。

図９（ａ２）は、図９（ａ１）と同様にイベント要求が発生する場合において、本実施形態による、ＶＭＭの共通処理がＲＵＮ状態の物理ＣＰＵで走行した累積奪い取り走行時間に基づいて物理ＣＰＵを選択するスケジューリング動作を行った場合の例を示す。また、図９（ｂ２）は、図９（ｂ１）と同じイベント要求が発生する場合において、本実施形態による、ＶＭＭの共通処理の属性を利用して、ＶＭＭの共通処理が走行する物理ＣＰＵを選択するスケジューリング動作を行った場合の例を示す。

図９（ａ１）に示した、タイムシェアリング方式とＶＭＭの共通処理がＲＵＮ状態の物理ＣＰＵで走行した回数情報を使用したスケジューリング動作では、物理ＣＰＵリソースを使用する時間の均等性は確保されるが、ＶＭの処理とＶＭＭの共通処理を切り替えるためのコストと、ＶＭＭの共通処理を次の物理ＣＰＵに引き継ぐためのコストが発生することを既に述べた。

これに対して、本実施形態に係るスケジューリング動作は、図９（ａ２）に示すようになる。

すなわち、イベント通知８１０（要求１）に対するＶＭＭの共通処理は、物理ＣＰＵ０で実行され、共通処理が終了するまで継続して実行される。また、イベント通知８１１（要求２）に対するＶＭＭの共通処理は、累積奪い取り走行時間が最も小さい物理ＣＰＵで走行を開始するので、物理ＣＰＵ１で実行が開始され、共通処理が終了するまで継続して実行される。また、また、イベント通知８１２（要求３）に対するＶＭＭの共通処理は、累積奪い取り走行時間が最も小さい物理ＣＰＵで走行を開始するので、物理ＣＰＵ２で実行が開始され、共通処理が終了するまで継続して実行される。また、また、イベント通知８１３（要求４）に対するＶＭＭの共通処理は、累積奪い取り走行時間が最も少ない物理ＣＰＵで走行を開始するので、物理ＣＰＵ０で実行が開始され、共通処理が終了するまで継続して実行される。また、イベント通知８１４（要求５）に対するＶＭＭの共通処理は、累積奪い取り走行時間が最も少ない物理ＣＰＵで走行を開始するので、物理ＣＰＵ２で実行が開始され、共通処理が終了するまで継続して実行される。

このように、本実施形態に係るスケジューリング動作によると、イベント通知８１０〜８１４を受けたＶＭＭの共通処理は、累積奪い取り走行時間が最も少ない物理ＣＰＵで走行を開始し、処理が完了するまで走行を継続する。これにより図９（ａ１）で問題となるコストが削減される。なお、図９（ａ１）及び図９（ａ２）を比較すると、図９（ａ１）に示すスケジューリング動作の方が、物理ＣＰＵのリソースを使用する時間の均等性の観点では優れているように見えるが、これは、これら図が短い時間範囲しか示していないためであり、より長い時間範囲でみると、図９（ａ２）のスケジューリング動作によっても、図９（ａ１）と同等の効果を有する。

図９（ｂ１）に示した、スケジューリング動作では、ＶＭがイベント通知９０４を発行するタイミングで、物理ＣＰＵ０でＶＭＭの共通処理が実行中であるために、イベント通知の発行と、処理とが遅れてしまう状況が発生することを既に述べた。

これに対して、本実施形態に係るスケジューリング動作は、図９（ｂ２）に示すようになる。

ここで、本実施形態では、イベント通知９１０〜９１２で要求されるＶＭＭの共通処理のプロセスに対しては、シリアル属性が付加され、イベント通知９１３〜９１５で要求されるＶＭＭの共通処理のプロセスに対しては、イベント通知が連続して発生するのでパラレル属性が付加されて管理される。

イベント通知９１０（要求１）に対するＶＭＭの共通処理は、シリアル属性を持っているので、物理ＣＰＵ０で実行され、共通処理が終了するまで継続して実行される。また、イベント通知９１１（要求２）に対するＶＭＭの共通処理は、シリアル属性を持っているので、物理ＣＰＵを変更することなく、実行され、共通処理が終了するまで継続して実行される。また、イベント通知９１２（要求３）に対するＶＭＭの共通処理は、シリアル属性を持っているので、物理ＣＰＵを変更することなく、実行され、共通処理が終了するまで継続して実行される。

その後、イベント通知９１３（要求４）に対するＶＭＭの共通処理は、パラレル属性を持っているので、累積奪い取り走行時間が最も小さい物理ＣＰＵで走行を開始するので、物理ＣＰＵ１で実行が開始され、共通処理が終了するまで継続して実行される。ここで、イベント通知９１４（要求５）を発行する物理ＣＰＵ０は、ＶＭＭの共通処理を実行していないので、イベント通知９１４を遅滞なく発行することができる。イベント通知９１４（要求５）に対するＶＭＭの共通処理は、その時点において物理ＣＰＵ１で要求４に対応するＶＭＭの共通処理が走行中であるので、要求４に対応する共通処理が終了した後、引き続きその物理ＣＰＵ１上で走行を開始することとなる。さらに、イベント通知９１５（要求６）を発行する物理ＣＰＵ０は、ＶＭＭの共通処理を実行していないので、イベント通知９１５を遅滞なく発行することができる。イベント通知９１５（要求６）に対するＶＭＭの共通処理は、その時点において、物理ＣＰＵ１で要求５に対応するＶＭＭの共通処理が走行中であるので、要求５に対応する共通処理が終了した後、引き続きその物理ＣＰＵ１上で走行を開始することとなる。

このように、本実施形態に係るスケジューリング動作によると、イベント通知９１３〜９１５のようにパラレル属性を持ったＶＭＭ共通処理に対しては、必ずイベント通知元とは別の物理ＣＰＵが選択され、イベントの発行とイベントに対する処理との並列実行が可能となる。また、イベント通知９１０〜９１２のようなシリアル属性を持ったＶＭＭの共通処理に対しては、イベント通知元の物理ＣＰＵで処理が行われるので、ＶＭの処理とＶＭＭ共通処理との切り替えのコストを削減することができる。

上記した実施形態によると、ＶＭＭの共通処理に関わるコストを削減することができる。特にネットワークやＶＧＡなどのＶＭからのイベント通知を受けて起動し、パラレルで実行されるＶＭＭの共通処理に対して、物理ＣＰＵのリソースの効率的な運用による性能の向上が期待でき、計算機の適応範囲の拡大が可能となる。

以上、実施形態を説明したが、本発明は、これらの実施形態に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

１００,２００ 仮想計算機（ＶＭ）、１１０，２１０ ゲストオペレーティングシステム（ＯＳ）、１２０，１２１，２２０，２２１ 論理ＣＰＵ、１３０，２３０ 論理メモリ、１４０，１４１ 論理Ｉ／Ｏデバイス、３００ 仮想マシンモニタ（ＶＭＭ）、３１０ 命令エミュレーション部、３２０ メモリ管理部、３３０ Ｉ／Ｏ制御部、３４０ プロセススケジューリング制御部、３５０，３５１ プロセス制御ブロック、３６０，３６１ スケジューリング制御テーブル、３７０ プロセススケジューリング処理部、４００ 物理計算機、４１０〜４１３ 物理ＣＰＵ、４２０ 物理メモリ、４３０ 物理Ｉ／Ｏデバイス、４４０ 外部記憶ディスク。

Claims (15)

1. 複数の物理ＣＰＵと、前記複数の物理ＣＰＵのいずれかが割り当てられ、所定の処理を実行する複数の仮想計算機と、前記複数の仮想計算機を管理する仮想計算機制御部とを有し、複数の前記仮想計算機から必要とされる共通処理を、前記仮想計算機制御部によって前記複数の物理ＣＰＵに実行させることができる、計算機であって、
   前記仮想計算機制御部は、
   （Ａ）前記仮想計算機の処理が実行状態である前記物理ＣＰＵで、前記共通処理を実行させる場合に、前記物理ＣＰＵで前記共通処理を実行した実行時間を測定し、前記物理ＣＰＵ毎に、前記実行時間を累積した累積実行時間を管理し、
   （Ｂ）前記（Ａ）以降に、前記共通処理を実行させる場合において、前記累積実行時間が最小である物理ＣＰＵを、前記共通処理を実行する物理ＣＰＵとして選択する
   計算機。
2. 前記仮想計算機制御部は、
   前記共通処理に対して、前記共通処理が前記仮想計算機の処理から連続して要求される処理であるか、連続して要求されない処理であるかを示す識別情報を対応付けて管理し、
   （Ｃ）前記共通処理を実行させる場合において、前記共通処理に対応付けられた前記識別情報が、前記共通処理が前記仮想計算機の処理から連続して要求される処理であることを示している場合に、前記（Ｂ）を行う
   請求項１に記載の計算機。
3. 前記仮想計算機制御部は、
   （Ｄ）前記共通処理を実行させる場合において、前記共通処理に対応付けられた前記識別情報が、前記共通処理が前記仮想計算機の処理から連続して要求されない処理であることを示している場合に、前記共通処理を要求した前記仮想計算機の処理を実行している物理ＣＰＵを、前記共通処理を実行する物理ＣＰＵとして選択する
   請求項２に記載の計算機。
4. 前記仮想計算機制御部は、
   前記共通処理を実行させる場合において、前記共通処理がいずれかの物理ＣＰＵで実行中ではなく、且つ前記仮想計算機の処理を実行していない物理ＣＰＵが存在しない場合に、前記共通処理の前記識別情報に基づいて、前記（Ｃ）又は前記（Ｄ）を実行する
   請求項３に記載の計算機。
5. 前記仮想計算機制御部は、
   前記共通処理を実行する物理ＣＰＵとして選択した前記物理ＣＰＵに、前記共通処理を実行させる
   請求項４に記載の計算機。
6. 前記仮想計算機制御部は、
   前記共通処理を実行する物理ＣＰＵとして選択した前記物理ＣＰＵが、前記仮想計算機の処理を実行中であった場合に、前記物理ＣＰＵで前記共通処理を実行した実行時間を測定し、測定した前記実行時間を、前記物理ＣＰＵの前記累積実行時間に加算する
   請求項５に記載の計算機。
7. 前記物理ＣＰＵは、１つの仮想記憶計算機が占有して利用できる占有モードと、複数の前記仮想計算機が共有して利用できる共有モードとのいずれかのモードに設定されており、
   前記仮想計算機制御部は、
   前記占有モードであって、前記仮想計算機の処理を実行していない物理ＣＰＵと、前記共有モードであって、前記仮想計算機の処理を実行していない物理ＣＰＵとが存在する場合に、前記共有モードであって、前記仮想計算機の処理を実行していない物理ＣＰＵを優先して、前記共通処理を実行する物理ＣＰＵとして選択する
   請求項６に記載の計算機。
8. 複数の物理ＣＰＵと、前記複数の物理ＣＰＵのいずれかが割り当てられ、所定の処理を実行する複数の仮想計算機とを有し、複数の前記仮想計算機から必要とされる共通処理を前記複数の物理ＣＰＵに実行させることができる計算機に、
   （Ａ）前記仮想計算機の処理が実行状態である前記物理ＣＰＵで、前記共通処理を実行させる場合に、前記物理ＣＰＵで前記共通処理を実行した実行時間を測定させ、前記物理ＣＰＵ毎に、前記実行時間を累積した累積実行時間を管理させ、
   （Ｂ）前記（Ａ）以降に、前記共通処理を実行させる場合において、前記累積実行時間が最小である物理ＣＰＵを、前記共通処理を実行する物理ＣＰＵとして選択させる
   コンピュータプログラム。
9. 前記計算機に、
   前記共通処理に対して、前記共通処理が前記仮想計算機の処理から連続して要求される処理であるか、連続して要求されない処理であるかを示す識別情報を対応付けて管理させ、
   （Ｃ）前記共通処理を実行させる場合において、前記共通処理に対応付けられた前記識別情報が、前記共通処理が前記仮想計算機の処理から連続して要求される処理であることを示している場合に、前記（Ｂ）を行わせる
   請求項８に記載のコンピュータプログラム。
10. 前記計算機に、
    前記共通処理を実行させる場合において、前記共通処理がいずれかの物理ＣＰＵで実行中ではなく、且つ前記仮想計算機の処理を実行していない物理ＣＰＵが存在しない場合に、前記共通処理の前記識別情報に基づいて、前記（Ｃ）又は前記（Ｄ）を実行させる
    請求項９に記載のコンピュータプログラム。
11. 前記計算機に、
    前記共通処理を実行する物理ＣＰＵとして選択された前記物理ＣＰＵが、前記仮想計算機の処理を実行中であった場合に、前記物理ＣＰＵで前記共通処理を実行した実行時間を測定させ、測定した前記実行時間を、前記物理ＣＰＵの前記累積実行時間に加算させる
    請求項１０に記載のコンピュータプログラム。
12. 複数の物理ＣＰＵと、前記複数の物理ＣＰＵのいずれかが割り当てられ、所定の処理を実行する複数の仮想計算機とを有し、複数の前記仮想計算機から必要とされる共通処理を前記複数の物理ＣＰＵに実行させることができる、計算機におけるスケジューリング方法であって、
    （Ａ）前記仮想計算機の処理が実行状態である前記物理ＣＰＵで、前記共通処理を実行させる場合に、前記物理ＣＰＵで前記共通処理を実行した実行時間を測定し、前記物理ＣＰＵ毎に、前記実行時間を累積した累積実行時間を管理し、
    （Ｂ）前記（Ａ）以降に、前記共通処理を実行させる場合において、前記累積実行時間が最小である物理ＣＰＵを、前記共通処理を実行する物理ＣＰＵとして選択する
    スケジューリング方法。
13. 前記共通処理に対して、前記共通処理が前記仮想計算機の処理から連続して要求される処理であるか、連続して要求されない処理であるかを示す識別情報を対応付けて管理し、
    （Ｃ）前記共通処理を実行させる場合において、前記共通処理に対応付けられた前記識別情報が、前記共通処理が前記仮想計算機の処理から連続して要求される処理であることを示している場合に、前記（Ｂ）を行う
    請求項１２に記載のスケジューリング方法。
14. 前記共通処理を実行させる場合において、前記共通処理がいずれかの物理ＣＰＵで実行中ではなく、且つ前記仮想計算機の処理を実行していない物理ＣＰＵが存在しない場合に、前記共通処理の前記識別情報に基づいて、前記（Ｃ）又は前記（Ｄ）を実行する
    請求項１３に記載のスケジューリング方法。
15. 前記共通処理を実行する物理ＣＰＵとして選択した前記物理ＣＰＵが、前記仮想計算機の処理を実行中であった場合に、前記物理ＣＰＵで前記共通処理を実行した実行時間を測定し、測定した前記実行時間を、前記物理ＣＰＵの前記累積実行時間に加算する
    請求項１４に記載のスケジューリング方法。

Images