JPH10289116A

JPH10289116A - プロセッサ・リソース管理装置

Info

Publication number: JPH10289116A
Application number: JP10053657A
Authority: JP
Inventors: K Ayrert Catharin; キャサリン・ケイ・アイラート; B Wakom Peter; ピーター・ビィ・ワコム
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1997-03-28
Filing date: 1998-03-05
Publication date: 1998-10-27
Anticipated expiration: 2018-03-05
Also published as: US6654780B1; JP3547976B2

Abstract

(57)【要約】【課題】リアルタイム・データ・ストリームを割込み
なくスムーズに配信する一方、システムで同時に実行さ
れる他の作業に所望の量のプロセッサ・リソースを提供
する装置を提供する。【解決手段】ある量のプロセッサ・リソースがコンピ
ュータ装置のリアルタイム・アプリケーションに割当て
られる。この量は、リアルタイム・アプリケーションの
グループに選択された限度を超えない。グループはリソ
ースが割当てられたリアルタイム・アプリケーションを
含む。選択された量のプロセッサ・リソースは、装置の
他のタイプのアプリケーションや作業を実行するため、
引き続き利用できる。リアルタイム・アプリケーション
の処理の間に、プロセッサ・リソースの使用量は選択さ
れた最大値を超えず、よってプロセッサ・リソースがリ
アルタイム・アプリケーションによって独占されず、装
置の他のタイプの作業を処理できるようにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的にはコンピ
ュータ装置のプロセッサ・リソース管理に関し、特に、
他のタイプのアプリケーションや作業を同じシステム上
で同時に実行できるようにしながら、割込みのないスム
ーズなリアルタイム・データ・ストリームを提示するの
に適したプロセッサ・リソースを提供することに関す
る。

【０００２】

【従来の技術】コンピュータ環境では、質のよいリアル
タイム・データ・ストリームを配信することは大きな課
題である。リアルタイム・データ・ストリームには、例
えば、ビデオ、オーディオ、及びマルチメディア等のデ
ータ・ストリームが含まれる。現在、リアルタイム・デ
ータ・ストリームを配信するためのアプローチは、構成
管理と高ディスパッチ優先度の２つがある。それぞれに
ついて説明する。

【０００３】構成管理アプローチでは、リアルタイム・
データ・ストリームの配信にサーバが専用される。特に
サーバは、リアルタイム・データ・ストリームを所与の
レートで配信するために、充分な容量を持たせて構成さ
れる。サーバはリアルタイム・データ・ストリームの配
信専用なので、リアルタイム・ストリームはシステム・
リソースを独占し、他のタイプの作業については、残る
としてもごくわずかなリソースしか残らない。

【０００４】高ディスパッチ優先度アプローチの場合、
リアルタイム・アプリケーションはディスパッチ優先度
がかなり高い状態で実行される。この手法は専用システ
ムで実行する必要はないが、この場合でも、リアルタイ
ム・アプリケーションをかなり高い優先度で実行するこ
とによって、実行に充分なリソースをシステムの他の作
業が受け取ることに対する制御あるいは保証はない。

【０００５】

【発明が解決しようとする課題】従って、リアルタイム
・データ・ストリームを割込みなくスムーズに配信する
一方、システムで同時に実行される他の作業に所望の量
のプロセッサ・リソースを提供する機構が求められる。
またリアルタイム・データ・ストリームに割当てられる
リソースの量に限度を設け、これにより、選択されたリ
ソース量を非リアルタイム作業に利用できる管理機構も
求められる。

【０００６】

【課題を解決するための手段】従来技術の欠点は、コン
ピュータ装置のプロセッサ・リソースを管理する装置を
提供することにより克服され、他の利点も与えられる。
この装置は、１つの例では、コンピュータ装置のリアル
タイム・アプリケーションに、ある量のプロセッサ・リ
ソースが割当てられるようにされたリソース・マネージ
ャを含む。この量は、１つ以上のリアルタイム・アプリ
ケーションのグループのために選択された限度を超える
ことはない。選択された量のプロセッサ・リソースは、
コンピュータ装置の少なくとも１つの非リアルタイム・
アプリケーションに引き続き利用できる。また装置は、
リアルタイム・アプリケーションを処理する手段を含
む。

【０００７】本発明の他の実施例で、処理手段は、リア
ルタイム・アプリケーションのグループのために選択さ
れたプロセッサ・リソースの最大量をリアルタイム・ア
プリケーションが超えることを防ぐ手段を含む。

【０００８】また他の実施例では、リソース・マネージ
ャは、リアルタイム・データ・レートを配信するため
の、所与の時間内の最大サービス・コストを求めるよう
にされた確認ユニット、リアルタイム・アプリケーショ
ンのリアルタイム・データ・ストリームを配信するサー
ビス・レートを計算するようにされた計算ユニット、及
びサービス・レートが限度内にあるときに、充分な量
のプロセッサ・リソースがリアルタイム・データ・スト
リームに利用できることを指定するようにされたインジ
ケータを含む。

【０００９】本発明の他の側面では、コンピュータ装置
のプロセッサ・リソースを管理する装置が提供される。
１つの例として、この装置はコンピュータ装置のリアル
タイム・アプリケーションのグループに割当て可能な、
選択された量のプロセッサ・リソース、及びコンピュー
タ装置の非リアルタイム・アプリケーションに予約され
た、選択された量のプロセッサ・リソースを含む。

【００１０】本発明の管理機能の利点は、リアルタイム
・アプリケーションによって利用される、ある量のプロ
セッサ・リソースを選択でき、選択された量のリソース
を非リアルタイム・アプリケーションに予約できること
である。また本発明の管理機能により、リアルタイム・
アプリケーションがコンピュータ装置の制限を超過させ
ることはなくなる。リアルタイム・アプリケーション
は、割込みなくスムーズに実行でき、他のタイプの作業
もシステム上で処理できる。

【００１１】

【発明の実施の形態】本発明に従い、リアルタイム・ア
プリケーション、及びバッチ処理、トランザクション処
理等、他のタイプのアプリケーションも、汎用システム
（つまり非専用システム）で同時に実行できる。特にリ
アルタイム・アプリケーションには、リアルタイム・ア
プリケーションがシステムの制限を超過させないよう
に、一定量のプロセッサ・リソースが与えられる。他の
タイプのアプリケーション（つまり非リアルタイム・ア
プリケーション）にも、ある量のプロセッサ・リソース
が処理のため与えられる。非リアルタイム・アプリケー
ションは、ここで用いているとおり、例えば、バッチ・
アプリケーション、トランザクション処理アプリケーシ
ョン、非リアルタイムにシステムで実行される他の作業
等、リアルタイムに実行されない任意のアプリケーショ
ンを含む。

【００１２】本発明の機能を取り入れて使用する非専用
コンピュータ装置の１つの例を図１に示す。以下、これ
について詳しく説明する。

【００１３】ある実施例では、コンピュータ装置１００
にオペレーティング・システム１０２、少なくとも１つ
のリアルタイム・サーバ・アプリケーション１０４、及
び他のタイプのアプリケーション１０６が含まれる。リ
アルタイム・サーバ・アプリケーション１０４はリアル
タイム・データを配信し、作業単位１０８を含む。作業
単位は、例えば、コンピュータ装置の目的である有益な
作業を行うアプリケーション・プログラムである。他の
タイプのアプリケーション１０６は、例えば、バッチ・
アプリケーション１１０とトランザクション処理アプリ
ケーション１１２を含む。これも作業単位を含む。リア
ルタイム・サーバ・アプリケーションとトランザクショ
ン処理アプリケーションは、例えば、コンピュータ装置
１００に接続されたワークステーション側のサービング
・クライアント１１４である。

