(57)【特許請求の範囲】
【請求項１】
コンピュータ装置のプロセッサ・リソースを管理する装置であって、
少なくとも１つ以上のリアルタイム・アプリケーションを含むリアルタイム・アプリケーションのグループについて予め指定された限度を超えない或る量のプロセッサ・リソースを、前記コンピュータ装置のリアルタイム・アプリケーションに割当てるとともに、選択された量の前記プロセッサ・リソースを、前記コンピュータ装置の少なくとも１つの非リアルタイム・アプリケーションに利用可能にする、リソース・マネージャと、
前記リアルタイム・アプリケーションを処理する手段と、
前記限度を示す限度値と、該限度値よりも大きく且つリアルタイム・アプリケーションの前記グループについて予め指定されたプロセッサ・リソースの最大値とを記憶する手段とを備え、
前記リソース・マネージャは、前記限度値の範囲内で、リアルタイム・アプリケーションへのプロセッサ・リソースの割り当てを許可し、
許可されたリアルタイム・アプリケーションは、その作業単位のディスパッチにより実行され、
前記処理する手段は、実行中のリアルタイム・アプリケーションによるプロセッサ・リソースの消費量を監視して、該消費量が前記最大値を超えないように、前記作業単位のディスパッチを選択的に禁止する手段を含む、
プロセッサ・リソース管理装置。
【請求項２】
前記リアルタイム・アプリケーションの処理が求められていることを前記コンピュータ装置に指示する手段を備えた、請求項１記載のプロセッサ・リソース管理装置。
【請求項３】
前記指示する手段は、
前記リアルタイム・アプリケーションについてセットされたディスパッチ優先度と、
前記ディスパッチ優先度を調整すべきでないことを指定するインジケータと、
を含む、請求項２記載のプロセッサ・リソース管理装置。
【請求項４】
前記リソース・マネージャは、
リアルタイム・データ・レートを配信するための、所与の時間内の最大サービス・コストを決定する手段と、
前記リアルタイム・アプリケーションのリアルタイム・データ・ストリームを配信するためのサービス・レートを計算する手段と、
前記サービス・レートが前記限度内にあるときに、充分な量の前記プロセッサ・リソースが前記リアルタイム・データ・ストリームに利用できることを指定するインジケータと、
を含む、請求項１記載のプロセッサ・リソース管理装置。
【請求項５】
リアルタイム・アプリケーションの前記グループに現在割当てられているプロセッサ・リソースの量を追跡するために、前記リアルタイム・データ・ストリームのデータ・レートを、現在の割当て済みデータ・レートに加算する手段を備えた、請求項４記載のプロセッサ・リソース管理装置。
【請求項６】
前記リソース・マネージャは、前記リアルタイム・アプリケーションが前記プロセッサ・リソースを必要としなくなったとき、前記割当てられた量の前記プロセッサ・リソースを割当て解除するように動作する、請求項１記載のプロセッサ・リソース管理装置。
【請求項７】
前記リソース・マネージャは、割当て解除された量のプロセッサ・リソースが直ちにリアルタイム・アプリケーションの前記グループに利用できるように、現在割当てられているデータ・レートから前記リアルタイム・アプリケーションのデータ・レートを減算する手段を含む、請求項６記載のプロセッサ・リソース管理装置。
【請求項８】
前記リソース・マネージャは、前記リアルタイム・アプリケーションの処理を一時停止するように動作する、請求項１記載のプロセッサ・リソース管理装置。
【請求項９】
前記リソース・マネージャは、前記一時停止の間に、前記割当てられた量のプロセッサ・リソースを予約する手段を含む、請求項８記載のプロセッサ・リソース管理装置。
【請求項１０】
前記リソース・マネージャは、前記一時停止したリアルタイム・アプリケーションの処理を再開するように動作する、請求項８記載のプロセッサ・リソース管理装置。
【請求項１１】
前記処理する手段は、前記コンピュータ装置の性能目標を達成するために前記リアルタイム・アプリケーションに関連する１つ以上の制御パラメータに調整が必要なとき、当該制御パラメータを調整する手段を含む、請求項１記載のプロセッサ・リソース管理装置。
【請求項１２】
１つの前記非リアルタイム・アプリケーションを処理する手段を含み、当該手段は、前記コンピュータ装置の性能目標を達成するために前記１つの非リアルタイム・アプリケーションに関連する１つ以上の制御パラメータに調整が必要なとき、当該制御パラメータを調整する手段を含む、請求項１記載のプロセッサ・リソース管理装置。
【請求項１３】
前記選択的に禁止する手段は、前記最大値を超えないように、前記リアルタイム・アプリケーションの１つ以上の作業単位がそれぞれディスパッチ不能であることを指示する１つ以上のインジケータを含む、請求項１記載のプロセッサ・リソース管理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般的にはコンピュータ装置（以下単に「システム」ともいう）のプロセッサ・リソース管理に係り、さらに詳細に説明すれば、他のタイプのアプリケーションや作業を同じシステム上で同時に実行できるようにしながら、割込みのないスムーズなリアルタイム・データ・ストリームを提示するようにプロセッサ・リソースを提供することに係る。
【０００２】
【従来の技術】
コンピュータ環境では、質の良いリアルタイム・データ・ストリームを配信することは大きな課題である。リアルタイム・データ・ストリームは、ビデオ、オーディオ、及びマルチメディア等のデータ・ストリームを含む。現在、リアルタイム・データ・ストリームを配信するためのアプローチは、構成管理と高ディスパッチ優先度の２つがある。それぞれについて説明する。
【０００３】
構成管理アプローチでは、リアルタイム・データ・ストリームの配信にサーバが専用される。このサーバは、リアルタイム・データ・ストリームを所与のレートで配信するために、充分な容量を持たせて構成される。このサーバはリアルタイム・データ・ストリームの配信専用なので、リアルタイム・ストリームはシステム・リソースを独占し、他のタイプの作業については、残るとしてもごく僅かなリソースしか残らない。
【０００４】
高ディスパッチ優先度アプローチの場合、リアルタイム・アプリケーションはディスパッチ優先度がかなり高い状態で実行される。この手法は専用システムで実行する必要はないが、この場合でも、リアルタイム・アプリケーションをかなり高い優先度で実行することによって、実行に充分なリソースをシステム上の他の作業が受け取ることに対する制御又は保証はない。
【０００５】
【発明が解決しようとする課題】
従って、リアルタイム・データ・ストリームを割込みなくスムーズに配信する一方、システム上で同時に実行される他の作業に所望の量のプロセッサ・リソースを提供する機構が求められる。またリアルタイム・データ・ストリームに割当てられるリソースの量に限度を設け、これにより、選択されたリソース量を非リアルタイム作業に利用可能にする管理機構も求められる。
【０００６】
【課題を解決するための手段】
従来技術の欠点は、コンピュータ装置内のプロセッサ・リソースを管理する装置を提供することにより克服され、他の利点も与えられる。この管理装置はは、１つの例では、コンピュータ装置のリアルタイム・アプリケーションに、或る量のプロセッサ・リソースを割当てるリソース・マネージャを含む。この量は、１つ以上のリアルタイム・アプリケーションの或るグループ（以下「リソース・グループ」ともいう）のために選択された限度を超えることはない。選択された量のプロセッサ・リソースは、コンピュータ装置の少なくとも１つの非リアルタイム・アプリケーションに利用できる。またこの管理装置は、リアルタイム・アプリケーションを処理する手段を含む。この処理する手段は、リアルタイム・アプリケーションの前記グループのために選択されたプロセッサ・リソースの最大量（後述の「最大値」によって指定されるプロセッサ・リソースの量）をリアルタイム・アプリケーションが超えることを防止する手段を含む。
【０００７】
また他の実施例では、リソース・マネージャは、リアルタイム・データ・レートを配信するための、所与の時間内の最大サービス・コストを決定する手段、リアルタイム・アプリケーションのリアルタイム・データ・ストリームを配信するサービス・レートを計算する手段、及びサービス・レートが限度内にあるときに、充分な量のプロセッサ・リソースがリアルタイム・データ・ストリームに利用できることを指定するインジケータを含む。
【０００８】
本発明の管理機能の利点は、リアルタイム・アプリケーションによって利用される、或る量のプロセッサ・リソースを選択でき、選択された量のリソースを非リアルタイム・アプリケーションに予約できることである。また本発明の管理機能により、リアルタイム・アプリケーションがコンピュータ装置をオーバランさせることはなくなる。リアルタイム・アプリケーションは、割込みなくスムーズに実行でき、他のタイプの作業もシステム上で処理できる。
【０００９】
【発明の実施の形態】
本発明に従い、リアルタイム・アプリケーション、及びバッチ処理、トランザクション処理等、他のタイプのアプリケーションも、汎用コンピュータ装置（つまり非専用コンピュータ装置）で同時に実行できる。特にリアルタイム・アプリケーションには、これらのリアルタイム・アプリケーションがシステムをオーバランさせないように、制限された量のプロセッサ・リソースが与えられる。他のタイプのアプリケーション（つまり非リアルタイム・アプリケーション）にも、或る量のプロセッサ・リソースが処理のため与えられる。非リアルタイム・アプリケーションは、ここで用いているとおり、バッチ・アプリケーション、トランザクション処理アプリケーション、非リアルタイムにシステムで実行される他の作業等、リアルタイムに実行されない任意のアプリケーションを含む。
【００１０】
本発明の機能を取り入れて使用する非専用コンピュータ装置の１つの例を図１に示す。以下、これについて詳しく説明する。
【００１１】
実施例では、コンピュータ装置１００は、オペレーティング・システム１０２、少なくとも１つのリアルタイム・サーバ・アプリケーション（以下「リアルタイム・アプリケーション」ともいう）１０４、及び１つ以上の他のタイプのアプリケーション（以下「非リアルタイム・アプリケーション」ともいう）１０６を含む。リアルタイム・サーバ・アプリケーション１０４は、リアルタイム・データを配信し、１つ以上の作業単位１０８を含む。作業単位１０８は、例えば、コンピュータ装置１００の目的である有益な作業を行うアプリケーション・プログラムである。他のタイプの・アプリケーション１０６は、例えば、バッチ・アプリケーション１１０とトランザクション処理アプリケーション１１２を含む。これらも作業単位を含む。リアルタイムサーバ・アプリケーション１０４とトランザクション処理アプリケーション１１２は、例えば、コンピュータ装置１００に接続されたワークステーション側のクライアント１１４にサービスを提供している。
【００１２】
オペレーティング・システム１０２はＩＢＭ社の「ＭＶＳ（多重仮想記憶）」オペレーティング・システムである。ただし、これは１つの例にすぎない。他のオペレーティング・システムも本発明の主旨又は範囲から逸脱することなく使用できる。実施例では、オペレーティング・システム１０２は、作業負荷マネージャ１１６、システム・リソース・マネージャ１１８、ディスパッチャ１２０、及び作業単位制御ブロック１２２を含む。以下、その各々について詳述する。
【００１３】
作業負荷マネージャ１１６はコンピュータ装置１００の作業負荷を管理する。作業負荷マネージャ１１６のタスクの１つは、本発明の管理機能によって用いられる或る値を入力としてコンピュータ装置１００に読込むことを含む。例えば、作業負荷マネージャ１１６は、１つ以上のプロセッサ消費限度値（以下単に「限度値」ともいう）と、１つ以上のプロセッサ消費最大値（以下単に「最大値」ともいう）を読込む。これらの値は、リアルタイム・アプリケーション（リアルタイム・データを配信するアプリケーション）及び非リアルタイム・アプリケーションに割当てられるリソースの量を決定するために用いられる。例えば、これらの値はシステム管理者によって設定される。
【００１４】
各プロセッサ消費限度値は、例えば、１つ以上のリアルタイム・アプリケーションに割当てることのできるプロセッサ・リソースの量を指定する。この値は、システム上の他のタイプのアプリケーションや作業が同時に実行できるように選択される。後述するように、異なるリアルタイム・アプリケーションを異なる限度値に関連付ける、又は同じ限度値にすることができる。同様に、プロセッサ消費限度値は、非リアルタイム・アプリケーションに関連付けることができる。
【００１５】
各プロセッサ消費最大値は、例えば１つ以上のリアルタイム・アプリケーション、又は１つ以上の非リアルタイム・アプリケーションによって使用できるプロセッサ・リソースの量に対するキャップ（上限）を指定する。実施例では、これらの最大値は限度値よりも大きい。なぜなら、処理の間に、データ・ストリームの配信に一時的なサージがあり得、これにより割当て済みリソースの量を超えることがあるからである。従って、各最大値は、処理中の１つ以上のアプリケーションが、プロセッサ消費限度値により指定されたものより少し多くプロセッサ・リソースを消費する必要のある場合を考慮してバッファを与える。ただし、これらのアプリケーションによって消費されるリソースの量は、このキャップを超えることができない。これは、システムの追加作業に、選択された量のプロセッサ・リソースが与えられることを保証する。後述するように、異なるアプリケーションを異なる最大値に関連付けることができ、又は同じ最大値にすることができる。
【００１６】
実施例では、プロセッサ消費限度値と最大値は、プロセッサ・サービス単位によって表される。ただし、これは１つの例にすぎない。当業者には明らかなように、他の測定単位も、本発明の主旨又は範囲から逸脱することなく選択できる。
【００１７】
作業負荷マネージャ１１６は、限度値と最大値の読込みに続いて、プロセッサ消費限度値と消費最大値の各ペアを取り、アプリケーションの個々の作業単位が割当てられる処の、或るリソース・グループを設定する。これにより、異なる限度値と最大値を異なるアプリケーションに指定できる。例えば、リアルタイム・アプリケーションＡ、Ｂをリソース・グループ１に割当て、限度値を５００、最大値を５５０と指定できる。また、リアルタイム・アプリケーションＣをリソース・グループ２に割当て、その限度値を２００、最大値を２１０と指定できる。同様に、非リアルタイム・アプリケーションＤ、Ｅをリソース・グループ３に割当て、限度値を２５００とし、最大値を使用しないように指定できる。これらの例では、リアルタイムと非リアルタイムのアプリケーションは別々のグループ内にある。これは１つの例にすぎない。他の実施例では、或るグループ内にタイプの異なる複数のアプリケーションを含ませることもできる。限度値と最大値は、特定のグループに対して選択される。従って、このグループは、全体としてこれらの値を超えることができない。
【００１８】
各リソース・グループは、オペレーティング・システム１０２に割当てられたメモリ内で、リソース・グループ・テーブル・エントリ１３０によって表されるようになっている。実施例では、リソース・グループ・テーブル・エントリ１３０は次を含む。
（ａ）リソース・グループ名１３２。これは、作業負荷マネージャ１１６への入力値であって、このリソース・グループ・エントリに対応したリソース・グループの名前を示す。
（ｂ）プロセッサ消費最大値１３４。これは、前述のように、このリソース・グループ内の１つ以上のアプリケーションによって消費されることが許可されたプロセッサ・リソースの量に対するキャップを指定する入力値である。
（ｃ）プロセッサ消費限度値１３６。これは、前述のように、このグループ内の１つ以上のアプリケーションに割当てることのできるプロセッサ・リソースの量を指定する入力値である。
（ｄ）プロセッサ利用状況データ１３８。これは、後述する種々の測定データ及び計算データを含む。
（ｅ）キャップ・スライス・パターン１４０。これは、詳細は後述するが、このリソース・グループ内の１つ以上の作業単位にキャップを付けるときの特定のタイム・スライスを示す計算値である。
【００１９】
前記の他に、作業負荷マネージャ１１６は、相対的重要度を含めて、コンピュータ装置１００の性能目標を入力として読込み、個々の作業単位（例えば、或るリソース・グループ内の作業単位）が割当てられる処の、或るユーザ性能目標クラスを設定する。性能目標は、リアルタイム及び非リアルタイムの両方のアプリケーションに関連付けられる。或る目標クラスが或るリソース・グループに関連付けられることもあるし、関連付けられないこともある。或るリソース・グループの一部ではない作業単位も、或る目標クラスの一部になり得る。また、２つ以上のクラスを或るリソース・グループに関連付けることができる。
【００２０】
性能目標とユーザ性能目標クラスについては、米国特許第５４７３７７３号、及び１９９５年２月３日に出願された米国特許出願第０８／３８３０４２号を参照されたい。
【００２１】
各ユーザ性能目標クラスは、オペレーティング・システム１０２に割当てられたメモリ内で、クラス・テーブル・エントリ１４２によって表される。クラス・テーブル・エントリ１４２は、例えば次を含む。
（ａ）リソース・グループ名１４４。これは、リソース・グループがあると仮定して、このユーザ性能目標クラスが属する特定のリソース・グループを指定する入力値である。リソース・グループがなければ、このフィールドはブランクのままである。
（ｂ）ユーザ性能目標１４６。これは、このクラスの特定の性能目標を示す入力値である。性能目標の例として所望の応答時間がある。
（ｃ）ユーザ性能目標の相対的重要度１４８。これもコンピュータ装置１００に対するこの目標の重要度を指定する入力値である。
（ｄ）ディスパッチ優先度１５０。これは、以下で「コントローラ」と略称するＳＧＤＰＣ（ｓｙｓｔｅｍ  ｇｏａｌ  ｄｒｉｖｅｎ  ｐｅｒｆｏｒｍａｎｃｅ  ｃｏｎｔｒｏｌｌｅｒ）１５８によってセットされ、このクラスの作業単位が（全体として）ディスパッチされる順序を、システムの他のクラスに対して示す。
（ｅ）リアルタイム・サーバ・ビット１５２。これは、このクラスの作業単位がリアルタイム・アプリケーションの一部か否かを示す。このビットは、後述するように本発明に従ってセットされる。
【００２２】
オペレーティング・システム１０２は、作業負荷マネージャ１１６の他にシステム・リソース・マネージャ１１８を含む。システム・リソース・マネージャ１１８は、オペレーティング・システム１０２の構成要素であり、コンピュータ装置１００のリソース（ＣＰＵ利用率等）を管理する。実施例では、システム・リソース・マネージャ１１８はコントローラ１５８を含む。このコントローラ１５８は、後述するように、オペレーティング・システム１０２に適応性と自己調整性を持たせるよう、性能問題の増分検出と補正を行うためのフィードバック・ループを与える。
【００２３】
コントローラ１５８の実施例については、前掲の米国特許第５４７３７７３号及び米国特許出願第０８／３８３０４２号に加えて、１９９５年２月３日に出願された米国特許出願第０８／３８３１６８号を参照されたい。
【００２４】
コントローラ１５８の、特に本発明に係る他の詳細事項について、ここで詳述する。コントローラ１５８は、本発明に従って、本発明のプロセッサ利用状況データの処理、ユーザ性能目標の達成を管理するための性能インデックスの計算とシステム・リソース管理の調整、及びリアルタイム・アプリケーションがシステムをオーバランさせないためのプロセッサ・リソース消費量のキャッピングの調整を担当する。以下、その各々について説明する。
【００２５】
オペレーティング・システム１０２は、さらにディスパッチャ１２０を含む。ディスパッチャ１２０は、コンピュータ装置１００によって次に実行される作業単位を選択するために用いられる。各作業単位は、作業単位制御ブロック１２２の１つによって表される。各作業単位制御ブロックは、オペレーティング・システム１０２に割当てられたメモリ内に格納され、例えば、次の３つのディスパッチ制御フィールドを含む。
（ａ）ディスパッチ優先度フィールド１５４。これは、ディスパッチャ１２０がディスパッチ作業に取り掛かる順序をディスパッチャ１２０に示す。ディスパッチ優先順位の１つの例を図２に示す。
図２に示すように、実施例では、最大のディスパッチ優先度は、オペレーティング・システム１０２、ディスパッチャ１２０、システム・リソース・マネージャ１１８、及びコントローラ１５８に予約され、次に最大の優先度は、リアルタイム・アプリケーションの作業単位及びシステム機能のために使われる。
トランザクション及びバッチ処理アプリケーション１１２及び１１０の作業単位には、複数の低い優先度が予約される。これら複数の低優先度は、前掲の米国特許及び米国特許出願に詳述されているとおり、コントローラ１５８の操作によって割当てられる。
（ｂ）優先使用ビット・フィールド１５６。これは、関連付けられた作業単位を、レディ状態になってすぐにディスパッチ対象として考慮すべきことをディスパッチャ１２０に示す。
（ｃ）キャップ・ビット・フィールド１６０。これは、関連付けられた作業単位をディスパッチできるか否かをディスパッチャ１２０に示す。このビットは、ここで詳しく述べているように、作業単位の特定のグループのために許可されたプロセッサ実行時間の量を制御するために用いられる。
【００２６】
本発明に従って、選択された量のプロセッサ・リソース（ＣＰＵ時間等）をリアルタイム・アプリケーションに、また選択された量をシステム上の他のタイプの作業に提供するために、コンピュータ装置１００の種々の構成要素が用いられる。本発明に従って、リアルタイム・アプリケーションの処理に関連付けられるロジックの実施例について、図３を参照して詳しく説明する。
【００２７】
図３を参照する。最初、実行したい或るリアルタイム・アプリケーションがシステム・リソース・マネージャ１１８に対してそれ自身を識別する（ステップ３０２）。これにより、システム・リソース・マネージャ１１８は、このリアルタイム・アプリケーションが割込みなくスムーズに処理を行う一方、システム上の他の作業をオーバランさせない程度の充分なリソースを持つのに必要な調整を行うことができる。システム・リソース・マネージャ１１８に対して或るアプリケーションを識別する手順の１つを、図４を参照して詳しく説明する。図４に示した諸機能は、システム・リソース・マネージャ１１８によって実行される。
【００２８】
図４を参照する。最初、クラス・テーブル・エントリ１４２内のディスパッチ優先度１５０と、識別側リアルタイム・アプリケーションに関連付けられた各作業単位制御ブロック１２２内のディスパッチ優先度１５４が、「次に最大の優先度」に設定される（ステップ４０２）。後者の優先度は、リアルタイム・アプリケーションのために指定される。
【００２９】
その後、このリアルタイム・アプリケーションの個々の作業単位制御ブロック１２２内の各優先使用ビット１５６がセットされ、関連付けられた作業単位が利用できるようになれば、すぐにディスパッチについて考慮すべきことがディスパッチャ１２０に示される（ステップ４０４）。
【００３０】
また、クラス・テーブル・エントリ１４２内のリアルタイム・サーバ・ビット１５２がセットされ、このクラス内の作業単位がリアルタイム・サーバであって、ディスパッチ優先度を調整すべきでないことがコントローラ１５８に示される（ステップ４０６）。
【００３１】
ディスパッチ優先度、全優先使用ビット、及びリアルタイム・サーバ・ビットのセット後、この識別機能は完了する。従って、図３に戻るが、このリアルタイム・アプリケーションの次のタスクは、リソースをこのアプリケーションに割当てることである（ステップ３０４）。
【００３２】
割当て方法の実施例を図５及び図６を参照して詳しく説明する。図６のロジックは種々のプロセッサ利用状況データを使用する。プロセッサ利用状況データについては、図５を参照して詳述する。データの説明の後、割当てロジックの実施例について説明する。
【００３３】
図５を参照する。本発明のプロセッサ利用状況データ１３８の１つの例は、次を含む。
（ａ）グループ・サービス・レート５０２。これは、このグループ内の作業単位によって消費された現在のサービス（ＣＰＵ消費等）を示す。このレートは普通はサービス単位／秒で表されるが、必ずしもそうする必要はない。
（ｂ）前の割当て済みリアルタイム・レート５０４。これは、コントローラ１５８が起動されたとき（例えば１０秒毎）、コントローラ１５８によって記入される。コントローラ１５８は、現在の割当て済みリアルタイム・レート（後述）を、前の割当て済みリアルタイム・レート５０４にコピーする。
（ｃ）現在の割当て済みリアルタイム・レート５０６。これは、このグループのリアルタイム・データ・ストリームを配信するために現在割当てられている容量単位の量（ＫＢ／秒等）を表す。ディスクから通信ネットワークへデータのバイトを移動させるためのプロセッサ・コストは、容量単位としてＫＢ／秒を使用する定数に充分近く、ＫＢ／秒はリアルタイム・アプリケーションには有意義な単位である。リアルタイム・アプリケーションは容量をＫＢ／秒で要求する。現在の割当て済みリアルタイム・レート５０６は、次に述べる割当て機能と割当て解除機能によって記入される。
（ｄ）前の一時停止リアルタイム・レート５０８。これは、コントローラ１５８が起動されたとき（例えば１０秒毎）、コントローラ１５８によって記入される。コントローラ１５８は、現在の一時停止リアルタイム・レート（後述）を、前の一時停止リアルタイム・レート５０８にコピーする。
（ｅ）現在の一時停止リアルタイム・レート５１０。これは、このグループの一時停止した任意のリアルタイム・データ・ストリームのデータ・レートの和を含む（後述）。
（ｆ）割当て済みリアルタイム・レート・ウィンドウ５１２。これは、例えば１８個のウィンドウ枠を含むデータのウィンドウである。特に割当て済みリアルタイム・レートは、移動するタイム・ウィンドウで維持される。移動するタイム・ウィンドウは、例えば最近の３分として定義される。１８０秒のウィンドウは、各々が１０秒である１８個の間隔（これを「１８個のウィンドウ枠」という）に分けられ、１８個の要素から成る１つの配列として実現される。割当て済みリアルタイム・レート・ウィンドウ枠は、コントローラ１５８が１０秒毎に起動されたとき、前の１０秒間隔の間にリアルタイム・アプリケーションの活動があったことを条件として、コントローラ１５８によって記入される。割当て済みリアルタイム・レート・ウィンドウ枠は、前の割当て済みリアルタイム・レート５０４と現在の割当て済みリアルタイム・レート５０６の平均を取ることによって計算される。
（ｇ）リアルタイム・サービス・レート・ウィンドウ５１４。これは、もう１つのデータ・ウィンドウであり、例えば１８個のウィンドウ枠を含む。リアルタイム・サービス・レートは、リアルタイム・データ・ストリームを配信するリアルタイム・アプリケーションの作業単位によって消費されたプロセッサ・サービスを表す。リアルタイム・サービス・レート・ウィンドウ枠は、コントローラ１５８が１０秒毎に起動されたとき、前の１０秒間隔の間にリアルタイム・アプリケーションの活動があったことを条件として、コントローラ１５８によって記入される。リアルタイム・サービス・レート・ウィンドウ枠の値は、グループ・サービス・レート５０２からコピーされる。
（ｈ）リアルタイム一時停止レート・ウィンドウ５１６。これは、第３のデータ・ウィンドウで、これも例えば１８個のウィンドウ枠を含む。リアルタイム一時停止レートは、現在一時停止しているこのグループのリアルタイム・データ・ストリームを表すデータ・レートである。他の２つのデータのウィンドウと同様に、一時停止レート・ウィンドウ枠は、コントローラ１５８が１０秒毎に起動されるとき、前の１０秒間隔の間にリアルタイム・アプリケーションの活動があったことを条件として、コントローラ１５８によって記入される。一時停止リアルタイム・レート・ウィンドウ枠の値は、前の一時停止リアルタイム・レート５０８と現在の一時停止リアルタイム・レート５１０の平均を取ることによって計算される。
（ｉ）リアルタイム・ウィンドウ枠インデックス５１８。これは、ウィンドウ枠配列要素の現在のインデックスを表す。現在の１０秒間隔のためのデータは、現在のウィンドウ枠インデックスによって索引されたウィンドウ枠配列要素内に格納される。各ウィンドウ配列の１８個の配列要素は、ローテーション方式で用いられる。１８個目の要素が用いられた後、次の間隔のためのデータが第１要素内に格納され、その要素内の古いデータと置き換えられる。リアルタイム・ウィンドウ枠インデックスは、前の１０秒間隔の間にリアルタイム・アプリケーションの活動があったことを条件として、コントローラ１５８によって進められる。かかる活動がないときは、このインデックスは進められない。これにより、再びリアルタイム・アプリケーションの活動が開始されたときに用いられるよう、ＫＢ／秒当たりの前のサービス・コストが保存される。
【００３４】
前述のように、前記のプロセッサ利用状況データ１３８は、本発明の割当て機能の実行中に用いられる。一般的に、システム・リソース・マネージャ１１８の割当て機能は、或るリアルタイム・データ・ストリームを配信するためのプロセッサ容量を割当て且つ保証するために、リアルタイム・サーバによって起動される。割当て機能の入力値は、リアルタイム・ストリームのＫＢ／秒データ・レートである。割当てのとき、リアルタイム・データ・ウィンドウ枠がスキャンされ、ウィンドウ内の１８個の枠で転送されたＫＢ／秒当たりの最大プロセッサ・サービス・コストが検出される。次に、この値を用いて、新しいストリームのサービス要件が決定される。その後、システム管理者によって指定されたグループ・サービス限度値１３６の範囲内で、必要なプロセッサ容量が利用できるか否かが決定される。割当て機能の実施例の詳細については、さらに図６を参照して説明する。
【００３５】
図６を参照する。最初、ウィンドウ枠インデックス５１８がセットされて、ウィンドウ枠をスキャンするときの最初のウィンドウ枠がポイントされ、また高レートと呼ばれる或る変数が０に初期化される（ステップ６００）。その後、ＫＢ／秒（データ・レート）を配信するサービス・コストが、次のように計算される（ステップ６０２）。
【数１】
リアルタイム・サービス・レート・ウィンドウ５１４÷
（割当て済みリアルタイム・レート・ウィンドウ５１２−
リアルタイム一時停止レート・ウィンドウ５１６）
【００３６】
ステップ６０２で計算された値は、現在のサービス・レートであり、これは新しいレートと呼ばれる。新しいレートは、保存された高レートに対して検査される（ステップ６０４）。もし、割当て済みリアルタイム・レート・ウィンドウ枠５１２内に保存された新しいレートが高レートより大きければ、高レートは新しいレートにセットされる（ステップ６０６）。新しい高レートを保存した後、又は現在のサービス・レートが高レートより小さいかこれに等しければ、さらに別のウィンドウ枠があるか否かが決定される（ステップ６０８）。特に、このケースでは、ウィンドウ枠インデックスが１８と比較され、このインデックスが１８より小さければ、リアルタイム・ウィンドウ枠インデックス５１８が１つ増分される（ステップ６１０）。次に制御はステップ６０２に移る。
【００３７】
他方、スキャンすべきウィンドウ枠が他になければ、新しいリアルタイム・データ・ストリームを配信するのに必要なサービスの量が次のように計算される。
【数２】
新しいストリームのＫＢ×ウィンドウ内のＫＢ当たりの最大サービス・レート
【００３８】
ただし、新しいストリームのＫＢは入力値であり、最大サービス・レートは、高レート変数内に格納されたレートである。
【００３９】
必要なサービスの量が計算された後、グループ・サービス限度値１３６内でこのサービス量が利用できるか否かが決定される（ステップ６１４）。もし、充分な容量が利用できなければ、不成功を示す戻りコードがセットされ（ステップ６１６）、割当て機能は完了する（ステップ６１８）。
【００４０】
他方、リアルタイム・データ・ストリームを配信するのに充分な容量があれば、新しいストリームのレートが現在の割当て済みリアルタイム・レート５０６に追加され（ステップ６２０）、成功を示す戻りコードがセットされる（ステップ６２２）。その後、割当て機能は完了する（ステップ６１８）。
【００４１】
図３に戻る。割当て機能が実行された後、リアルタイム・アプリケーションを実行でき、これによりリアルタイム・データ・ストリームが配信される（ステップ３０６）。
【００４２】
リアルタイム・アプリケーション及び非リアルタイム・アプリケーションの実行中、コントローラ１５８がシステム・リソースの利用状況を監視し、監視内容に基づいて制御を調整する。
【００４３】
コントローラ１５８は、例えばユーザ性能目標の達成を管理するため、ディスパッチ優先度等のシステム・リソース制御を調整すること（図７、ステップ７００）、及び特定のリソース・グループによるリソース消費を制限するため、それらのグループのキャッピングを調整すること（ステップ７０２）を含めて、２つのタスクを実行する。これらのタスクの各々についてここで詳述する。
【００４４】
最初のタスクであるシステム・リソース制御の調整（ステップ７００）は、例えば、システム上のアプリケーションの実行中に或る間隔で実行される。実施例では、コントローラ１５８は１０秒毎に起動され、システム制御を調整する必要があるか否かを決定する。
【００４５】
特にコントローラ１５８の制御調整機能は、性能目標の達成度を測定し、性能を改良する必要のあるユーザ性能目標クラスを選択し、関連付けられた作業単位のシステム制御パラメータ（つまり、ディスパッチ優先度等の被制御変数）を変更することによって選択されたユーザ性能目標クラスの性能を改良する。しかし、ディスパッチ優先度等の特定パラメータを変更する前に、コントローラ１５８は、本発明に従って、リアルタイム・サーバ・ビット１５２を検査し、このアプリケーションがリアルタイム・アプリケーションか否かを決定する。もし、リアルタイム・サーバ・ビット１５２がオン、つまりリアルタイム・データ・ストリームの配信を示せば、このクラスのディスパッチ優先度１５０及び適応できる各作業単位内のディスパッチ優先度１５４は変わらないままに留まる。これにより、リアルタイム・データ・ストリームに一定量のリソースが保証される。
【００４６】
他方、リアルタイム・サーバ・ビット１５２がオフであれば、ディスパッチ優先度を調整することができる。非リアルタイム・アプリケーションに対するコントローラ１５８の処理については、前掲の米国特許出願第０８／３８３０４２号を参照されたい。しかし、本発明に従って、非リアルタイム・アプリケーションの作業単位に利用できるプロセッサ容量は、プロセッサ総容量から、リアルタイム・アプリケーションの作業単位に保証され且つこれらの作業単位によって用いられるプロセッサ容量を引いたものである。
【００４７】
２つ目のタスクであるキャッピングの調整（ステップ７０２）も、前掲の米国特許出願第０８／３８３０４２号で説明されているものと同様に行われる。このキャッピング調整機能は、各リソース・グループに割当てられた作業単位をディスパッチ不能（キャッピング済み）にすべき時間の量を決定することにより、リソース消費量を、このリソース・グループのために指定されたリソース・グループ最大値１３４の範囲内に制限する。
【００４８】
特に、時間の長さ（この長さはプロセッサ速度に依存する）は、例えば６４個の間隔等、多数の間隔に分けられ、そしてキャッピング調整機能は、各リソース・グループ内の作業単位にキャップを付けるべき間隔の個数を計算する。次に、キャッピング調整機能は、６４個の間隔の各々に対応するインジケータをセットして、その間隔の間にこのリソース・グループにキャップを付けるべきか否かを指示させる。これらのインジケータは、キャップ・スライス・パターン（キャップ・ビット・パターン）１４０を形成する。キャップ・ビットは、前掲の米国特許出願第０８／３８３０４２号に記述されているように、６４個の間隔全体にわたって比較的均一に分散される。
【００４９】
６４個の間隔の各々の間に、システム・リソース・マネージャ１１８のキャップ・ビット・マニピュレータ機能が起動され、キャップ・ビット・パターン１４０が検査される。これにより、どのリソース・グループにキャップを付けるかが決定され、そのように決定されたリソース・グループ内の作業単位に関連する作業単位制御ブロック内にキャップ・ビット１６０がセットされる。キャップ・ビット１６０はディスパッチャ１２０によって問い合わせられ、その結果、或る作業単位をディスパッチできるか否かが決定される。本発明では、システム管理者が、リアルタイム・アプリケーションを含むリソース・グループの最大値１３４を指定し、そしてキャッピング調整機能は、そのリアルタイム・アプリケーションが、指定された最大値１３４を超えてプロセッサ容量を消費しないことを保証する。
【００５０】
キャッピング調整機能の実施例について、図８及び図９を参照して詳述する。まず図８を参照する。最大値１３４を有する、従って処理が必要であるリソース・グループが他にあるか否かが決定される（ステップ８００）。もし、処理すべきグループが他になければ、この機能は完了し、制御はステップ８０２に移る。
【００５１】
他方、処理すべきリソース・グループが他にあれば、このリソース・グループのキャップ・スライスが現にセットされているか、又はこのリソース・グループが指定された最大値以上のプロセッサ時間を現に消費しているか否かが決定される（ステップ８０４）。もし、この検査の結果が否定的であれば、制御はステップ８００に移り、次のリソース・グループが処理される。
【００５２】
他方、このリソース・グループのキャップ・スライスが現にセットされているか、又はこのリソース・グループのプロセッサ消費時間がその最大値を超えている場合は、制御はステップ８０６に移り、このリソース・グループのキャップ・スライスが計算される。
【００５３】
ステップ８０６では、許可されるプロセッサ・サービス単位の数（つまり最大値１３４）が、次のステップを用いて、キャップ・スライスの数に変換される。
１．許可される非キャップ・スライスの値を次のように計算する。
【数３】
非キャップ・スライス＝ＳＡ＊（ＴＳＬＯＷ−ＣＳＬＯＷ）／ＳＥＲＯＷ
【００５４】
ＳＡ  −  許可されたプロセッサ・サービス単位（つまり最大値）
ＴＳＬＯＷ  −  ウィンドウの総スライス数（例えば６＊６４＝３８４、定数）
ＣＳＬＯＷ  −  キャップ・スライス・ウィンドウでキャップが付いたスライスの値（後述）
ＳＥＲＯＷ  −  サービス・ウィンドウで消費されたプロセッサ・サービス単位（後述）
キャップ・スライス・ウィンドウは、例えば６個の枠から成るウィンドウであり、その各ウィンドウ枠は例えば１０秒である。各ウィンドウ枠はその枠のキャップ付きスライスの数を保持する。サービス・ウィンドウも、例えば６個の枠から成るウィンドウで、その各ウィンドウ枠が１０秒にわたって測定されたサービスを保持する。キャップ・スライス・ウィンドウとサービス・ウィンドウは、キャッピング・インデックスにより１から始めて索引される。増分は１で、６に達すると１に戻る。キャップ・スライス・ウィンドウ、サービス・ウィンドウ、及びキャッピング・インデックスは、プロセッサ利用状況データ１３８の一部である（しかし図５には示していない）。
２．もし、非キャップ・スライスの計算結果が０になれば、これを１にセットする。その時間の１００％にキャップを付けない。
３．キャップ・スライスを、総スライス数（６４）から非キャップ・スライスを引いた値に等しくセットする。
４．もし、キャップ・スライスの増加が総スライス数の２分の１より大きければ、キャップ・スライス数を総スライス数の２分の１だけ増やす。
５．キャップ・スライス数をリソース・グループ・テーブル・エントリ１３０内に格納する。キャップ・スライス数は、現在のウィンドウ枠インデックスによって索引されたキャップ・スライス配列要素内に格納される。
【００５５】
キャップを付けるべきキャップ・スライス数を求める他に、各リソース・グループのキャップ・スライスが、キャップ・ビット・マニピュレータの問い合わせのため、キャップ・スライス・パターンにわたって比較的均一に分散される。キャップ付きスライス数が最大のリソース・グループには、特定のスライスが最初に割当てられ、次に最大のキャップ・スライス数を要するリソース・グループが次に処理され、以下同様に、キャップ付きスライスを有するすべてのリソース・グループが処理されていく。システム全体では、キャップ・スライス・パターンの６４個のスライスの各々の間に、同じ個数のリソース・グループ±１グループにキャップが付けられる。こうするため、特定スライスが特定のリソース・グループに割当てられるとき、各スライスの間にキャップが付けられるべきリソース・グループの値のカウントが維持される。このカウントはテストされ、グループに特定スライスを割当てるか否かが決定される。６４個のすべてのスライスが１回割当てられるまでは、２つのリソース・グループにスライスが割当てられることはない。６４個のすべてのスライスが２回割当てられるまでは、３つのグループにスライスが割当てられることはない。以下同様である。
【００５６】
キャップ・スライスを分散させる実施例について、図９を参照して詳述する。最初、システム・データであるスライス・カウント配列（ＳＣＡ）がその配列要素を０にセットすることによって初期化される（ステップ９００）。このスライス・カウント配列は複数のカウントの配列である。各エントリは、そのスライスの間にキャップが付けられるグループの数を保持する。このスライス・カウント配列には、６４個のエントリがある。各エントリは、時間の６４分の１を表す。
【００５７】
その後、まだ処理されていないキャップ・スライスの数が最大のリソース・グループが選択される（ステップ９０２）。もし、処理すべきリソース・グループがなければ、制御は終了する（ステップ９０４）。他方、処理すべきリソース・グループが他にあれば、制御はステップ９０６に進む。
【００５８】
ステップ９０６で、リソース・グループ・データが初期化される。特にスライス増分（ＳＩ）、スライス・カウント基準（ＳＣＣ）、及びスライス・カウント配列インデックス（ＳＣＡＩ）、が次のように初期化される。（ＳＩ−１）は、このリソース・グループの各キャップ・スライスの間でスキップできるスライス数である。かかるスキップを行うことにより、このリソース・グループのキャップ・スライスは、６４個の可能なキャップ・スライスにわたって比較的均一に分散される。ＳＩは、このグループのキャップ・スライス数で６４を除算した値にセットされる。ＳＣＣは、スライス・カウント配列内の最大値にセットされる。もし、スライス・カウント配列内のすべてのカウントが同じ値であれば、ＳＣＣに１が追加される。ＳＣＡＩは、キャップ・スライス・パターン内の最初のスライスで始めるため、１にセットされる。
【００５９】
次に、ＳＣＡ（ＳＣＡＩ）セル内のカウントが、このグループのスライス・カウント基準（ＳＣＣ）に対して検査される（ステップ９０８）。もし、このスライスがＳＣＣ個のグループに割当てられているか、又はすでにこのグループに割当てられていれば、制御はステップ９１０に移り、ここでＳＣＡＩに１が追加される。ＳＣＡＩが６５に増分されると、これは１にリセットされる（つまりＳＣＡＩはモジュロ６４である）。もし、スライス・カウント配列内のすべてのカウントが同じ値であれば、ＳＣＣに１が追加される。制御は次にステップ９０８に戻る。
【００６０】
他方、このスライスがＳＣＣより小さい個数のリソース・グループに割当てられていて、処理中の現在のグループに割当てられていなければ、制御はステップ９１２に移り、そこでこのスライスが現在のグループに割当てられ、ＳＣＡ内のスライスの利用状況カウントに１が追加される。このスライスは、このリソース・グループのキャップ・スライス・パターン１４０内のＳＣＡＩに対応したビットをセットすることによって、このリソース・グループに割当てられる。制御は次にステップ９１４に移る。
【００６１】
ステップ９１４では、現在のリソース・グループに割当てるスライスが他にあるか否かが決定される。もし、特定のスライスがすべてのグループのキャップ・スライスについて割当てられていれば、制御はステップ９０２に戻り、他のリソース・グループが検査される。しかし、このグループに他の特定のスライスを割当てる必要がある場合は、制御はステップ９１６に移る。
【００６２】
ステップ９１６では、ＳＣＡＩにＳＩが追加され、次に検査すべき特定のスライスがセットされる。もし、ＳＣＡＩが６４より大きければ、ＳＣＡＩから６４が引かれる。もし、ＳＣＡ内のすべてのカウントが同じ値であれば、ＳＣＣに１が追加される。次に制御はステップ９０８に戻る。その後、キャップ・スライスの分散が完了する。
【００６３】
再び図３の概要図に戻る。識別３０２、割当て３０４、及び実行３０６の機能が完了すると、リアルタイム・データ・ストリームを配信するために割当てられたプロセッサ・リソースの割当てが、割当て解除機能を使用して割当て解除される（ステップ３０８）。特に、リアルタイム・サーバがシステム・リソース・マネージャ１１８の割当て解除機能を起動して、リアルタイム・データ・ストリームが終了し、割当て済みプロセッサ・リソースをそれ以上消費することはないことを示す。
【００６４】
割当て解除機能の実施例について、図１０を参照して説明する。例えば、プロセッサ・リソースを割当て解除するために、現在の割当て済みリアルタイム・レート５０６から入力データ・レートが引かれる（ステップ１０００）。従って現在のレートは、これらのリソースが他のデータ・ストリームの配信に利用できることを示す。その後、割当て解除は完了する。
【００６５】
本発明に従って、リアルタイム・データ・ストリームの配信時に、クライアント１１４は表示の一時停止を決定することができる。その場合、リアルタイム・サーバがシステム・リソース・マネージャ１１８の一時停止機能を起動し、リアルタイム・データ・ストリームを表示中のクライアント１１４が、例えばビデオの表示を一時停止したことを示す。一時停止したストリームは、プロセッサの消費量には関係しないが、それらに必要なプロセッサ時間は依然として予約されている。従って、一時停止したストリームのデータ・レートは計算に用いられる。一時停止機能の実施例については、図１１を参照して詳述する。また再開機能についても述べる。
【００６６】
図１１を参照する。最初、クライアント１１４がリアルタイム・データ・ストリームの配信を一時停止しているか、又は一時停止の後に配信を再開しているか否かが決定される（ステップ１１００）。もし、このオプションが一時停止であれば、入力データ・レートが現在の一時停止リアルタイム・レート５１０に追加される（ステップ１１０２）。その後、本発明の一時停止機能は完了する（ステップ１１０４）。
【００６７】
他方、オプションが再開であれば、現在の一時停止データ・レート５１０から入力データ・レートが引かれ（ステップ１１０６）、再開機能は完了する（ステップ１１０４）。
【００６８】
上に述べたのは、選択された量のリソースをリアルタイム・サーバに提供し、また、システムの他のタイプのアプリケーション及び他の作業を処理するため、選択された量のリソースが予約されることを保証する、プロセッサ・リソース管理機能である。
【図面の簡単な説明】
【図１】本発明の管理機能を取り入れて使用するコンピュータ装置の１つの例を示す図である。
【図２】本発明に従って用いられるディスパッチ優先度の１つの例を示す図である。
【図３】本発明に従って、リアルタイム・アプリケーションの処理に関連して用いられるロジックの実施例を示す図である。
【図４】本発明に従って、図３の識別機能に関連付けられるロジックの１つの例を示す図である。
【図５】本発明に従って用いられるプロセッサ利用状況データの１つの例を示す図である。
【図６】本発明に従って、リアルタイム・アプリケーションにプロセッサ・リソースを割当てるために用いられるロジックの実施例を示す図である。
【図７】本発明に従って、リアルタイム・アプリケーションを実行する際に用いられるロジックの実施例を示す図である。
【図８】本発明に従って、図７の実行手順のキャッピング調整機能を実行する際に用いられるロジックの実施例を示す図である。
【図９】本発明に従って、図７の実行手順のキャッピング調整機能を実行する際に用いられるロジックの実施例を示す図である。
【図１０】本発明に従って、リアルタイム・アプリケーションに割当てられるリソースの割当てを解除する際に用いられるロジックの実施例を示す図である。
【図１１】本発明に従って、リアルタイム・アプリケーションの実行を一時停止／再開する際に用いられるロジックの実施例を示す図である。
【符号の説明】
１０２  オペレーティング・システム
１０４  リアルタイム・サーバ・アプリケーション
１０６  非リアルタイム・アプリケーション
１０８  作業単位
１１６  作業負荷マネージャ
１１８  システム・リソース・マネージャ
１２０  ディスパッチャ
１２２  作業単位制御ブロック
１３４  プロセッサ消費最大値
１３６  プロセッサ消費限度値
１３８  プロセッサ利用状況データ
１４０  キャップ・スライス・パターン
１４６  ユーザ性能目標
１４８  ユーザ性能目標の相対的重要度
１５０  ディスパッチ優先度
１５２  リアルタイム・サーバ・ビット
１５４  ディスパッチ優先度
１５６  優先使用ビット
１６０  キャップ・ビット
【図１】
0003547976.tif 000002
【図２】
0003547976.tif 000003
【図３】
0003547976.tif 000004
【図４】
0003547976.tif 000005
【図５】
0003547976.tif 000006
【図６】
0003547976.tif 000007
【図７】
0003547976.tif 000008
【図８】
0003547976.tif 000009
【図９】
0003547976.tif 000010
【図１０】
0003547976.tif 000011
【図１１】
0003547976.tif 000012