【００１４】オペレーティング・システム１０２は、１
つの例として、International Business Machines Corp
orationのＭＶＳ（多重仮想記憶）オペレーティング・
システムである。ただしこれは１つの例にすぎない。他
のオペレーティング・システムも本発明の主旨または範
囲から逸脱することなく使用できる。ある実施例では、
オペレーティング・システム１０２は作業負荷マネージ
ャ１１６、システム・リソース・マネージャ１１８、デ
ィスパッチャ１２０、及び作業単位制御ブロック１２２
を含む。以下、それぞれについて詳しく説明する。

【００１５】作業負荷マネージャ１１６はコンピュータ
装置１００の作業負荷を管理する。作業負荷マネージャ
のタスクの１つは、本発明の管理機能によって用いられ
るある値を入力としてコンピュータ装置に読込むことを
含む。例えば、作業負荷マネージャはプロセッサ消費限
度値とプロセッサ消費最大値を読込む。これらの値は、
リアルタイム・アプリケーション（つまりリアルタイム
・データを配信するアプリケーション）及び非リアルタ
イム・アプリケーションに割当てられるリソースの量を
確認するために用いられる。１つの例として、これらの
値はシステム管理者によって設定される。

【００１６】プロセッサ消費限度値はそれぞれ、例えば
リアルタイム・アプリケーションに割当てることのでき
るプロセッサ・リソースの量を指定する。この値は、シ
ステムの他のタイプのアプリケーションや作業が同時に
実行できるように選択される。後述するように、異なる
リアルタイム・アプリケーションを異なる限度値に関連
付ける、または同じ限度値にすることができる。同様
に、プロセッサ消費限度値は非リアルタイム・アプリケ
ーションに関連付けることができる。

【００１７】プロセッサ消費最大値はそれぞれ、例えば
リアルタイム・アプリケーション、または非リアルタイ
ム・アプリケーションによって使用できるプロセッサ・
リソースの量に対するキャップを指定する。ある実施例
で、これらの値は限度値よりも大きい。これは、処理の
間に、データ・ストリームの配信に一時的なサージがあ
り得、これにより割当て済みリソースの量が不足すると
されるからである。従って、最大値はそれぞれ、処理側
アプリケーションが、プロセッサ消費限度値により指定
されたものより少し多くプロセッサを消費する必要のあ
る場合を考慮してバッファを与える。アプリケーション
によって消費されるリソースの量はこのキャップを超え
ない。これはシステムに追加される作業に、選択された
量のプロセッサ・リソースが与えられることを保証す
る。後述するように、異なるアプリケーションを異なる
最大値に関連付けることができ、または同じ最大値にす
ることができる。

【００１８】ある実施例で、プロセッサ消費限度値と最
大値はプロセッサ・サービス単位として表される。ただ
しこれは１つの例にすぎない。当業者には明らかなよう
に、他の測定単位も、本発明の主旨または範囲から逸脱
することなく選択できる。

【００１９】作業負荷マネージャは、限度値と最大値の
読込みに続いて、各プロセッサの消費限度値と消費最大
値のペアを取り、アプリケーションの個々の作業単位が
割当てられるリソース・グループを設定する。これによ
り、異なる限度値と最大値を異なるアプリケーションに
指定できる。例えば、リアルタイム・アプリケーション
Ａ、Ｂをリソース・グループ１に割当て、限度値を５０
０、最大値を５５０とすることができる。また、リアル
タイム・アプリケーションＣがリソース・グループ２に
割当てられ、限度値２００、最大値２１０が取られる。
同様に、非リアルタイム・アプリケーションＤ、Ｅがリ
ソース・グループ３に割当てられ、限度値２５００とさ
れ、最大値は使用されない。これらの例で、リアルタイ
ムと非リアルタイムのアプリケーションは別々のグルー
プである。これは１つの例にすぎない。他の実施例で、
グループにタイプの異なるアプリケーションを追加する
こともできる。限度値と最大値はグループに対して選択
される。従ってグループは全体としてこれらの値を超え
ることはない。

【００２０】各リソース・グループは、リソース・グル
ープ・テーブル・エントリ１３０によってオペレーティ
ング・システムに割当てられたメモリで表される。ある
実施例で、リソース・グループ・テーブル・エントリ１
３０は次を含む。（ａ）リソース・グループ名１３２。作業負荷マネージ
ャへの入力値であり、このリソース・グループ・エント
リに対応したリソース・グループの名前を示す。（ｂ）プロセッサ消費最大値１３４。これは先に述べた
ように、このリソース・グループのアプリケーションに
よって消費されることが許可されたプロセッサ・リソー
スの量に対するキャップを指定する入力値である。（ｃ）プロセッサ消費限度値１３６。これは先に述べた
ように、このグループのアプリケーションに割当てるこ
とのできるプロセッサ・リソースの量を指定する入力値
である。（ｄ）プロセッサ利用状況データ１３８。これは、後述
するさまざまな測定データ及び計算データを含む。（ｅ）キャップ・スライス・パターン１４０。これは、
詳細は後述するが、リソース・グループの作業単位にキ
ャップを付けるときの特定タイム・スライスを示す計算
値である。

【００２１】前記の他に、作業負荷マネージャ１１６
は、相対的重要度を含めて、コンピュータ装置１００の
性能目標を入力として読込み、個々の作業単位（例え
ば、リソース・グループの作業単位）が割当てられるユ
ーザ性能目標クラスを設定する。性能目標は、リアルタ
イム及び非リアルタイムの両方のアプリケーションに関
連付けられる。目標クラスがリソース・グループに関連
付けられる可能性は五分五分である。リソース・グルー
プの一部ではない作業単位も目標クラスの一部になり得
る。また、クラスは２つ以上をリソース・グループに関
連付けることができる。

【００２２】性能目標とユーザ性能目標のクラスについ
ては、J．D．Amanらによる１９９５年１２月５日付米国
特許番号第５４７３７７３号、"Apparatus and Method
forManaging A Data Processing System Workload Acco
rding to Two or More Distinct Processing Goal Type
s"、及びC．K．Eilertらによる１９９５年２月３日付米
国特許出願番号第０８／３８３０４２号、"Multi-Syste
m Resource Capping"を参照されたい。

【００２３】ユーザ性能目標クラスはそれぞれ、クラス
・テーブル・エントリ１４２によってオペレーティング
・システムに割当てられたメモリで表される。クラス・
テーブル・エントリ１４２は、例えば次を含む。（ａ）リソース・グループ名１４４。これはリソース・
グループがあると仮定して、ユーザ性能目標クラスが属
するリソース・グループを指定する入力値である。リソ
ース・グループがなければ、このフィールドはブランク
のままである。（ｂ）ユーザ性能目標１４６。これはクラスの特定の性
能目標を示す入力値である。性能目標の例として所望の
応答時間がある。（ｃ）ユーザ性能目標の相対重要度１４８。これもコン
ピュータ装置に対するこの目標の重要度を指定する入力
値である。（ｄ）ディスパッチ優先度１５０。これはコントローラ
１５８によってセットされる。このクラスの作業単位が
（全体として）ディスパッチされる順序を、システムの
他のクラスに対して示す。（ｅ）リアルタイム・サーバ・ビット１５２。これはこ
のクラスの作業単位がリアルタイム・サービング・アプ
リケーションの一部かどうかを示す。このビットは、後
述するように本発明に従ってセットされる。

【００２４】オペレーティング・システム１０２は、作
業負荷マネージャの他にシステム・リソース・マネージ
ャ１１８を含む。システム・リソース・マネージャはオ
ペレーティング・システムのコンポーネントであり、コ
ンピュータ装置のリソース（ＣＰＵ利用率等）を管理す
る。ある実施例でシステム・リソース・マネージャ１１
８はＳＧＤＰＣ（system goal driven performance con
troller）１５８を含む。ＳＧＤＰＣは、後述するよう
に、オペレーティング・システムに適応性と自己調整性
を持たせるよう、性能問題の増分検出と補正を行うた
め、フィードバック・ループを与える。

【００２５】ＳＧＤＰＣの実施例は、J．D．Amanらによ
る１９９５年１２月５日付米国特許番号第５４７３７７
３号、"Apparatus and Method for Managing A Data Pr
ocessing System Workload According To Two or More
Distinct Processing Goal Types"、C．K．Eilertらに
よる１９９５年２月３日付米国特許出願番号第０８／３
８３０４２号、"Multi-System Resource Capping"、及
びC．K．EilertとP．Yocomによる１９９５年２月３日付
米国特許出願番号第０８／３８３１６８号、"Apparatus
and Method for Managing A Distributed Data Proces
sing System Workload According To A Plurality of D
istinct Processing Goal Types"を参照されたい。

【００２６】コントローラ１５８の、特に本発明に関わ
る他の詳細について、ここで詳しく説明する。コントロ
ーラ１５８は、本発明に従って、本発明のプロセッサ利
用状況データの処理、ユーザ性能目標の達成を管理する
ための性能インデックスの計算とシステム・リソース管
理の調整、及びリアルタイム・アプリケーションがシス
テムの制限を超過させないためのプロセッサ・リソース
消費量のキャッピングの調整を担当する。以下、それぞ
れについて説明する。

【００２７】オペレーティング・システム１０２は、さ
らにディスパッチャ１２０を含む。ディスパッチャ１２
０は、コンピュータ装置１００によって次に実行される
作業単位を選択するために用いられる。各作業単位は作
業単位制御ブロック（ＷＵＣＢ）１２２の１つによって
表される。作業単位制御ブロックはそれぞれオペレーテ
ィング・システム１０２に割当てられたメモリに格納さ
れ、例えば、次の３つのディスパッチ制御フィールドを
含む。（ａ）ディスパッチ優先度フィールド１５４。これはデ
ィスパッチャがディスパッチ作業に取り掛かる順序をデ
ィスパッチャ１２０に示す。ディスパッチ優先順位の１
つの例を図２に示す。図２に示すように、ある実施例で
最大のディスパッチ優先度はオペレーティング・システ
ム、ディスパッチャ、システム・リソース・マネージ
ャ、及びＳＧＤＰＣに予約され、次に最大の優先度は、
リアルタイム・アプリケーションの作業単位及びシステ
ム・ファンクションのために使われる。トランザクショ
ン及びバッチ処理のアプリケーションの作業単位には複
数の低い優先度が予約される。これら複数の低優先度
は、先に述べた特許及び特許出願に詳しく述べられてい
るとおり、ＳＧＤＰＣの操作によって割当てられる。（ｂ）優先使用ビット・フィールド１５６。これは関連
付けられた作業単位を、レディ状態になってすぐにディ
スパッチ対象として考慮するかどうかをディスパッチャ
に示す。（ｃ）キャップ・ビット・フィールド１５８。これは関
連付けられた作業単位をディスパッチできるかどうかを
ディスパッチャに示す。このビットは、ここで詳しく述
べているように、作業単位の特定のグループのために許
可されたプロセッサ実行時間の量を制御するために用い
られる。

【００２８】本発明に従って、選択された量のプロセッ
サ・リソース（ＣＰＵ時間等）をリアルタイム・アプリ
ケーションに、また選択された量をシステムの他のタイ
プの作業に提供するため、コンピュータ装置１００のさ
まざまなコンポーネントが用いられる。本発明に従っ
て、リアルタイム・アプリケーションの処理に関連付け
られるロジックの実施例について、図３を参照して詳し
く説明する。

【００２９】図３を参照する。最初、実行したいリアル
タイム・アプリケーションがシステム・リソース・マネ
ージャ１１８に対して自身を識別する（ステップ３０
２）。これによりリソース・マネージャは、リアルタイ
ム・アプリケーションが割込みなくスムーズに処理を行
う一方、システムの他の作業の制限を超過させないため
充分なリソースを持つのに必要な調整を行うことができ
る。システム・リソース・マネージャに対してアプリケ
ーションを識別する手順の１つを、図４を参照して詳し
く説明する。図４に示したファンクションは、１つの例
ではシステム・リソース・マネージャ１１８によって実
行される。

【００３０】図４を参照する。１つの例として、最初に
クラス・テーブル・エントリ１４２のディスパッチ優先
度１５０と、識別側リアルタイム・アプリケーションに
関連付けられた各作業単位制御ブロック１２２の優先度
１５４が"次に最大の優先度"に設定される。これはリア
ルタイム・アプリケーションのために指定される（ステ
ップ４０２）。

【００３１】その後、リアルタイム・アプリケーション
のための個々の作業単位制御ブロック１２２の各優先使
用ビット１５６がセットされ、ディスパッチについて関
連付けられた作業単位を、利用できるようになればすぐ
に考慮すべきことがディスパッチャに示される（ステッ
プ４０４）。

【００３２】また、クラス・テーブル・エントリ１４２
のリアルタイム・サーバ・ビット１５２がセットされ、
クラスの作業単位がリアルタイム・サーバであり、ディ
スパッチ優先度が調整されないことがＳＧＤＰＣコント
ローラ１５８に示される（ステップ４０６）。

【００３３】ディスパッチ優先度、全優先使用ビット、
及びリアルタイム・サーバ・ビットのセット後、識別フ
ァンクションは完了する。従って、図３に戻るが、リア
ルタイム・アプリケーションの次のタスクは、リソース
をアプリケーションに割当てることである（ステップ３
０４）。

【００３４】割当て方法の実施例を図５及び図６を参照
して詳しく説明する。図６のロジックはさまざまなプロ
セッサ利用状況データを使用する。プロセッサ利用状況
データについては図５を参照して詳しく説明する。デー
タの説明の後、割当てロジックの実施例について説明す
る。

【００３５】図５を参照する。本発明のプロセッサ利用
状況データ１３８の１つの例は次を含む。（ａ）グループ・サービス・レート５０２。これはグル
ープの作業単位によって消費された現在のサービス（Ｃ
ＰＵ消費等）を示す。このレートは普通はサービス単位
／秒で表されるが、これは必要ではない。（ｂ）前の割当て済みリアルタイム・レート５０４。こ
れは性能コントローラが起動されたとき（例えば１０秒
毎）ＳＧＤＰＣによって埋められる。性能コントローラ
は現在の割当て済みリアルタイム・レート（後述）を前
の割当て済みリアルタイム・レートにコピーする。（ｃ）現在の割当て済みリアルタイム・レート５０６。
これはグループのリアルタイム・データ・ストリームを
配信するために現在割当てられている容量単位の量（Ｋ
Ｂ／秒等）を表す。ディスクから通信ネットワークへデ
ータのバイトを送るプロセッサ・コストは、容量単位と
してＫＢ／秒を使用する定数に充分近く、ＫＢ／秒はリ
アルタイム・サービング・アプリケーションには有意義
な単位である。リアルタイム・サービング・アプリケー
ションは容量をＫＢ／秒で要求する。現在割当てられて
いるリアルタイム・レートは、次に述べる割当てファン
クションと割当て解除ファンクションによって埋められ
る。（ｄ）前の一時停止リアルタイム・レート５０８。これ
はコントローラ１５８が起動したとき（例えば１０秒
毎）ＳＧＤＰＣコントローラ１５８によって埋められ
る。コントローラ１５８は現在の一時停止リアルタイム
・レート（後述）を前の一時停止リアルタイム・レート
のフィールドにコピーする。（ｅ）現在の一時停止リアルタイム・レート５１０。こ
れはグループの一時停止した任意のリアルタイム・デー
タ・ストリームのデータ・レートの和を含む（後述）。（ｆ）割当て済みリアルタイム・レート・ウィンドウ５
１２。これは、例えば１８のウィンドウ枠を含むデータ
のウィンドウである。特に割当て済みリアルタイム・レ
ートは、移動するタイム・ウィンドウで維持される。移
動するタイム・ウィンドウは、例えば最近の３分として
定義される。１８０秒のウィンドウは、それぞれが１０
秒である１８のインターバル（１８のウィンドウ枠とい
う）に分けられ、１８の要素配列として実現される。割
当て済みリアルタイム・レート・ウィンドウ枠は、コン
トローラ１５８が１０秒毎に起動されたとき、前の１０
秒間隔の間にリアルタイム・サービング・アクティビテ
ィがあった場合はコントローラ１５８によって埋められ
る。割当て済みリアルタイム・ウィンドウ枠は、前の割
当て済みリアルタイム・レートと現在の割当て済みリア
ルタイム・レートの平均を取ることによって計算され
る。（ｇ）リアルタイム・サービス・レート・ウィンドウ５
１４。もう１つのデータ・ウィンドウであり、例えば１
８のウィンドウ枠を含む。リアルタイム・サービス・レ
ートは、リアルタイム・データ・ストリームを配信する
リアルタイム・アプリケーションの作業単位によって消
費されたプロセッサ・サービスを表す。リアルタイム・
サービス・レート・ウィンドウ枠は、コントローラ１５
８が１０秒毎に起動されたとき、前の１０秒間隔の間に
リアルタイム・サービング・アクティビティがあった場
合に、コントローラ１５８によって埋められる。リアル
タイム・サービス・レート・ウィンドウ枠の値はグルー
プ・サービス・レートのフィールドからコピーされる。（ｈ）リアルタイム一時停止レート・ウィンドウ５１
６。これは第３のデータ・ウィンドウで、これも例えば
１８のウィンドウ枠を含む。リアルタイム一時停止レー
トは、現在一時停止しているこのグループのリアルタイ
ム・データ・ストリームを表すデータ・レートである。
他の２つのデータのウィンドウと同様に、一時停止レー
ト・ウィンドウ枠は、コントローラ１５８が１０秒毎に
起動されるとき、前の１０秒間隔の間にリアルタイム・
サービング・アクティビティがあった場合は、コントロ
ーラ１５８によって埋められる。一時停止リアルタイム
・レート・ウィンドウ枠の値は、前の一時停止リアルタ
イム・レートと現在の一時停止リアルタイム・レートの
平均を取ることによって計算される。（ｉ）リアルタイム・ウィンドウ枠インデックス５１
８。これはウィンドウ枠配列要素の現在のインデックス
を表す。現在の１０秒間隔のデータは、現在のウィンド
ウ枠インデックスによってインデックスが付けられたウ
ィンドウ枠配列要素に格納される。各ウィンドウ配列の
１８の配列要素がローテーション方式で用いられる。１
８個目の要素が用いられた後、次の時間間隔のデータが
第１要素に格納され、その要素の古いデータと置き換え
られる。リアルタイム・ウィンドウ枠インデックスは、
前の１０秒間隔の間にリアルタイム・サービング・アク
ティビティがあった場合に、コントローラ１５８によっ
て進められる。リアルタイム・サービング・アクティビ
ティがないときはインデックスは進められない。これに
より、再びリアルタイム・サービング・アクティビティ
が開始されたときに用いられるよう、ＫＢ／秒当たりの
前のサービス・コストが保存される。

【００３６】先に述べたとおり、前記のプロセッサ利用
状況データは、本発明の割当てファンクションの実行時
に用いられる。一般的に、システム・リソース・マネー
ジャの割当てファンクションは、リアルタイム・データ
・ストリームを配信するためのプロセッサ容量を割当
て、保証するために、リアルタイム・サーバによって起
動される。割当てファンクションの入力値は、リアルタ
イム・ストリームのＫＢ／秒データ・レートである。割
当てのとき、リアルタイム・データ・ウィンドウ枠がス
キャンされ、ウィンドウの１８の枠で転送されたＫＢ／
秒当たりの最大プロセッサ・サービス・コストが検出さ
れる。次にこの値により、新しいストリームのサービス
要件が確認される。その後、システム管理者によって指
定されたグループ・サービス限度１３６の範囲内で、必
要なプロセッサ容量が利用できるかどうか確認される。
割当てファンクションの実施例の詳細については、さら
に図６を参照して説明する。

【００３７】図６を参照する。最初、ウィンドウ枠イン
デックス５１８がセットされ、ウィンドウ枠をスキャン
するときの最初のウィンドウ枠がポイントされて、高レ
ートと呼ばれる変数が０に初期化される（ステップ６０
０）。その後、ＫＢ／秒（データ・レート）を配信する
サービス・コストが次のように計算される。

【数１】リアルタイム・サービス・レート・ウィンドウ
５１４÷（割当て済みリアルタイム・レート・ウィンド
ウ５１２−リアルタイム一時停止レート・ウィンドウ５
１６）（ステップ６０２）

【００３８】ステップ６０２で計算された値は現在のサ
ービス・レートであり、これはまた新しいレートと呼ば
れる。新しいレートはセーブされた高レートに対してチ
ェックされる（照会６０４）。割当て済みリアルタイム
・レート・ウィンドウ枠５１２にセーブされた新しいレ
ートが高レートより大きい場合、高レートは新しいレー
トにセットされる（ステップ６０６）。新しい高レート
をセーブした後、または現在のサービス・レートが高レ
ートより小さいか等しい場合は、さらに別のウィンドウ
枠があるかどうか確認される（照会６０８）。特にウィ
ンドウ枠インデックスが１８と比較され、１８より小さ
い場合は、リアルタイム・ウィンドウ枠インデックス５
１８が１つ増分される（ステップ６１０）。次に制御は
ステップ６０２の"ウィンドウ枠のレート計算"に移る。

【００３９】他方、スキャンすべきウィンドウ枠が他に
ない場合は、新しいリアルタイム・データ・ストリーム
を配信するのに必要なサービスが次のように計算され
る。

【数２】新しいストリームのＫＢ×ウィンドウのＫＢ当
たりの最大サービス・レート

【００４０】ここで新しいストリームのＫＢは入力値、
最大サービス・レートは、高レート変数に格納されたレ
ートである。

【００４１】必要なサービスの量が計算された後、グル
ープ・サービス限度１３６内でサービス量が利用できる
かどうか確認される（照会６１４）。充分な容量が利用
できない場合、不成功を示す戻りコードがセットされ
（ステップ６１６）、割当てファンクションは完了する
（ステップ６１８）。

【００４２】リアルタイム・データ・ストリームを配信
するのに充分な容量がある場合は、新しいストリームの
レートが現在の割当て済みリアルタイム・レート５０６
に追加され（ステップ６２０）、成功を示す戻りコード
がセットされる（ステップ６２２）。その後、割当てフ
ァンクションは完了する（ステップ６１８）。

【００４３】図３に戻る。割当てファンクションが実行
された後、リアルタイム・サービング・アプリケーショ
ンを実行でき、これによりリアルタイム・データ・スト
リームが配信される（ステップ３０６）。

【００４４】リアルタイム・サービング・アプリケーシ
ョン及び非リアルタイム・アプリケーションの実行時、
ＳＧＤＰＣコントローラ１５８がシステム・リソースの
利用状況を監視し、監視内容をもとに制御を調整する。

【００４５】１つの例として、性能コントローラは、例
えばユーザ性能目標の達成を管理するため、ディスパッ
チ優先度等、システム・リソース制御を調整すること
（図７、ステップ７００）、及び特定のリソース・グル
ープによるリソース消費を制限するため、それらのグル
ープのキャッピングを調整すること（ステップ７０２）
を含めて、２つのタスクを実行する。それぞれのタスク
についてここで詳しく説明する。

【００４６】最初のタスク、システム・リソース制御の
調整（ステップ７００）は、１つの例として、システム
のアプリケーションの実行時にある間隔で実行される。
ある実施例で、コントローラ１５８は１０秒毎に起動さ
れ、システム制御を調整する必要があるかどうか確認す
る。

【００４７】特にコントローラ１５８の制御調整機能
は、性能目標の達成度を測定し、性能を改良する必要の
あるユーザ性能目標クラスを選択し、関連付けられた作
業単位のシステム制御パラメータ（つまりディスパッチ
優先度等の被制御変数）を変更することによって選択さ
れたユーザ性能目標クラスの性能を改良する。しかしデ
ィスパッチ優先度等の特定パラメータを変更する前に、
性能コントローラ１５８は、本発明に従って、リアルタ
イム・サーバ・ビット１５２をチェックし、アプリケー
ションがリアルタイム・サーバ・アプリケーションかど
うか確認する。ビットがオン、つまりリアルタイム・デ
ータ・ストリームの配信を示す場合は、クラスのディス
パッチ優先度（優先度１５０）及び適応できる各作業単
位のディスパッチ優先度（優先度１５４）は変わらない
ままである。これによりリアルタイム・データ・ストリ
ームに一定量のリソースが保証される。

【００４８】リアルタイム・サーバ・ビットがオフのと
き、ディスパッチ優先度は調整できる。非リアルタイム
・アプリケーションに対するコントローラ１５８の処理
については、C．K．Eilertらによる１９９５年２月３日
付米国特許出願番号第０８／３８３０４２号、"Multi-S
ystem Resource Capping"を参照されたい。しかし本発
明に従って、非リアルタイム・サービング作業単位に利
用できるプロセッサ容量は、プロセッサ総容量から、リ
アルタイム・サービング作業単位に保証され、前記作業
単位によって用いられるプロセッサ容量を引いたもので
ある。

【００４９】２つ目のタスク、キャッピングの調整（ス
テップ７０２）も、先に述べた"Multi-System Resource
Capping"で説明されているものと同様に働く。キャッ
ピング調整ファンクションは、リソース消費量を、リソ
ース・グループ最大値１３４で当該リソース・グループ
に指定された最大値に制限するため、各リソース・グル
ープに割当てられた作業単位をディスパッチ不能（キャ
ップ済み）にする時間を決定する。

【００５０】特に、時間の長さ（長さはプロセッサ速度
に依存）は、例えば６４間隔等、いくつかの間隔に分け
られ、キャッピング調整ファンクションは、各リソース
・グループの作業単位にキャップを付ける間隔の個数を
計算する。次に６４間隔のそれぞれに対応し、その間隔
でリソース・グループにキャップを付けるかどうかを示
すインジケータをセットする。これらのインジケータは
キャップ・スライス・パターン１４０を形成する。キャ
ップ・ビットは、"Multi-System Resource Capping"に
述べられているように、６４個の間隔全体に比較的均一
に分散される。

【００５１】６４の間隔のそれぞれでシステム・リソー
ス・マネージャのキャップ・ビット操作ファンクション
が起動され、キャップ・ビット・パターンがチェックさ
れる。これにより、どのリソース・グループにキャップ
を付けるか確認され、作業単位制御ブロックにキャップ
・ビットがセットされる。キャップ・ビットはディスパ
ッチャ１２０によって問い合わせられ、作業単位をディ
スパッチできるかどうか確認される。本発明では、シス
テム管理者が、リアルタイム・サービング・リソース・
グループの最大値を指定し、キャッピング・ファンクシ
ョンは、リアルタイム・サービング・アプリケーション
が、指定された最大プロセッサ容量以上を消費しないこ
とを保証する。

【００５２】キャッピング・ファンクションの実施例に
ついて、図８及び図９を参照して詳しく説明する。まず
図８を参照する。最大値を有する、従って処理が必要で
あるリソース・グループが他にあるかどうか確認される
（照会８００）。処理すべきグループが他にない場合
は、ファンクションは完了し、制御はステップ８０２に
移る。

【００５３】処理すべきリソース・グループが他にある
場合は、リソース・グループにキャップ・スライスが現
在セットされているか、または現在、指定最大値以上の
プロセッサ時間を消費しているかどうか確認される（ス
テップ８０４）。このチェックの結果が否定的なら、制
御はステップ８００に移り、次のリソース・グループが
処理される。

【００５４】他方、キャップ・スライスが現在セットさ
れているか、またはリソース・グループが最大値を超え
ている場合は、制御はステップ８０６に移り、リソース
・グループのキャップ・スライスが計算される。

【００５５】ステップ８０６で、許可されるプロセッサ
・サービス単位の値（つまり最大値１３４）が、次のス
テップでキャップ・スライスの値に変換される。１．許可される非キャップ・スライスの値を次のように
計算する。

【数３】非キャップ・スライス＝ＳＡ＊（ＴＳＬＯＷ−
ＣＳＬＯＷ）／ＳＥＲＯＷ

【００５６】ＳＡ − 許可されたプロセッサ・サービ
ス単位（つまり最大値）ＴＳＬＯＷ − ウィンドウの総スライス数（例えば６
＊６４＝３８４、定数）ＣＳＬＯＷ − キャップ・スライス・ウィンドウでキ
ャップが付いたスライスの値（後述）ＳＥＲＯＷ − サービス・ウィンドウで消費されたプ
ロセッサ・サービス単位（後述）キャップ・スライス・ウィンドウは、例えば６枠ウィン
ドウであり、例えばそれぞれ１０秒である。各ウィンド
ウ枠はその枠のキャップ付きスライスの値を保持する。
サービス・ウィンドウも、例えば６枠ウィンドウで、各
枠が１０秒で測定されたサービスを保持する。キャップ
・スライス・ウィンドウとサービス・ウィンドウは、キ
ャッピング・インデックスにより１から始めてインデッ
クスが付けられる。増分は１で、６に達すると１に戻
る。キャップ・スライス・ウィンドウ、サービス・ウィ
ンドウ、及びキャッピング・インデックスは、プロセッ
サ利用状況データ１３８の一部である（しかしこれらは
図５には示していない）。２．非キャップ・スライスが計算して０になる場合は、
これを１にセットする。時間の１００％にキャップを付
けない。３．キャップ・スライスを総スライス数（６４）から非
キャップ・スライスを引いた値に等しくセットする。４．キャップ・スライスの増加が総スライス数の２分の
１より大きい場合は、キャップ・スライス数を総スライ
ス数の２分の１だけ増やす。５．キャップ・スライス数をリソース・グループ・テー
ブル・エントリ１３０に格納する。キャップ・スライス
数は、現在のウィンドウ枠インデックスによってインデ
ックスが付けられたキャップ・スライス配列要素に格納
される。

【００５７】キャップを付けるべきキャップ・スライス
数を求める他に、各リソース・グループのキャップ・ス
ライスが、キャップ・ビット・マニピュレータが問い合
わせをするため、キャップ・スライス・パターンに比較
的均一に分散される。キャップ付きスライス数が最大の
リソース・グループには特定のスライスが最初に割当て
られ、次に最大のキャップ・スライス数を要するリソー
ス・グループが次に処理され、というように、キャップ
付きスライスを有するすべてのリソース・グループが処
理されていく。システム全体で、同じ個数のリソース・
グループ±１グループに、キャップ・スライス・パター
ンの６４個のスライスのそれぞれの間で、特定スライス
が特定のリソース・グループに割当てられるとき、各ス
ライスの間でキャップが付けられるリソース・グループ
の値のカウントを維持することによってキャップが付け
られる。このカウントはテストされ、グループに特定ス
ライスを割当てるかどうか確認される。６４個のすべて
のスライスが割当てられるまでは、２つのリソース・グ
ループにスライスが割当てられることはない。６４個の
すべてのスライスが２回割当てられるまでは、３つのグ
ループにスライスが割当てられることはない。以下同様
である。

【００５８】キャップ・スライスを分散させる実施例に
ついて、図９を参照して詳しく説明する。最初、配列要
素を０にセットすることによってシステム・データ、キ
ャップ・スライス・カウント配列（ＳＣＡ）が初期化さ
れる（ステップ９００）。スライス・カウント配列はカ
ウントの配列である。各エントリはそのスライスの間に
キャップが付けられるグループの値を保持する。キャッ
プ・スライス・カウント配列には６４のエントリがあ
る。各エントリは時間の６４分の１を表す。

【００５９】その後、まだ処理されていないキャップ・
スライスの値が最大のリソース・グループが選択される
（ステップ９０２）。処理すべきリソース・グループが
ない場合は、制御は終了する（ステップ９０４）。処理
すべきリソース・グループが他にある場合は制御はステ
ップ９０６に進む。

【００６０】ステップ９０６でリソース・グループ・デ
ータが初期化される。特にスライス増分（ＳＩ）、スラ
イス・カウント基準（ＳＣＣ）、及びスライス・カウン
ト配列インデックス（ＳＣＡＩ）、が次のように初期化
される。（ＳＩ−１）は、リソース・グループの各キャ
ップ・スライスの間でスキップできるスライス数であ
り、リソース・グループのキャップ・スライスは６４個
の可能なキャップ・スライスで比較的均一に分散され
る。ＳＩは、グループのキャップ・スライス数で分けら
れた６４にセットされる。ＳＣＣはスライス・カウント
配列の最大値にセットされる。スライス・カウント配列
のすべてのカウントが同じ値なら、ＳＣＣに１が追加さ
れる。ＳＣＡＩはキャップ・スライス・パターンの最初
のスライスで始めるため、１にセットされる。

【００６１】次に、ＳＣＡ（ＳＣＡＩ）セルのカウント
が、このグループの基準（ＳＣＣ）に対してチェックさ
れる（照会９０８）。スライスがＳＣＣ個のグループに
割当てられているかがチェックされ、またはすでにこの
グループに割当てられている場合は、制御はステップ９
１０に移り、ここでＳＣＡＩに１が追加される。ＳＣＡ
Ｉが６５に増分されると、これは１にリセットされる
（つまりＳＣＡＩは６４を法とする）。スライス・カウ
ント配列のすべてのカウントが同じ値であれば、ＳＣＣ
に１が追加される。制御は次にステップ９０８に戻る。

【００６２】スライスがＳＣＣより小さい個数のリソー
ス・グループに割当てられていて、処理されている現在
のグループに割当てられていない場合、制御はステップ
９１２に移り、そこでスライスがグループに割当てら
れ、ＳＣＡのスライスの利用状況カウントに１が追加さ
れる。スライスは、リソース・グループのキャップ・ス
ライス・パターン１４０のＳＣＡＩに対応したビットを
セットすることによってリソース・グループに割当てら
れる。制御は次に照会９１４に移る。

【００６３】照会９１４では、現在のリソース・グルー
プに割当てるスライスが他にあるかどうか確認される。
特定のスライスがすべてのグループのキャップ・スライ
スに割当てられている場合、制御はステップ９０２に戻
り、他のリソース・グループがチェックされる。しかし
グループに他の特定のスライスを割当てる必要がある場
合は、制御はステップ９１６に移る。

【００６４】ステップ９１６では、ＳＣＡＩにＳＩが追
加され、次にチェックすべき特定のスライスがセットさ
れる。ＳＣＡＩが６４より大きい場合はＳＣＡＩから６
４が引かれる。ＳＣＡのすべてのカウントが同じ値な
ら、ＳＣＣに１が追加される。次に制御はステップ９０
８に戻る。その後、キャップ・スライスの分散が完了す
る。

【００６５】再び図３の概要図に戻る。識別、割当て、
及び実行のファンクションが完了すると、リアルタイム
・データ・ストリームを配信するために割当てられたプ
ロセッサ・リソースの割当てが、割当て解除ファンクシ
ョンを使用して割当て解除される（ステップ３０８）。
特に、リアルタイム・サーバがシステム・リソース・マ
ネージャの割当て解除ファンクションを起動して、リア
ルタイム・データ・ストリームが終了し、割当て済みプ
ロセッサ・リソースをそれ以上消費することはないこと
を示す。

【００６６】割当て解除ファンクションの実施例につい
て、図１０を参照して説明する。１つの例として、プロ
セッサ・リソースを割当て解除するために、現在の割当
て済みリアルタイム・レート５０６から入力データ・レ
ートが引かれる（ステップ１０００）。従って現在のレ
ートは、これらのリソースが他のデータ・ストリームの
配信に利用できることを示す。その後、割当て解除は完
了する。

【００６７】本発明に従って、リアルタイム・データ・
ストリームの配信時に、クライアントは表示の一時停止
を決定することができる。その場合は、リアルタイム・
サーバがシステム・リソース・マネージャの一時停止フ
ァンクションを起動し、リアルタイム・データ・ストリ
ームを表示するクライアントが、例えばビデオの表示を
一時停止したことを示す。一時停止したストリームは、
プロセッサの消費量には関係しないが、それらに必要な
プロセッサ時間は保存される。従って、一時停止したス
トリームのデータ・レートは計算に用いられる。一時停
止ファンクションの実施例については、図１１を参照し
て詳しく説明する。また再開ファンクションについても
述べる。

【００６８】図１１を参照する。最初、クライアントが
リアルタイム・データ・ストリームの配信を一時停止し
ているか、または一時停止の後に配信を再開しているか
どうか確認される（照会１１００）。このオプションが
一時停止なら、入力データ・レートが現在の一時停止リ
アルタイム・レート５１０に追加される（ステップ１１
０２）。その後、本発明の一時停止ファンクションは完
了する（ステップ１１０４）。

【００６９】他方、オプションが再開なら、現在の一時
停止データ・レートから入力データ・レートが引かれ
（ステップ１１０６）、再開ファンクションは完了する
（ステップ１１０４）。

【００７０】上に述べたのは、選択された量のリソース
をリアルタイム・サーバに提供し、また、システムの他
のタイプのアプリケーション及び他の作業を処理するた
め、選択された量のリソースが予約されることを保証す
る、プロセッサ・リソース管理機能である。

【００７１】上に述べたコンピュータ装置は１つの例に
すぎない。他のシステムや環境も、本発明の主旨から逸
脱することなく本発明を取り入れ、あるいは利用するこ
とができる。

【００７２】本発明は、例えばコンピュータ使用可能媒
体を有する製品（コンピュータのプログラム・プロダク
ト等）に加えることができる。媒体には、本発明の機能
を提供し促進するため、コンピュータ読取り可能プログ
ラム・コード手段が具体化される。製品はコンピュータ
装置の一部として追加するか、または個別に販売するこ
ともできる。

【００７３】ここに示したフローチャートも１つの例に
すぎない。これらの図やステップ（あるいは操作）は本
発明の主旨から逸脱することなく変更することができ
る。例えばステップは異なる順序で実行できる。あるい
はステップは追加、削除、または変更可能である。これ
らの変形はすべて特許請求範囲とみなされる。

【００７４】以上、好適な実施例が詳細に図示及び説明
されたが、様々な変更、追加、代替等が、本発明の趣旨
から逸脱することなく実現可能であり、従って本発明の
範囲内で考慮されることが当業者には理解されよう。

【００７５】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００７６】（１）コンピュータ装置のプロセッサ・リ
ソースを管理する装置であって、少なくともリアルタイ
ム・アプリケーションを含むリアルタイム・アプリケー
ションのグループに選択された限度を超えないある量の
プロセッサ・リソースを、前記コンピュータ装置のリア
ルタイム・アプリケーションに割当てるようにされ、選
択された量の前記プロセッサ・リソースを、前記コンピ
ュータ装置の少なくとも１つの非リアルタイム・アプリ
ケーションに引き続き利用できる、リソース・マネージ
ャと、前記リアルタイム・アプリケーションを処理する
手段と、を含む、装置。（２）前記リアルタイム・アプリケーションの処理が求
められていることを前記コンピュータ装置に指示する手
段を含む、前記（１）記載の装置。（３）前記指示手段は、前記リアルタイム・アプリケー
ションのディスパッチ優先度セットと、前記ディスパッ
チ優先度は調整されないことを指定するようにされたイ
ンジケータと、を含む、前記（２）記載の装置。（４）前記リソース・マネージャは、リアルタイム・デ
ータ・レートを配信するための、所与の時間内の最大サ
ービス・コストを求めるようにされた確認ユニットと、
前記リアルタイム・アプリケーションのリアルタイム・
データ・ストリームを配信するサービス・レートを計算
するようにされた計算ユニットと、前記サービス・レー
トが前記限度内にあるときに、充分な量の前記プロセッ
サ・リソースが前記リアルタイム・データ・ストリーム
に利用できることを指定するようにされたインジケータ
と、を含む、前記（１）記載の装置。（５）リアルタイム・アプリケーションの前記グループ
に現在割当てられているプロセッサ・リソースの量を追
跡するために、前記リアルタイム・データ・ストリーム
のデータ・レートを、現在の割当て済みデータ・レート
に加えるようにされた加算ユニットを含む、前記（４）
記載の装置。（６）前記リソース・マネージャはさらに、前記リアル
タイム・アプリケーションが前記プロセッサ・リソース
を必要としなくなったとき、前記割当てられた量の前記
プロセッサ・リソースを割当て解除するようにされた、
前記（１）記載の装置。（７）前記リソース・マネージャは、割当て解除された
量のプロセッサ・リソースがリアルタイム・アプリケー
ションの前記グループに利用できるように、現在割当て
られているデータ・レートから前記リアルタイム・アプ
リケーションのデータ・レートを引くようにされた減算
器を含む、前記（６）記載の装置。（８）前記リソース・マネージャは、前記リアルタイム
・アプリケーションの処理を一時停止するようにされ
た、前記（１）記載の装置。（９）前記リソース・マネージャは、前記一時停止の間
に、前記割当てられた量のプロセッサ・リソースを予約
する手段を含む、前記（８）記載の装置。（１０）前記リソース・マネージャは、前記一時停止し
たリアルタイム・アプリケーションの処理を再開するよ
うにされた、前記（８）記載の装置。（１１）前記リアルタイム・アプリケーションを処理す
る前記手段は、前記リアルタイム・アプリケーションに
関連付けられ、前記コンピュータ装置の性能目標を達成
するため制御パラメータに調整が必要なとき、調整され
るようにされた前記制御パラメータを含む、前記（１）
記載の装置。（１２）前記少なくとも１つの非リアルタイム・アプリ
ケーションを処理する手段を含み、前記１つの非リアル
タイム・アプリケーションを処理する手段は、前記コン
ピュータ装置の性能目標を達成するため、制御パラメー
タに調整が必要なとき、前記１つの非リアルタイム・ア
プリケーションに関連付けられた前記制御パラメータを
調整する手段を含む、前記（１）記載の装置。（１３）前記処理手段は、リアルタイム・アプリケーシ
ョンの前記グループに選択された前記プロセッサ・リソ
ースの最大量を前記リアルタイム・アプリケーションが
超えることを防ぐ手段を含む、前記（１）記載の装置。（１４）前記防止手段は、前記最大量を超えずには前記
リアルタイム・アプリケーションの作業単位がディスパ
ッチ不能であることを指示するようにされたインジケー
タを含む、前記（１３）記載の装置。（１５）コンピュータ装置のプロセッサ・リソースを管
理する装置であって、前記コンピュータ装置のリアルタ
イム・アプリケーションのグループに割当て可能な、選
択された量のプロセッサ・リソースと、前記コンピュー
タ装置の非リアルタイム・アプリケーションに予約され
た、選択された量の前記プロセッサ・リソースと、を含
む、装置。（１６）前記選択された量の前記プロセッサ・リソース
はリアルタイム・アプリケーションの複数のグループに
割当てることができる、前記（１５）記載の装置。（１７）前記の量のプロセッサ・リソースの少なくとも
一部を、リアルタイム・アプリケーションの前記グルー
プの１つのリアルタイム・アプリケーションに割当てる
ようにされたリソース・マネージャと、前記１つのリア
ルタイム・アプリケーションを処理する手段であって、
リアルタイム・アプリケーションの前記グループに選択
された前記プロセッサ・リソースの最大量を、前記１つ
のリアルタイム・アプリケーションが超えることを防ぐ
手段を含む、前記処理する手段と、を含む、前記（１
５）記載の装置。

【図面の簡単な説明】

【図１】本発明の管理機能を取り入れて使用するコンピ
ュータ装置の１つの例を示す図である。

【図２】本発明に従って用いられるディスパッチ優先度
の１つの例を示す図である。

【図３】本発明に従って、リアルタイム・アプリケーシ
ョンの処理に関連して用いられるロジックの実施例を示
す図である。

【図４】本発明に従って、図３の識別機能に関連付けら
れるロジックの１つの例を示す図である。

【図５】本発明に従って用いられるプロセッサ利用状況
データの１つの例を示す図である。

【図６】本発明に従って、リアルタイム・アプリケーシ
ョンにプロセッサ・リソースを割当てるために用いられ
るロジックの実施例を示す図である。

【図７】本発明に従って、リアルタイム・アプリケーシ
ョンの実行時に用いられるロジックの実施例を示す図で
ある。

【図８】本発明に従って、図７の実行手順のキャッピン
グ機能実行時に用いられるロジックの実施例を示す図で
ある。

【図９】本発明に従って、図７の実行手順のキャッピン
グ機能実行時に用いられるロジックの実施例を示す図で
ある。

【図１０】本発明に従って、リアルタイム・アプリケー
ションに割当てられるリソースの割当て解除時に用いら
れるロジックの実施例を示す図である。

【図１１】本発明に従って、リアルタイム・アプリケー
ションの実行の一時停止／再開時に用いられるロジック
の実施例を示す図である。

【符号の説明】

１００コンピュータ装置１０２オペレーティング・システム１０４リアルタイム・サーバ・アプリケーション１０６他のタイプのアプリケーション１０８作業単位１１０バッチ・アプリケーション１１２トランザクション処理アプリケーション１１４サービング・クライアント１１６作業負荷マネージャ１１８システム・リソース・マネージャ１２０ディスパッチャ１２２作業単位制御ブロック１３０リソース・グループ・テーブル・エントリ１３２、１４４リソース・グループ名１３４プロセッサ消費最大値１３６プロセッサ消費限度値１３８プロセッサ利用状況データ１４０キャップ・スライス・パターン１４２クラス・テーブル・エントリ１４６ユーザ性能目標１４８ユーザ性能目標の相対重要度１５０ディスパッチ優先度１５２リアルタイム・サーバ・ビット１５４ディスパッチ優先度フィールド１５６優先使用ビット・フィールド１５８キャップ・ビット・フィールド５０２グループ・サービス・レート５０４前の割当て済みリアルタイム・レート５０６現在の割当て済みリアルタイム・レート５０８前の一時停止リアルタイム・レート５１０現在の一時停止リアルタイム・レート５１２割当て済みリアルタイム・レート・ウィンドウ５１４リアルタイム・サービス・レート・ウィンドウ５１６リアルタイム・一時停止レート・ウィンドウ５１８リアルタイム・ウィンドウ枠インデックス

───────────────────────────────────────────────────── フロントページの続き (72)発明者ピーター・ビィ・ワコムアメリカ合衆国12590、ニューヨーク州ワッピンガーズ・フォールズ、ワイルドウッド・マナー 17ビィ

Claims

【特許請求の範囲】

【請求項１】コンピュータ装置のプロセッサ・リソース
を管理する装置であって、少なくともリアルタイム・アプリケーションを含むリア
ルタイム・アプリケーションのグループに選択された限
度を超えないある量のプロセッサ・リソースを、前記コ
ンピュータ装置のリアルタイム・アプリケーションに割
当てるようにされ、選択された量の前記プロセッサ・リ
ソースを、前記コンピュータ装置の少なくとも１つの非
リアルタイム・アプリケーションに引き続き利用でき
る、リソース・マネージャと、前記リアルタイム・アプリケーションを処理する手段
と、を含む、装置。
【請求項２】前記リアルタイム・アプリケーションの処
理が求められていることを前記コンピュータ装置に指示
する手段を含む、請求項１記載の装置。
【請求項３】前記指示手段は、前記リアルタイム・アプリケーションのディスパッチ優
先度セットと、前記ディスパッチ優先度は調整されないことを指定する
ようにされたインジケータと、を含む、請求項２記載の装置。
【請求項４】前記リソース・マネージャは、リアルタイム・データ・レートを配信するための、所与
の時間内の最大サービス・コストを求めるようにされた
確認ユニットと、前記リアルタイム・アプリケーションのリアルタイム・
データ・ストリームを配信するサービス・レートを計算
するようにされた計算ユニットと、前記サービス・レートが前記限度内にあるときに、充分
な量の前記プロセッサ・リソースが前記リアルタイム・
データ・ストリームに利用できることを指定するように
されたインジケータと、を含む、請求項１記載の装置。
【請求項５】リアルタイム・アプリケーションの前記グ
ループに現在割当てられているプロセッサ・リソースの
量を追跡するために、前記リアルタイム・データ・スト
リームのデータ・レートを、現在の割当て済みデータ・
レートに加えるようにされた加算ユニットを含む、請求
項４記載の装置。
【請求項６】前記リソース・マネージャはさらに、前記
リアルタイム・アプリケーションが前記プロセッサ・リ
ソースを必要としなくなったとき、前記割当てられた量
の前記プロセッサ・リソースを割当て解除するようにさ
れた、請求項１記載の装置。
【請求項７】前記リソース・マネージャは、割当て解除
された量のプロセッサ・リソースがリアルタイム・アプ
リケーションの前記グループに利用できるように、現在
割当てられているデータ・レートから前記リアルタイム
・アプリケーションのデータ・レートを引くようにされ
た減算器を含む、請求項６記載の装置。
【請求項８】前記リソース・マネージャは、前記リアル
タイム・アプリケーションの処理を一時停止するように
された、請求項１記載の装置。
【請求項９】前記リソース・マネージャは、前記一時停
止の間に、前記割当てられた量のプロセッサ・リソース
を予約する手段を含む、請求項８記載の装置。
【請求項１０】前記リソース・マネージャは、前記一時
停止したリアルタイム・アプリケーションの処理を再開
するようにされた、請求項８記載の装置。
【請求項１１】前記リアルタイム・アプリケーションを
処理する前記手段は、前記リアルタイム・アプリケーシ
ョンに関連付けられ、前記コンピュータ装置の性能目標
を達成するため制御パラメータに調整が必要なとき、調
整されるようにされた前記制御パラメータを含む、請求
項１記載の装置。
【請求項１２】前記少なくとも１つの非リアルタイム・
アプリケーションを処理する手段を含み、前記１つの非
リアルタイム・アプリケーションを処理する手段は、前
記コンピュータ装置の性能目標を達成するため、制御パ
ラメータに調整が必要なとき、前記１つの非リアルタイ
ム・アプリケーションに関連付けられた前記制御パラメ
ータを調整する手段を含む、請求項１記載の装置。
【請求項１３】前記処理手段は、リアルタイム・アプリ
ケーションの前記グループに選択された前記プロセッサ
・リソースの最大量を前記リアルタイム・アプリケーシ
ョンが超えることを防ぐ手段を含む、請求項１記載の装
置。
【請求項１４】前記防止手段は、前記最大量を超えずに
は前記リアルタイム・アプリケーションの作業単位がデ
ィスパッチ不能であることを指示するようにされたイン
ジケータを含む、請求項１３記載の装置。
【請求項１５】コンピュータ装置のプロセッサ・リソー
スを管理する装置であって、前記コンピュータ装置のリアルタイム・アプリケーショ
ンのグループに割当て可能な、選択された量のプロセッ
サ・リソースと、前記コンピュータ装置の非リアルタイム・アプリケーシ
ョンに予約された、選択された量の前記プロセッサ・リ
ソースと、を含む、装置。
【請求項１６】前記選択された量の前記プロセッサ・リ
ソースはリアルタイム・アプリケーションの複数のグル
ープに割当てることができる、請求項１５記載の装置。
【請求項１７】前記の量のプロセッサ・リソースの少な
くとも一部を、リアルタイム・アプリケーションの前記
グループの１つのリアルタイム・アプリケーションに割
当てるようにされたリソース・マネージャと、前記１つのリアルタイム・アプリケーションを処理する
手段であって、リアルタイム・アプリケーションの前記
グループに選択された前記プロセッサ・リソースの最大
量を、前記１つのリアルタイム・アプリケーションが超
えることを防ぐ手段を含む、前記処理する手段と、を含
む、請求項１５記載の装置。