(57)【特許請求の範囲】
【請求項１】
コンピューティング環境におけるプロセッサ・デバイスによる、デュアル動作システムに対する複数のリソースのリソース割り当てのための方法であって、前記方法は、
より要求の高い第１の動作およびより要求の低い第２の動作を含み、前記第１の動作および前記第２の動作の各々にリソースの静的割り当て量が設定されているデュアル動作の各々を開始するステップと、
前記第１の動作のリソース要求に対して、前記第２の動作のリソース要求が拒絶されるまでリソース境界を増加させるステップと、
前記第２の動作の前記リソース要求の前記拒絶に応答して、
前記第１の動作に対するリソース境界を低減するステップ、および
現行リソース使用量が前記低減するステップで低減されたリソース境界以下になるまで減少後待機モードを始動させるステップ
を行うステップと、
を含む、方法。
【請求項２】
前記デュアル動作の各々を開始するステップに続いて、前記デュアル動作によって前記リソース要求を発行するステップと、
前記デュアル動作の前記リソース境界を定めるステップと、
前記リソース要求を拒絶するステップであって、前記リソース要求が拒絶されるのは、
前記デュアル動作に対して割り当てられた前記複数のリソースの総数がグローバル・リソース限界に達し、前記リソース要求が拒絶されるとマーク付けされたとき、および
前記デュアル動作のうち前記リソース要求を発行した動作に対して割り当てられた前記複数のリソースの前記総数が前記リソース要求を発行した動作の前記リソース境界に達したとき
である、ステップと、
前記デュアル動作の現行リソース・カウンタを増加させるステップと、
前記リソース要求を受諾するステップであって、
前記リソース要求が受諾され、かつ前記現行リソース・カウンタが増加されるのは、
前記リソース要求を発行した動作に対して割り当てられた前記複数のリソースの前記総数が前記リソース要求を発行した動作の前記静的割り当て量よりも低いとき、
前記デュアル動作のうち他方の動作に対して割り当てられた前記複数のリソースの前記総数が前記他方の動作に対する前記リソース境界に達したとき、および
前記リソース要求を発行した動作に対して割り当てられた前記複数のリソースの前記総数が前記リソース要求を発行した動作に対する前記リソース境界に達していないとき
である、ステップと
を実行する、請求項１に記載の方法。
【請求項３】
前記リソース境界を定める前記ステップが、
前記リソース要求を発行した動作が動的ベースを有するかどうかを定めるステップと、
もし前記リソース要求を発行した動作が動的ベースを有さなければ、
動的ベースを作成するステップであって、前記動的ベースは前記リソース要求を発行した動作の前記静的割り当て量に初期化される、ステップ、
前記他方の動作に対する前記動的ベースを除去するステップ、
動的ベース経過時間をリセットするステップ、および
前記減少後待機モードをリセットするステップ
を行うステップと、
もし前記リソース要求を発行した動作が動的ベースを有していれば、
前記リソース要求を発行した動作が前記減少後待機モードであるかどうかを定めるステップ、
もし前記リソース要求を発行した動作が前記減少後待機モードでなければ動的加法的増加とともに前記リソース境界を戻すステップ、
もし前記リソース要求を発行した動作が前記減少後待機モードであれば、前記現行リソース使用量が前記動的ベースに達したかどうかを確認し、もし前記現行リソース使用量が前記動的ベースに達していなければ前記減少後待機モードに残り、もし前記現行リソース使用量が前記動的ベースに達していれば、前記減少後待機モードをオフにし、前記動的ベース経過時間をリセットし、前記動的ベースを前記リソース要求を発行した動作の前記リソース境界として戻すステップ
を行うステップと、
を含む、請求項２に記載の方法。
【請求項４】
前記リソース要求が拒絶されるとマーク付けすることが、
前記リソース要求を発行した動作が前記減少後待機モードであるかどうかを確認するステップと、
もし前記リソース要求を発行した動作が前記減少後待機モードであれば、前記リソース要求を発行した動作の前記現行リソース使用量が前記動的ベースに達したかどうかを定めるステップであって、もし前記現行リソース使用量が前記動的ベースに達していれば前記減少後待機モードをオフに設定して前記動的ベース経過時間をリセットする、ステップと、
前記リソース要求を発行した動作が前記減少後待機モードでない場合、前記リソース要求を発行した動作の前記現行リソース使用量が前記動的ベースに達していない場合、および前記動的ベース経過時間をリセットした後で、前記デュアル動作の拒絶されなかった動作が動的ベースを有するかどうかを定めるステップと、
もし前記デュアル動作の拒絶されなかった動作が動的ベースを有していれば、前記拒絶されなかった動作が減少後待機モードであるかどうかを定めるステップと、
前記拒絶されなかった動作が前記減少後待機モードでなければ、前記リソース境界を乗法的に減少させ、前記動的ベース経過時間をリセットし、前記減少後待機モードをオンにするステップと
を含む、請求項３に記載の方法。
【請求項５】
コンピューティング環境におけるデュアル動作システムに対する複数のリソースのリソース割り当てのためのシステムであって、
前記コンピューティング環境において動作可能な少なくとも１つのプロセッサ・デバイスを含み、前記少なくとも１つのプロセッサ・デバイスは、
より要求の高い第１の動作およびより要求の低い第２の動作を含み、前記第１の動作および前記第２の動作の各々にリソースの静的割り当て量が設定されているデュアル動作の各々を開始するステップと、
前記第１の動作に対するリソース要求に対して、前記第２の動作に対するリソース要求が拒絶されるまでリソース境界を増加させるステップと、
前記第２の動作に対する前記リソース要求の前記拒絶に応答して、前記第１の動作に対するリソース境界を低減し、現行リソース使用量が低減されたリソース境界以下になるまで減少後待機モードを始動させるステップと、
に対して適合される、システム。
【請求項６】
前記少なくとも１つのプロセッサ・デバイスは、
前記デュアル動作の各々を開始するステップに続いて、前記デュアル動作によって前記リソース要求を発行するステップと、
前記デュアル動作の前記リソース境界を定めるステップと、
前記リソース要求を拒絶するステップであって、前記リソース要求が拒絶されるのは、  前記デュアル動作に対して割り当てられた前記複数のリソースの総数がグローバル・リソース限界に達し、前記リソース要求が拒絶されるとマーク付けされたとき、および
前記デュアル動作のうち前記リソース要求を発行した動作に対して割り当てられた前記複数のリソースの前記総数が前記リソース要求を発行した動作の前記リソース境界に達したとき
である、ステップと、
前記デュアル動作の現行リソース・カウンタを増加させるステップと、
前記リソース要求を受諾するステップであって、
前記リソース要求が受諾され、かつ前記現行リソース・カウンタが増加されるのは、
前記リソース要求を発行した動作に対して割り当てられた前記複数のリソースの前記総数が前記リソース要求を発行した動作の前記静的割り当て量よりも低いとき、
前記デュアル動作のうち他方の動作に対して割り当てられた前記複数のリソースの前記総数が前記他方の動作に対する前記リソース境界に達したとき、および
前記リソース要求を発行した動作に対して割り当てられた前記複数のリソースの前記総数が前記リソース要求を発行した動作に対する前記リソース境界に達していないとき
である、ステップと
に対して適合される、請求項５に記載のシステム。
【請求項７】
前記リソース境界を定める前記ステップが、
前記リソース要求を発行した動作が動的ベースを有するかどうかを定めるステップと、
もし前記リソース要求を発行した動作が動的ベースを有さなければ、
動的ベースを作成するステップであって、前記動的ベースは前記リソース要求を発行した動作の前記静的割り当て量に初期化される、ステップ、
前記他方の動作に対する前記動的ベースを除去するステップ、
動的ベース経過時間をリセットするステップ、および
前記減少後待機モードをリセットするステップ
を行うステップと、
もし前記リソース要求を発行した動作が動的ベースを有していれば、
前記リソース要求を発行した動作が前記減少後待機モードであるかどうかを定めるステップ、
もし前記リソース要求を発行した動作が前記減少後待機モードでなければ動的加法的増加とともに前記リソース境界を戻すステップ、
もし前記リソース要求を発行した動作が前記減少後待機モードであれば、前記現行リソース使用量が前記動的ベースに達したかどうかを確認し、もし前記現行リソース使用量が前記動的ベースに達していなければ前記減少後待機モードに残り、もし前記現行リソース使用量が前記動的ベースに達していれば、前記減少後待機モードをオフにし、前記動的ベース経過時間をリセットし、前記動的ベースを前記リソース要求を発行した動作の前記リソース境界として戻すステップ
を行うステップと、
を含む、請求項６に記載のシステム。
【請求項８】
前記リソース要求が拒絶されるとマーク付けすることが、
前記リソース要求を発行した動作が前記減少後待機モードであるかどうかを確認するステップと、
もし前記リソース要求を発行した動作が前記減少後待機モードであれば、前記リソース要求を発行した動作の前記現行リソース使用量が前記動的ベースに達したかどうかを定めるステップであって、もし前記現行リソース使用量が前記動的ベースに達していれば前記減少後待機モードをオフに設定して前記動的ベース経過時間をリセットする、ステップと、
前記リソース要求を発行した動作が前記減少後待機モードでない場合、前記リソース要求を発行した動作の前記現行リソース使用量が前記動的ベースに達していない場合、および前記動的ベース経過時間をリセットした後で、前記デュアル動作の拒絶されなかった動作が動的ベースを有するかどうかを定めるステップと、
もし前記デュアル動作の拒絶されなかった動作が動的ベースを有していれば、前記拒絶されなかった動作が減少後待機モードであるかどうかを定めるステップと、
前記拒絶されなかった動作が前記減少後待機モードでなければ、前記リソース境界を乗法的に減少させ、前記動的ベース経過時間をリセットし、前記減少後待機モードをオンにするステップと
を含む、請求項７に記載のシステム。
【請求項９】
コンピュータ・プログラムであって、コンピュータ読取り可能媒体に保存されたコンピュータ・プログラム・コードを含むことによって、コンピュータ・システムにロードされてそこで実行されたときに、前記コンピュータ・システムに請求項１から４のいずれか１項に記載の方法のすべてのステップを行わせる、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的にコンピュータに関し、より特定的にはコンピューティング環境におけるプロセッサ・デバイスによるデュアル動作システム（ｄｕａｌ  ａｃｔｉｖｉｔｙ  ｓｙｓｔｅｍ）に対する複数のリソースのリソース割り当てに関する。
【背景技術】
【０００２】
現代社会にはコンピュータ・システムが普及している。職場にも、家庭にも、学校にもコンピュータ・システムが見出され得る。コンピュータ・システムは、データを処理して保存するためのデータ記憶システムまたはディスク記憶システムを含んでもよい。データ記憶システムまたはディスク記憶システムは、データを処理して保存するために利用される。記憶システムは１つまたはそれ以上のディスク・ドライブを含んでもよい。これらのデータ処理システムは、典型的に大量のデータ記憶を必要とする。顧客データ、またはそのデータ処理システム内のユーザによって生成されたデータは、このデータ記憶の大きな部分を占める。これらのコンピュータ・システムの多くは仮想記憶構成要素を含む。
【０００３】
コンピューティング環境内では、さまざまな動作およびサービスを行うためにシステム・リソースが必要とされることがある。同時進行する複数の動作を維持するシステムはしばしば、一度に１つの動作にしか使用できないリソースに依存していることによる制約を受ける。こうしたシステムにおける課題は、リソースの可用性ならびに動作の必要性および優先度を考慮しながら、これらの異なる動作に限られた数のリソースを分配することである。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
同時進行するデュアル動作を行いかつサポートするコンピュータ・システムは、一度に１つの動作にのみ割り当てられるか、使用されるか、または利用され得るコンピュータ・システム・リソースに依存していることによる制約を受ける。これらのコンピュータ・システムは、コンピューティング・リソースの可用性ならびにデュアル動作の必要性および優先度を考慮しながら、これらの異なるデュアル動作に限られた数のシステム・リソースの分配、割り付けもしくは割り当てまたはその組み合わせを行うという課題に直面する。その結果として、効率および生産性が落ちることがある。
【課題を解決するための手段】
【０００５】
したがって前述に鑑みて、プロセッサ・デバイスによるデュアル動作システムに対する複数のリソースのリソース割り当てのためのさまざまな例示的方法、システムおよびコンピュータ・プログラム製品の実施形態が提供される。一実施形態においては、単なる例として、動作の各々が静的割り当て量（ｓｔａｔｉｃ  ｑｕｏｔａ）において開始されてもよい。デュアル動作の少なくとも１つに対するリソース要求に対しては、そのデュアル動作の少なくとも１つの代替的な１つに対するリソース要求が拒絶されるまでリソース境界が増やされてもよい。デュアル動作の少なくとも１つの代替的な１つに対するリソース要求の拒絶に応答して、そのデュアル動作の少なくとも１つに対するリソース境界が低減されてもよく、現行リソース使用量が低減されたリソース境界以下になるまで、減少後待機（ｗａｉｔ  ａｆｔｅｒ  ｄｅｃｒｅａｓｅ）モードが始動されてもよい。
【０００６】
前述の例示的方法の実施形態に加えて、他の例示的システムおよびコンピュータ製品の実施形態も提供され、関連する利点に寄与する。前述の概要は、以下の詳細な説明にさらに記載される概念の一部を簡単な形で紹介するために提供されたものである。この概要は、請求される発明の主題の主要な特徴または必須の特徴を明確にすることは意図されていないし、請求される発明の主題の範囲を定めるための助けとして用いられることも意図されていない。請求される発明の主題は、背景技術において示されたいずれかの不利益またはすべての不利益を解決する実施に限定されない。
【０００７】
第１の局面から見て、本発明は、コンピューティング環境におけるプロセッサ・デバイスによるデュアル動作システムに対する複数のリソースのリソース割り当てのための方法を提供する。この方法は、複数の静的割り当て量の各々においてデュアル動作の各々を開始するステップと、デュアル動作の少なくとも１つに対するリソース要求に対して、そのデュアル動作の少なくとも１つの代替的な１つに対するリソース要求が拒絶されるまでリソース境界を増加させるステップと、デュアル動作の少なくとも１つの代替的な１つに対するリソース要求の拒絶に応答して、そのデュアル動作の少なくとも１つに対するリソース境界を低減するステップ、および現行リソース使用量が低減されたリソース境界以下になるまで減少後待機モードを始動させるステップのうちの少なくとも１つを行うステップとを含む。
【０００８】
好ましくはこの方法はさらに、デュアル動作によってリソース要求を発行するステップに従って、デュアル動作のリソース境界を定めるステップと、リソース要求を拒絶するステップであって、リソース要求が拒絶されるのは、デュアル動作に対して発行された複数のリソースの総数がグローバル・リソース限界に達し、リソース要求が拒絶されるとマーク付けされたとき、およびデュアル動作の少なくとも１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つのリソース境界に達したときのうちの少なくとも１つのときである、ステップと、デュアル動作の現行リソース・カウンタを増加させるステップと、リソース要求を受諾するステップであって、リソース要求が受諾され、かつ現行リソース・カウンタが増加されるのは、デュアル動作の少なくとも１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つの複数の静的割り当て量の１つよりも低いとき、およびデュアル動作の少なくとも１つの代替的な１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つの代替的な１つに対するリソース境界に達したとき、およびデュアル動作の少なくとも１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つに対するリソース境界に達したときのうちの少なくとも１つのときである、ステップとのうちの少なくとも１つを行うステップを含む。
【０００９】
好ましくはこの方法はさらに、リソース境界を定めるステップに従って、デュアル動作が動的モードであるかどうかを定めるステップと、もしデュアル動作の少なくとも１つが動的ベースを有さなければ、動的ベースを作成するステップであって、この動的ベースは複数の静的割り当て量の１つに初期化される、ステップ、デュアル動作の少なくとも１つの代替的な１つに対する動的ベースを除去するステップ、動的ベース経過時間（ｄｙｎａｍｉｃ  ｂａｓｅ  ａｇｅ）をリセットするステップ、および減少後待機モードをリセットするステップのうちの少なくとも１つを行うステップと、もしデュアル動作の少なくとも１つが動的ベースを有していれば、そのデュアル動作の少なくとも１つが減少後待機モードであるかどうかを定めるステップであって、もしそのデュアル動作の少なくとも１つが減少後待機モードでなければ動的加法的増加とともにリソース境界を戻すステップ、他方の場合には現行リソース使用量が動的ベースに達したかどうかを確認するステップ、およびもし現行リソース使用量が動的ベースに達していなければ減少後待機モードに残るステップ、他方の場合には減少後待機モードをオフにするステップ、動的ベース経過時間をリセットするステップ、および動的ベースをデュアル動作の少なくとも１つのリソース境界として戻すステップのうちの少なくとも１つを行うステップのうちの少なくとも１つを行う、ステップとのうちの少なくとも１つを行うステップを含む。
【００１０】
好ましくはこの方法はさらに、拒絶されるリソース要求をマーク付けするステップに従って、もしデュアル動作が減少後待機モードであれば、デュアル動作の少なくとも１つの現行リソース使用量が動的ベースに達したかどうかを定めるステップであって、もし現行リソース使用量が動的ベースに達していれば減少後待機モードをオフに設定して動的ベース経過時間をリセットする、ステップと、もし拒絶されないデュアル動作の少なくとも１つの代替的な１つが動的ベースを有していれば、リソース境界を乗法的に減少させるステップと、減少後待機モードがオフにされているかどうかを確認するステップと、もし減少後待機モードがオフにされていれば、動的ベース経過時間をリセットするステップと、減少後待機モードをオンにするステップとのうちの少なくとも１つを行うステップを含む。
【００１１】
好ましくはこの方法はさらに、フィードバック制御動作によってリソース要求に応答して複数のリソースを動的に調整するステップを含み、この複数のリソースはデュアル動作のうちよりアクティブなものに割り当てられる。
【００１２】
好ましくはこの方法はさらに、フィードバック制御動作によってリソース要求に応答して複数のリソースを動的に調整するステップに従って、デュアル動作のうちよりアクティブでないものから複数のリソースが奪われないことを確認するステップと、リソース要求の際に複数のリソースのうち少なくとも１つをデュアル動作のうちよりアクティブでないものに割り当てるステップとのうちの少なくとも１つを行うステップを含む。
【００１３】
好ましくはこの方法はさらに、デュアル動作の各々に対する現行リソース使用量およびリソース境界を維持するステップと、複数のリソースのうち発行されたものの使用をデュアル動作が完了したときに通知を送り、現行リソース使用量を更新するステップとのうちの少なくとも１つを行うステップを含む。
【００１４】
第２の局面から見て、本発明は、コンピューティング環境におけるデュアル動作システムに対する複数のリソースのリソース割り当てのためのシステムを提供し、このシステムは、コンピューティング環境において動作可能な少なくとも１つのプロセッサ・デバイスを含み、この少なくとも１つのプロセッサ・デバイスは、複数の静的割り当て量の各々においてデュアル動作の各々を開始するステップと、デュアル動作の少なくとも１つに対するリソース要求に対して、そのデュアル動作の少なくとも１つの代替的な１つに対するリソース要求が拒絶されるまでリソース境界を増加させるステップと、デュアル動作の少なくとも１つの代替的な１つに対するリソース要求の拒絶に応答して、そのデュアル動作の少なくとも１つに対するリソース境界を低減するステップ、および現行リソース使用量が低減されたリソース境界以下になるまで減少後待機モードを始動させるステップのうちの少なくとも１つを行うステップとに対して適合されている。
【００１５】
好ましくはこのシステムにおいて、少なくとも１つのプロセッサ・デバイスはさらに、デュアル動作によってリソース要求を発行するステップに従って、デュアル動作のリソース境界を定めるステップと、リソース要求を拒絶するステップであって、リソース要求が拒絶されるのは、デュアル動作に対して発行された複数のリソースの総数がグローバル・リソース限界に達し、リソース要求が拒絶されるとマーク付けされたとき、およびデュアル動作の少なくとも１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つのリソース境界に達したときのうちの少なくとも１つのときである、ステップと、デュアル動作の現行リソース・カウンタを増加させるステップと、リソース要求を受諾するステップであって、リソース要求が受諾され、かつ現行リソース・カウンタが増加されるのは、デュアル動作の少なくとも１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つの複数の静的割り当て量の１つよりも低いとき、およびデュアル動作の少なくとも１つの代替的な１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つの代替的な１つに対するリソース境界に達したとき、およびデュアル動作の少なくとも１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つに対するリソース境界に達したときのうちの少なくとも１つのときである、ステップとのうちの少なくとも１つを行うステップに対して適合されている。
【００１６】
好ましくはこのシステムにおいて、少なくとも１つのプロセッサ・デバイスはさらに、リソース境界を定めるステップに従って、デュアル動作が動的モードであるかどうかを定めるステップと、もしデュアル動作の少なくとも１つが動的ベースを有さなければ、動的ベースを作成するステップであって、この動的ベースは複数の静的割り当て量の１つに初期化される、ステップ、デュアル動作の少なくとも１つの代替的な１つに対する動的ベースを除去するステップ、動的ベース経過時間をリセットするステップ、および減少後待機モードをリセットするステップのうちの少なくとも１つを行うステップと、もしデュアル動作の少なくとも１つが動的ベースを有していれば、そのデュアル動作の少なくとも１つが減少後待機モードであるかどうかを定めるステップであって、もしそのデュアル動作の少なくとも１つが減少後待機モードでなければ動的加法的増加とともにリソース境界を戻すステップ、他方の場合には現行リソース使用量が動的ベースに達したかどうかを確認するステップ、およびもし現行リソース使用量が動的ベースに達していなければ減少後待機モードに残るステップ、他方の場合には減少後待機モードをオフにするステップ、動的ベース経過時間をリセットするステップ、および動的ベースをデュアル動作の少なくとも１つのリソース境界として戻すステップを行うステップのうちの少なくとも１つを行うステップのうちの少なくとも１つを行う、ステップとのうちの少なくとも１つを行うステップに対して適合されている。
【００１７】
好ましくはこのシステムにおいて、少なくとも１つのプロセッサ・デバイスはさらに、拒絶されるリソース要求をマーク付けするステップに従って、もしデュアル動作が減少後待機モードであれば、デュアル動作の少なくとも１つの現行リソース使用量が動的ベースに達したかどうかを定めるステップであって、もし現行リソース使用量が動的ベースに達していれば減少後待機モードをオフに設定して動的ベース経過時間をリセットする、ステップと、もし拒絶されないデュアル動作の少なくとも１つの代替的な１つが動的ベースを有していれば、リソース境界を乗法的に減少させるステップと、減少後待機モードがオフにされているかどうかを確認するステップと、もし減少後待機モードがオフにされていれば、動的ベース経過時間をリセットするステップと、減少後待機モードをオンにするステップとのうちの少なくとも１つを行うステップに対して適合されている。
【００１８】
好ましくはこのシステムにおいて、少なくとも１つのプロセッサ・デバイスはさらに、フィードバック制御動作によってリソース要求に応答して複数のリソースを動的に調整するステップに対して適合され、この複数のリソースはデュアル動作のうちよりアクティブなものに割り当てられる。
【００１９】
好ましくはこのシステムにおいて、少なくとも１つのプロセッサ・デバイスはさらに、フィードバック制御動作によってリソース要求に応答して複数のリソースを動的に調整するステップに従って、デュアル動作のうちよりアクティブでないものから複数のリソースが奪われないことを確認するステップと、リソース要求の際に複数のリソースのうち少なくとも１つをデュアル動作のうちよりアクティブでないものに割り当てるステップとのうちの少なくとも１つを行うステップに対して適合されている。
【００２０】
好ましくはこのシステムにおいて、少なくとも１つのプロセッサ・デバイスはさらに、デュアル動作の各々に対する現行リソース使用量およびリソース境界を維持するステップと、複数のリソースのうち発行されたものの使用をデュアル動作が完了したときに通知を送り、現行リソース使用量を更新するステップとのうちの少なくとも１つを行うステップに対して適合されている。
【００２１】
第３の局面から見て、本発明は、プロセッサ・デバイスによるデュアル動作システムに対する複数のリソースのリソース割り当てのためのコンピュータ・プログラム製品を提供する。このコンピュータ・プログラム製品は、コンピュータ読取り可能プログラム・コード部分が中に保存された非一時的なコンピュータ読取り可能記憶媒体を含み、このコンピュータ読取り可能プログラム・コード部分は、複数の静的割り当て量の各々においてデュアル動作の各々を開始するための第１の実行可能部分と、デュアル動作の少なくとも１つに対するリソース要求に対して、そのデュアル動作の少なくとも１つの代替的な１つに対するリソース要求が拒絶されるまでリソース境界を増加させるための第２の実行可能部分と、デュアル動作の少なくとも１つの代替的な１つに対するリソース要求の拒絶に応答して、デュアル動作の少なくとも１つに対するリソース境界を低減するステップ、および現行リソース使用量が低減されたリソース境界以下になるまで減少後待機モードを始動させるステップのうちの少なくとも１つを行うための第３の実行可能部分とを含む。
【００２２】
好ましくはこのコンピュータ・プログラム製品はさらに、デュアル動作によってリソース要求を発行するステップに従って、デュアル動作のリソース境界を定めるステップと、リソース要求を拒絶するステップであって、リソース要求が拒絶されるのは、デュアル動作に対して発行された複数のリソースの総数がグローバル・リソース限界に達し、リソース要求が拒絶されるとマーク付けされたとき、およびデュアル動作の少なくとも１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つのリソース境界に達したときのうちの少なくとも１つのときである、ステップと、デュアル動作の現行リソース・カウンタを増加させるステップと、リソース要求を受諾するステップであって、リソース要求が受諾され、かつ現行リソース・カウンタが増加されるのは、デュアル動作の少なくとも１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つの複数の静的割り当て量の１つよりも低いとき、およびデュアル動作の少なくとも１つの代替的な１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つの代替的な１つに対するリソース境界に達したとき、およびデュアル動作の少なくとも１つに対して発行された複数のリソースの総数がそのデュアル動作の少なくとも１つに対するリソース境界に達したときのうちの少なくとも１つのときである、ステップとのうちの少なくとも１つを行うための第４の実行可能部分を含む。
【００２３】
好ましくはこのコンピュータ・プログラム製品はさらに、リソース境界を定めるステップに従って、デュアル動作が動的モードであるかどうかを定めるステップと、もしデュアル動作の少なくとも１つが動的ベースを有さなければ、動的ベースを作成するステップであって、この動的ベースは複数の静的割り当て量の１つに初期化される、ステップ、デュアル動作の少なくとも１つの代替的な１つに対する動的ベースを除去するステップ、動的ベース経過時間をリセットするステップ、および減少後待機モードをリセットするステップのうちの少なくとも１つを行うステップと、もしデュアル動作の少なくとも１つが動的ベースを有していれば、そのデュアル動作の少なくとも１つが減少後待機モードであるかどうかを定めるステップであって、もしそのデュアル動作の少なくとも１つが減少後待機モードでなければ動的加法的増加とともにリソース境界を戻すステップ、他方の場合には現行リソース使用量が動的ベースに達したかどうかを確認するステップ、およびもし現行リソース使用量が動的ベースに達していなければ減少後待機モードに残るステップ、他方の場合には減少後待機モードをオフにするステップ、動的ベース経過時間をリセットするステップ、および動的ベースをデュアル動作の少なくとも１つのリソース境界として戻すステップのうちの少なくとも１つを行うステップのうちの少なくとも１つを行う、ステップとのうちの少なくとも１つを行うための第４の実行可能部分を含む。
【００２４】
好ましくはこのコンピュータ・プログラム製品はさらに、拒絶されるリソース要求をマーク付けするステップに従って、もしデュアル動作が減少後待機モードであれば、デュアル動作の少なくとも１つの現行リソース使用量が動的ベースに達したかどうかを定めるステップであって、もし現行リソース使用量が動的ベースに達していれば減少後待機モードをオフに設定して動的ベース経過時間をリセットする、ステップと、もし拒絶されないデュアル動作の少なくとも１つの代替的な１つが動的ベースを有していれば、リソース境界を乗法的に減少させるステップと、減少後待機モードがオフにされているかどうかを確認するステップと、もし減少後待機モードがオフにされていれば、動的ベース経過時間をリセットするステップと、減少後待機モードをオンにするステップとのうちの少なくとも１つを行うための第４の実行可能部分を含む。
【００２５】
好ましくはこのコンピュータ・プログラム製品はさらに、フィードバック制御動作によってリソース要求に応答して複数のリソースを動的に調整するための第４の実行可能部分を含み、この複数のリソースはデュアル動作のうちよりアクティブなものに割り当てられる。
【００２６】
好ましくはこのコンピュータ・プログラム製品はさらに、デュアル動作の各々に対する現行リソース使用量およびリソース境界を維持するステップと、複数のリソースのうち発行されたものの使用をデュアル動作が完了したときに通知を送り、現行リソース使用量を更新するステップとのうちの少なくとも１つを行い、かつフィードバック制御動作によってリソース要求に応答して複数のリソースを動的に調整するステップに従って、デュアル動作のうちよりアクティブでないものから複数のリソースが奪われないことを確認するステップと、リソース要求の際に複数のリソースのうち少なくとも１つをデュアル動作のうちよりアクティブでないものに割り当てるステップとのうちの少なくとも１つを行うための第５の実行可能部分を含む。
【００２７】
本発明について、添付の図面に示されるその好ましい実施形態を参照しながら単なる例として説明する。
【図面の簡単な説明】
【００２８】
【図１】本発明の局面を実現し得る記憶装置の例を有するコンピュータ記憶装置環境を示す図である。
【図２】本発明の局面を実現し得るコンピュータ・システムにおけるデータ記憶システムのハードウェア構造を示す例示的ブロック図である。
【図３】本発明の局面を実現し得るデュアル動作システムに対するリソースのリソース割り当てのための構成要素を有するコンピューティング環境を示す例示的ブロック図である。
【図４】デュアル動作システムに対するリソースのリソース割り当てのための例示的方法を示す流れ図である。
【図５】時間に対する実際のリソース境界の挙動を示すコンピューティング環境を示す例示的スナップショットである。
【図６】リソース要求を処理するための例示的方法を示す流れ図である。
【図７】リソース境界を定めるための例示的方法を示す流れ図である。
【図８】リソース要求の拒絶をマーク付けするための例示的方法を示す流れ図である。
【発明を実施するための形態】
【００２９】
以下の説明および請求される発明の主題において、示される実施形態に関する以下の用語を説明する。この定義は、必要であれば、および本明細書において用いられる特定の用語に対して、定義の好適なものの表を形成してもよいし、好適な目的に対するマトリクスを形成してもよい。
【００３０】
本明細書において、「グローバル・リソース限界（Ｇｌｏｂａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｉｍｉｔ：ＧＲＬ）」とは、デュアル動作に対して利用可能なリソースの総数を含むことが意図される。
【００３１】
本明細書において、「動作ウェイト（Ａｃｔｉｖｉｔｙ  Ｗｅｉｇｈｔ）」とは、各デュアル動作に割り当てられる予め定められた数を含むことが意図されており、リソース割り当てに関してそのデュアル動作が有するべき優先度を表すものである。より高いウェイトを有する動作は、より低いウェイトを有する動作よりも優先される。
【００３２】
本明細書において、（動作当りの）「静的割り当て量（Ｓｔａｔｉｃ  Ｑｕｏｔａ）」とは、各デュアル動作に割り当てられた初期リソース・シェアを含むことが意図される。これはＧＲＬおよび動作ウェイトから得られ、デュアル動作のグローバル・リソースの相対部分となるように算出される。静的割り当て量は、下記の等式に示されるとおりの式に従って算出される。
ＳＱｉ＝（ＡＷｉ＊ＧＲＬ）／（ΣｊＡＷｊ）      （１）
ここでＳＱｉはｉ番目の静的割り当て量であり、ＡＷｉはｉ番目の動作ウェイトであり、ＧＲＬはグローバル・リソース限界であり、ΣｊはＡＷｊのｊ番目の和であり、ＡＷｊはｊ番目の動作ウェイトである。
【００３３】
本明細書において、（動作当りの）「実際のリソース境界（Ａｃｔｕａｌ  Ｒｅｓｏｕｒｃｅ  Ｂｏｕｎｄａｒｙ）」とは、各動作に割り当てられた現行リソース限界を含むことが意図される。この境界はリソース・アロケータによって設定されてもよい。この境界はその動作の静的割り当て量よりも低くなくてよい。
【００３４】
本明細書において、（動作当りの）「現行リソース使用量（Ｃｕｒｒｅｎｔ  Ｒｅｓｏｕｒｃｅ  Ｕｓａｇｅ）」とは、ある動作に割り当てられた現在のリソース数を含むことが意図される。
【００３５】
本明細書において、「フィードバック制御アルゴリズム（Ｆｅｅｄｂａｃｋ  Ｃｏｎｔｒｏｌ  Ａｌｇｏｒｉｔｈｍ）」（ＦＣＡ）とは、出力と目標値との差を常に低減させるためにシステムの挙動を利用してその動作を変更するためのアルゴリズムを含むことが意図される。
【００３６】
本明細書において、（動作当りの）「動作リソース限界（Ａｃｔｉｖｉｔｙ  Ｒｅｓｏｕｒｃｅ  Ｌｉｍｉｔ）」とは、ある動作が同時に有し得るリソースの数に対する限界を含むことが意図される。この数はＧＲＬよりも高くなくてよい。
【００３７】
本明細書において、「加法的増加／乗法的減少（Ａｄｄｉｔｉｖｅ  Ｉｎｃｒｅａｓｅ／Ｍｕｌｔｉｐｌｉｃａｔｉｖｅ  Ｄｅｃｒｅａｓｅ）」（ＡＩＭＤ）とは、伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ：ＴＣＰ）の輻輳回避に用いられるフィードバック制御アルゴリズムを含むことが意図される。これは輻輳が起こったときに輻輳ウィンドウの線形的増加を指数関数的低減と組み合わせるものであり、よって下の図３において言及されるとおり、必要とされるＦＣＡ特性を維持するフィードバック制御アルゴリズムに対する例となる。リソースを制御するステップの実施を説明するために、単なる例としてこのアルゴリズムの適合が用いられてもよい。
【００３８】
本明細書において、「加法因子（Ａｄｄｉｔｉｖｅ  Ｆａｃｔｏｒ）」とは、動的リソース割り当てのために用いられる適合されたＡＩＭＤアルゴリズムの加法部分を含むことが意図される。この因子は、境界が動作に対して維持されるときの、その動作の実際のリソース境界の１秒当りの増加を表す。
【００３９】
本明細書において、「乗法因子（Ｍｕｌｔｉｐｌｉｃａｔｉｖｅ  Ｆａｃｔｏｒ）」とは、動的リソース割り当てのために用いられる適合されたＡＩＭＤアルゴリズムの乗法部分を含むことが意図される。このパラメータは、他の動作からの要求が拒絶されたときに、動作の実際の境界に適用されるべき減少の因子を表す。
【００４０】
本明細書において、「動的ベース（Ｄｙｎａｍｉｃ  Ｂａｓｅ）」とは、実際のリソース境界の動的算出のベースを含むことが意図される。実際のリソース境界は、このベースと加法因子とを用いて定められる。このベースは、乗法的減少が起こったときはいつでも更新される。
【００４１】
本明細書において、「動的ベース経過時間（Ｄｙｎａｍｉｃ  Ｂａｓｅ  Ａｇｅ）」とは、前回動的ベースが更新されてから経過した期間（例、この期間は、たとえば秒またはマイクロ秒などのさまざまな実施形態に基づく可変量であってもよい）を含むことが意図される。これはある動作の実際のリソース境界（例、動的動作、もしくはより要求が高いかもしくは低い動作またはその両方の実際のリソース境界）の算出に用いられる。
【００４２】
前に言及したとおり、同時進行する複数の動作を維持するコンピューティング・システムはしばしば、一度に１つの動作にしか使用できないリソースに依存していることによる制約を受ける。これらのシステムは、コンピューティング・リソースの可用性ならびに動作の必要性および優先度を考慮しながら、これらの異なる動作に限られた数のリソースを分配するという課題に直面する。リソース割り当ては、リソースの可用性とともに動作の制約を考慮しながら、動作に対してさまざまなリソースをスケジュールしかつ割り当てるための手順であってもよい。リソースを必要とする動作は、必要なリソースの割り当てに対するリソース要求を発行してもよい。しかし、これらのリソース要求は受諾されることも拒絶されることもある。リソース割り当ては静的であっても動的であってもよい。静的リソース割り当てにおいて、システムのリソースは、そのシステムの存続期間にわたって動作当りのリソース・シェアを固定した状態で、複数の動作間で静的に分割されてもよい。よってある動作によってリソース要求が発行されるとき、その要求は動作当りのリソース・シェア（その動作に割り当てられたリソース）が使用されていないときにのみ受諾される。このアプローチは実施が容易かもしれないが、たとえば１つの動作はそのリソースのシェアをまったく使用していないのに対し、別の動作は常時そのリソース境界を上回っているような特定のシステムにおいては、リソースが無駄になるおそれがある。
【００４３】
動的リソース割り当てにおいては、リソースの需要に従って、実行時間中に動作当りのリソース・シェアが定められてもよい。この態様では、大量のリソースを必要とする動作が、少量のリソースを必要とする動作よりも有利にされる。もし要求の需要が変化すれば、リソース割り当てプロセスは実行時間中に動作当りのリソース・シェアを適合させる必要があり得る。動的リソース割り当て機構は、リソース割り当てスキームを最適化するために、未決の（ｐｅｎｄｉｎｇ）（すなわちまだ発行されていない）リソース要求を利用してもよい。たとえば、もし一方の動作が他方の動作の２倍の未決要求を有していれば、その動作から発行されることが予想されるより大量の要求に備えるために、要求が低い方の動作の要求のいくつかを拒絶する決定が発行されてもよい。このアプローチはリソース割り当てに対するある程度の最適化を可能にするが、それは動作の未決要求を動作がリソース・アロケータと共有することを必要とする。こうしたプロセスは常に実用的とは限らない。特定のシステム構成においては、たとえば要求がその要求自体に対して十分な帯域幅しか有さないネットワーク・リンクを介して届くときなどに、動作当りの未決リソース要求の数をリソース割り当て機構と共有することは難しいかもしれない。こうした場合には、リソース割り当て要求が発行されて初めてリソース割り当て機構がそれを利用できるようになる。
【００４４】
これに対し、前述の非効率性およびパフォーマンスの問題に対処するために、例示される実施形態は、予測不可能な負荷を有するデュアル動作システムに対するリソースのリソース割り当てのための機構を提供する。この機構は、たとえば静的割り当て量においてデュアル動作の各々を開始してもよい。デュアル動作のうちより要求の高いものに対するリソース要求に対しては、そのデュアル動作のうちより要求の低いものに対するリソース要求が拒絶されるまでリソース境界が増やされてもよい。デュアル動作のうちより要求の低いものに対するリソース要求の拒絶に応答して、そのデュアル動作のうちより要求の高いものに対するリソース境界が低減されてもよく、減少後待機モードが始動されてもよく、その減少後待機モードは、デュアル動作のうちより要求の高いものの現行リソース使用量がデュアル動作のうちより要求の高いもののリソース境界以下になるまで停止することなく続く。
【００４５】
よって、本発明の好ましい実施形態の機構は、予測不可能な負荷を有するデュアル動作システムに対するリソースのリソース割り当てに対する以下の必須要件を満たす。（１）動作当りの予め定められた優先度に従ってリソースを割り当て、より優先度の高い動作には優先度の低い動作よりも高いリソース・シェアが割り当てられること、（２）リソース要求の変化に対する調整を行い、現在リソース・シェアを使用していない動作を犠牲にして、より要求の高い動作により多くのリソースを動的に割り当てること、（３）要求の低い動作の枯渇を避けること、すなわち一方の動作がより多くのリソースを必要とし、他方が必要としないとき、後者がリソースを要求すればそれは枯渇しない、および（４）予測不可能な負荷とともに、すなわち未決のリソース要求を知ることなく動作すること。このリソース割り当てスキームは、前に発行されたリソース要求のみに基づくべきである。
【００４６】
ここで図１を参照すると、コンピューティング環境におけるデュアル動作システムに対するリソースのリソース割り当てのためのデータ記憶システム（例、仮想テープ・システム）の例示的アーキテクチャ１０が示されている。このコンピュータ・システム１０は中央処理ユニット（ｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ：ＣＰＵ）１２を含み、ＣＰＵ１２は大容量記憶装置（単数または複数）１４およびメモリ・デバイス１６に接続されている。大容量記憶装置はハード・ディスク・ドライブ（ｈａｒｄ  ｄｉｓｋ  ｄｒｉｖｅ：ＨＤＤ）デバイス、固体デバイス（ｓｏｌｉｄ  ｓｔａｔｅ  ｄｅｖｉｃｅｓ：ＳＳＤ）などを含んでもよく、これは独立ディスク冗長アレイ（ｒｅｄｕｎｄａｎｔ  ａｒｒａｙ  ｏｆ  ｉｎｄｅｐｅｎｄｅｎｔ  ｄｉｓｋｓ：ＲＡＩＤ）に構成されていてもよい。さらに説明されるバックアップ動作は、システム１０内または他の場所に位置するデバイス（単数または複数）１４において実行されてもよい。メモリ・デバイス１６は、たとえば電気的消去可能プログラマブル・リード・オンリ・メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ  ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ：ＥＥＰＲＯＭ）などのメモリ、または関連デバイスのホストを含んでもよい。メモリ・デバイス１６および大容量記憶装置１４は、信号を有する（ｓｉｇｎａｌ−ｂｅａｒｉｎｇ）媒体を介してＣＰＵ１２に接続される。加えて、ＣＰＵ１２は通信ポート１８を通じて通信ネットワーク２０に接続されてもよく、通信ネットワーク２０には複数の付加的コンピュータ・システム２２および２４が接続されている。
【００４７】
図２は、本発明の好ましい実施形態に従うコンピュータ・システムにおけるデータ記憶システムのハードウェア構造を示す例示的ブロック図２００である。なお、本発明の本実施形態の機構は、リソース割り当てを必要とし得るあらゆるデュアル動作コンピューティング・システムを説明するものである。例示的実施形態の１つにおいては、単なる例として記憶サブシステムまたは記憶装置コントローラが説明されるが、これが本発明の範囲を制限することは意図されていない。図２を参照すると、ホスト・コンピュータ２１０、２２０、２２５が示されており、その各々は、デュアル動作システムに対するリソースのリソース割り当てのためのデータ記憶システム２００の一部としてデータ処理を行うための中央処理ユニットとして働く。これらのホスト（物理デバイスまたは仮想デバイス）２１０、２２０および２２５は、データ記憶システム２００において本発明の好ましい実施形態の目的を達成するための１つまたはそれ以上の新たな物理デバイスまたは論理デバイスであってもよい。一実施形態においては単なる例として、データ記憶システム２００がＩＢＭ（ＩＢＭ社の登録商標）Ｓｙｓｔｅｍ  Ｓｔｏｒａｇｅ（ＩＢＭ社の登録商標）ＤＳ８０００（ＩＢＭ社の登録商標）として実現されてもよい。ネットワーク接続２６０は、ファイバ・チャネル・ファブリック、ファイバ・チャネル・ポイント・ツー・ポイント・リンク、イーサネット（Ｒ）・ファブリックもしくはポイント・ツー・ポイント・リンク上のファイバ・チャネル、ＦＩＣＯＮ（ＩＢＭ社の登録商標）もしくはＥＳＣＯＮ（ＩＢＭ社の登録商標）Ｉ／Ｏインタフェース、あらゆる他のＩ／Ｏインタフェース・タイプ、ワイヤレス・ネットワーク、ワイヤード・ネットワーク、ＬＡＮ、ＷＡＮ、異種、同種、公共（すなわちインターネット）、私有、またはそのあらゆる組み合わせであってもよい。ホスト２１０、２２０および２２５はローカルであっても、１つまたはそれ以上の場所に分散されていてもよく、これらのホストには記憶装置コントローラ２４０に対するあらゆるタイプのファブリック（またはファブリック・チャネル）（図２には示さず）またはネットワーク・アダプタ２６０が備えられていてもよく、それはたとえばファイバ・チャネル、ＦＩＣＯＮ（ＩＢＭ社の登録商標）、ＥＳＣＯＮ（ＩＢＭ社の登録商標）、イーサネット（Ｒ）、光ファイバ、ワイヤレス、または同軸アダプタなどであってもよい。したがってデータ記憶システム２００には通信のために好適なファブリック（図２には示さず）またはネットワーク・アダプタ２６０が備えられている。図２において、データ記憶システム２００は記憶装置コントローラ２４０および記憶装置２３０を含むことが示される。
【００４８】
本明細書に記載される方法のより明確な理解を容易にするために、例示的実施形態の１つにおいては単なる例として、図２における記憶装置コントローラ２４０はマイクロプロセッサ２４２と、システム・メモリ２４３と、不揮発性記憶装置（ｎｏｎｖｏｌａｔｉｌｅ  ｓｔｏｒａｇｅ：「ＮＶＳ」）２１６とを含む単一の処理ユニットとして示されており、これについては以下により詳細に説明する。なお、いくつかの実施形態において、記憶装置コントローラ２４０は複数の処理ユニットで構成されており、各々の処理ユニットは自身のプロセッサ複合体およびシステム・メモリを有し、データ記憶システム２００内の専用ネットワークによって相互接続されている。記憶装置２３０は、たとえば記憶装置アレイなどの１つまたはそれ以上の記憶装置で構成されていてもよく、それらは記憶装置ネットワークによって記憶装置コントローラ２４０に接続される。
【００４９】
いくつかの実施形態においては単なる例として、記憶装置２３０に含まれるデバイスは接続されてループ・アーキテクチャになっていてもよい。記憶装置コントローラ２４０は記憶装置２３０を管理し、記憶装置２３０に対する書込みおよび読取り要求の処理を容易にする。記憶装置コントローラ２４０のシステム・メモリ２４３はプログラム命令およびデータを保存しており、プロセッサ２４２は、記憶装置２３０の管理に関連する機能および方法ステップを実行するため、ならびにコンピュータ記憶装置環境におけるデュアル動作システムに対するリソースのリソース割り当てのための本発明の好ましい実施形態のステップおよび方法を実行するために、それにアクセスしてもよい。一実施形態において、システム・メモリ２４３は、本明細書に記載される方法および動作を含む、コンピュータ記憶装置環境におけるデュアル動作システムに対するリソースのリソース割り当てのための動作ソフトウェア２５０を含むか、それに関連付けられるか、またはそれと通信する。図２に示されるとおり、システム・メモリ２４３はさらに記憶装置２３０に対するキャッシュ２４５を含むか、またはそれと通信してもよく、本明細書においてキャッシュ２４５は「キャッシュ・メモリ」とも呼ばれ、書込み／読取り要求およびその関連データをそれぞれ示す「書込みデータ」および「読取りデータ」をバッファリングするためのものである。一実施形態において、キャッシュ２４５はシステム・メモリ２４３の外部のデバイスに割り当てられるが、なおもマイクロプロセッサ２４２によるアクセスが可能であり、本明細書に記載される動作を実行することに加えて、データ損失に対する付加的なセキュリティを提供する働きをしてもよい。
【００５０】
いくつかの実施形態において、キャッシュ２４５は揮発性メモリおよび不揮発性メモリによって実現されてもよく、データ記憶システム２００のパフォーマンス向上のためにローカル・バス（図２には示さず）を介してマイクロプロセッサ２４２に結合されてもよい。データ記憶装置コントローラに含まれるＮＶＳ２１６はマイクロプロセッサ２４２によるアクセスが可能であってもよく、他の図面に記載される本発明の好ましい実施形態の動作および実行に対する付加的サポートを提供する働きをする。ＮＶＳ２１６は「永続的」キャッシュまたは「キャッシュ・メモリ」と呼ばれることもあり、中に保存されたデータを保持するために外部電力を利用しても利用しなくてもよい不揮発性メモリによって実現されてもよい。ＮＶＳは、本発明の好ましい実施形態の目的を達成するために好適なあらゆる目的のために、キャッシュ２４５内またはキャッシュ２４５とともに保存されてもよい。いくつかの実施形態においては、データ記憶システム２００に対する電力損失の場合に、たとえばバッテリなどのバックアップ電源（図２には示さず）がＮＶＳ２１６に保存されたデータを保持するために十分な電力をＮＶＳ２１６に供給する。特定の実施形態において、ＮＶＳ２１６の容量はキャッシュ２４５の総容量以下であってもよい。
【００５１】
記憶装置２３０は、たとえば記憶装置アレイなどの１つまたはそれ以上の記憶装置で物理的に構成されてもよい。記憶装置アレイは、たとえばハード・ディスクなど、個々の記憶装置の論理的グループ化であってもよい。特定の実施形態において、記憶装置２３０はＪＢＯＤ（単なるディスクの束（Ｊｕｓｔ  ａ  Ｂｕｎｃｈ  ｏｆ  Ｄｉｓｋｓ））アレイまたはＲＡＩＤ（独立ディスク冗長アレイ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙ  ｏｆ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｄｉｓｋｓ））アレイで構成される。物理記憶装置アレイの集合体がさらに組み合わされてランクを形成してもよく、ランクは物理記憶装置を論理的構成から分離する。ランク内の記憶空間が論理ボリュームに割り当てられてもよく、論理ボリュームは書込み／読取り要求において指定される記憶位置を定めるものである。
【００５２】
一実施形態においては単なる例として、図２に示されるとおりの記憶システムは論理ボリュームまたは単に「ボリューム」を含んでもよく、異なる種類の割り当てを有してもよい。記憶装置２３０ａ、２３０ｂおよび２３０ｎはデータ記憶システム２００内のランクとして示されており、本明細書においてはランク２３０ａ、２３０ｂおよび２３０ｎと呼ぶ。ランクはデータ記憶システム２００に対してローカルであってもよいし、物理的に離れた（リモート）位置に置かれていてもよい。言い換えると、ローカル記憶装置コントローラがリモート記憶装置コントローラに接続してリモート位置の記憶装置を管理してもよい。ランク２３０ａは、２つの全体ボリューム２３４および２３６、ならびに１つの部分ボリューム２３２ａで構成されることが示される。ランク２３０ｂは別の部分ボリューム２３２ｂとともに示される。つまりボリューム２３２はランク２３０ａおよび２３０ｂにまたがって割り当てられてもよい。ランク２３０ｎはボリューム２３８に完全に割り当てられていることが示されており、つまりランク２３０ｎはボリューム２３８に対する物理記憶装置全体を示す。上記の例から、ランクは１つまたはそれ以上の部分ボリュームもしくは全体ボリュームまたはその両方を含むように構成されてもよいことが認識されるだろう。ボリュームおよびランクは、記憶装置の固定されたブロックを表すいわゆる「トラック」にさらに分割されてもよい。したがってトラックは所与のボリュームに関連付けられ、所与のランクが与えられてもよい。
【００５３】
一実施形態においては単なる例として、記憶装置コントローラ２４０は、コンピューティング環境におけるデュアル動作システムに対するリソースのリソース割り当てを助けるためのリソース・アロケータ・モジュール２５５と、減少後待機（ｗａｉｔ  ａｆｔｅｒ  ｄｅｃｒｅａｓｅ）（または本明細書および図面を通じて、減少後待機する（ｗａｉｔｉｎｇ  ａｆｔｅｒ  ｄｅｃｒｅａｓｅ）と呼ばれることもある）モジュール２５６と、リソース境界モジュール２５７と、リソース要求モジュール２４７とを含んでもよい。リソース・アロケータ・モジュール２５５、減少後待機モジュール２５６、リソース境界モジュール２５７、およびリソース要求モジュール２４７の各々は、１つもしくはそれ以上のフィードバック制御モジュール（図示せず）を含むように適合されるか、または１つもしくはそれ以上のフィードバック制御モジュール（図示せず）と通信するように構成されるか、またはその両方であってもよい。リソース・アロケータ・モジュール２５５、減少後待機モジュール２５６、リソース境界モジュール２５７、およびリソース要求モジュール２４７は、記憶装置コントローラ２４０、ホスト２１０、２２０、２２５、および記憶装置２３０のあらゆる構成要素とともに働いてもよい。リソース・アロケータ・モジュール２５５、減少後待機モジュール２５６、リソース境界モジュール２５７、およびリソース要求モジュール２４７は、すべてが構造的に１つの完全なモジュールであって、コンピューティング環境におけるデュアル動作システムに対するリソースのリソース割り当てのために互いとともに共同して作業してもよいし、各々が独立したモジュールであって、以下に説明される機構に従って設計および構成されたとおりの個々の機能を行ってもよい。リソース・アロケータ・モジュール２５５、減少後待機モジュール２５６、リソース境界モジュール２５７、およびリソース要求モジュール２４７が１つのモジュールであるとき、フィードバック制御モジュール（図示せず）はその１つの完全なモジュール内でともに実現されてもよい。加えてリソース・アロケータ・モジュール２５５、減少後待機モジュール２５６、リソース境界モジュール２５７、およびリソース要求モジュール２４７は、キャッシュ２４５または記憶装置コントローラ２４０のその他の構成要素の中に位置して、本発明の好ましい実施形態の目的を達成してもよい。
【００５４】
記憶装置コントローラ２４０は、ホスト・コンピュータ２１０、２２０、２２５に対するファイバ・チャネル・プロトコルを制御するための制御スイッチ２４１と、記憶装置コントローラ２４０すべてを制御するためのマイクロプロセッサ２４２と、記憶装置コントローラ２４０の動作を制御するためのマイクロプログラム（動作ソフトウェア）２５０を保存するための不揮発性制御メモリ２４３と、データを一時的に保存（バッファリング）するためのキャッシュ２４５と、キャッシュ２４５がデータを読み書きするのを助けるためのバッファ２４４と、記憶装置２３０へのデータ転送またはそこからのデータ転送を制御するためのプロトコルを制御するための制御スイッチ２４１と、リソース・アロケータ・モジュール２５５と、減少後待機モジュール２５６と、リソース境界モジュール２５７と、情報が設定され得るリソース要求モジュール２４７とによって構築されてもよい。コンピューティング環境におけるデュアル動作システムに対するリソースのリソース割り当てを助けるために、本発明の好ましい実施形態によって複数のバッファ２４４が実現されてもよい。
【００５５】
一実施形態においては単なる例として、ホスト・コンピュータまたは１つもしくはそれ以上の物理デバイスもしくは仮想デバイス２１０、２２０、２２５と、記憶装置コントローラ２４０とは、インタフェースとしてのネットワーク・アダプタ（これはファイバ・チャネルであってもよい）２６０を通じて、すなわち「ファブリック」と呼ばれるスイッチを介して接続される。一実施形態においては単なる例として、図２に示されるシステムの動作が説明される。マイクロプロセッサ２４２はメモリ２４３を制御して、ホスト・デバイス（物理または仮想）２１０からのコマンド情報およびホスト・デバイス（物理または仮想）２１０を識別するための情報を保存してもよい。制御スイッチ２４１、バッファ２４４、キャッシュ２４５、動作ソフトウェア２５０、マイクロプロセッサ２４２、メモリ２４３、ＮＶＳ２１６、リソース・アロケータ・モジュール２５５、減少後待機モジュール２５６、リソース境界モジュール２５７、およびリソース要求モジュール２４７は互いに通信しており、分離していても、１つの独立した構成要素（単数または複数）であってもよい。加えて、すべての構成要素ではなくてもいくつかの構成要素、たとえば動作ソフトウェア２５０などが、コンピューティング環境におけるデュアル動作システムに対するリソースのリソース割り当てのためにメモリ２４３とともに含まれてもよい。記憶装置内の各々の構成要素はともにリンクしていてもよく、本発明の好ましい実施形態に好適な目的のために互いに通信してもよい。
【００５６】
前に言及したとおり、例示される実施形態は、コンピューティング環境内のデュアル動作システムに対する複数のリソースのリソース割り当てのための機構を提供する。図３は、デュアル動作システムに対するリソースのリソース割り当てのための構成要素を有するコンピューティング環境を示す例示的ブロック図３００を示す。動作３０２（動作１  ３０２Ａおよび動作２  ３０２Ｂ）によって発行されたリソース要求３１２が受諾されるのは、その動作の現行リソース使用量（動作データ３０６から得られる）がその動作の実際のリソース境界よりも低いときだけである。この境界を超えた動作３０２からの要求３１２は拒絶され得る。動作３０２の実際のリソース境界は最初にその動作の静的割り当て量に設定されてもよく、各動作の現行リソース使用量はゼロに設定されてもよい（例、動作データ３０６）。よって、自身の静的割り当て量（例、動作データ３０６から得られる）をまだ超えていない動作３０２から発行されたリソース要求３１２は受諾され得る。動作３０２（例、３０２Ａ）がその静的割り当て量に達すると、実行時間中にフィードバック制御アルゴリズム（ＦＣＡ）によってその実際のリソース境界が動的に定められてもよく、この実際のリソース境界は、この動作３０２（例、３０２Ａ）の負荷と、要求がより低いかもしれない他方の動作（例、もし３０２Ａが要求が高い方の動作であれば３０２Ｂ）によって必要とされ得るリソース負荷との両方に影響され得る。動作３０２（例、３０２Ａ）は、動的動作（またはより要求が高い動作）と呼ばれる。ＦＣＡは、以下に説明されるとおりの特性を有する必要がある。他方の動作（例、もし３０２Ａが要求が高い方の動作であれば３０２Ｂ）のリソースの要求３１２が拒絶されない限り、ＦＣＡは動的動作の実際のリソース境界を徐々に増分させる。動的動作が取ったリソースの現行数がその動作の静的割り当て量よりも高くなるとき、他方の動作（例、もし３０２Ａが要求が高い方の動作であれば３０２Ｂ）の有効境界は、グローバル・リソース限界（ＧＲＬ）と、この動作（例、３０２Ａ）の現行リソース使用量との差になる。結果的に、他方の動作（例、もし３０２Ａが要求が高い方の動作であれば３０２Ｂ）の要求は、たとえその現行リソース使用量が静的割り当て量よりも低くても拒絶されるかもしれない。一旦他方の動作（例、もし３０２Ａが要求が高い方の動作であれば３０２Ｂ）によるリソースの要求が拒絶されると、ＦＣＡはすぐに動的動作（例、３０２Ａ）の実際のリソース境界を減少させる。実際のリソース境界は静的割り当て量よりも低くならなくてもよいため、ＦＣＡは実際のリソース境界をその動作の静的割り当て量まで減少させるだけであってもよい。このフィードバック制御の利用によって、リソース要求が高い方の動作に対するリソース割り当てをリソース要求が低い方の動作よりも徐々に優先させることができる。しかしながら動作負荷が変わると、その変化した挙動によって他の動作の要求が拒絶されるかもしれず、実際のリソース境界を迅速に調整してその変化に適応してもよい。よって、本発明の好ましい実施形態の機構は、動的リソース割り当てを達成する能力を提供する。
【００５７】
例示される実施形態の機構は、たとえば以下に挙げられる動的リソース割り当ての必要条件の包括的セットに対応してそれを満たそうとする。第１に、この機構は動作ウェイトを用いて、動作の予め定められた優先順位付けをサポートし、ここでは一方の動作が他方よりも有利にされてもよい。第２に、フィードバック制御アルゴリズムの利用によって、この機構はリソース要求の変化に対して動的な調整を行い、リソースのシェアを使用していない動作を犠牲にして要求の高い方の動作により多くのリソースを割り当てることが可能になる。第３に、上に言及したアルゴリズムは要求が低い方の動作が枯渇しないことを確認し、たとえば一方の動作がより多くのリソースを必要とし、他方が必要としないとき、一旦後者がリソースを必要とすれば、フィードバック制御アルゴリズムはその要求に適応するよう迅速に調整を行う。第４に、この機構は予測不可能な負荷で動作してもよく、すなわちこの機構があらゆる未決リソース要求を認識することは要求されない。すべての決定は、未決の将来の要求ではなくすでに発行されたリソース要求のみに基づいていてもよい。
【００５８】
下に説明するとおり、一実施形態において、この機構は前に言及したとおりに動的リソース割り当ての必要条件の包括的セットに対応しようとする。図４は、デュアル動作システムに対するリソースのリソース割り当てのための例示的方法４００を示す流れ図である。この方法４００を開始する（ステップ４０２）のは、静的割り当て量においてデュアル動作の各々を開始するステップ（ステップ４０４）である。この静的割り当て量は、固定された静的割り当て量もしくは可変の静的割り当て量またはその両方であってもよく、必要であれば時間とともに変化するように構成／適合される。デュアル動作（単数または複数）のうちより要求の高いものに対するリソース要求に対しては、そのデュアル動作（単数または複数）のうちより要求の低いものに対するリソース要求が拒絶され得るまでリソース境界が増やされてもよい（ステップ４０６）。この方法４００は、デュアル動作（単数または複数）のうちより要求の低いものに対するリソース要求が拒絶されたかどうかを判定する（ステップ４０８）。デュアル動作のうちより要求の低いものに対するリソース要求の拒絶に応答して、よりアクティブなデュアル動作に対するリソース境界が低減されてもよい（ステップ４１０）。減少後待機モードが始まり、現行リソース使用量が、低減されたよりアクティブなデュアル動作（単数または複数）のリソース境界以下になるまで、この方法４００は減少後待機モードであり続けてもよい（ステップ４１２）。リソース割り当ては進行中のプロセスであってもよいため、この方法４００は繰り返しステップ４０６に戻り、より要求の低いデュアル動作（単数または複数）に対するリソース要求が拒絶され得るまで、より要求の高いデュアル動作（単数または複数）に対するリソース要求に対するリソース境界を増やし続けてもよい。この方法はステップ４０６に続く各後続ステップを継続する。この方法４００は終了する（ステップ４１４）。
【００５９】
一実施形態において、デュアル動作のうちの１つがリソースを必要とするとき、それはリソース要求を発行してもよい。この機構は各動作が有するリソースの数（例、現行リソース使用量）を把握し、この現行リソース使用量を動作のリソース境界とともに利用して、この要求を受諾するか否かを判定する。この機構がリソース要求を受諾するとき、一旦その動作がリソースの使用を終了すると、その動作は現在そのリソースがフリー／利用可能であることを示す通知を送ってもよく、それに従ってその動作の現行リソース使用量が更新されてもよい。リソース要求が拒絶されるとき、それに従って、図５により詳細に説明されるとおりにリソース境界および動的ベースが反応する。図５は、動的動作の実際のリソース境界および動的ベースの挙動を示す。図５は、時間に対する実際のリソース境界の挙動を示すコンピューティング環境を示す例示的スナップショットを示す。動的動作の実際のリソース境界は、一般的に下記の等式に記載されるとおり、その動作の動的ベース、動的ベース経過時間および加法因子によって定められてもよい。
ＲＢ＝ＤＢ＋（ＤＢＡ）＊（ＡＦ）      （２）
ここでＲＢはリソース境界（例、実際のリソース境界）であり、ＤＢは動的ベースであり、ＤＢＡは動的ベース経過時間であり、ＡＦは加法因子である。動的ベースは、最初にその動作の静的割り当て量に設定され、乗法的減少が起こらない限り変わることはない。他方の動作（例、より要求が低いデュアル動作）からの要求が拒絶されるとき、乗法的減少が行われてもよく、実際のリソース境界が更新されてもよい。一実施形態において、下記の等式は乗法的減少がどのように行われるかを示す。
ＤＢ＝（ＣＲＢ）＊（ＭＦ）      （３）
ここでＤＢは動的ベースであり、ＣＲＢは現行の実際のリソース境界であり、ＭＦは乗法因子である。乗法的減少は動的ベース経過時間をリセットするため、減少が起こった直後に実際のリソース境界が新たな動的ベースになってもよい。乗法的減少が起こると、この機構は減少後待機と呼ばれる状態で、動作の現行リソース使用量が実際に新たな境界に達するのを待つ。これによって、他方の動作が常時拒絶される場合にこの動作の実際のリソース境界が劇的に低下することが防がれる。動作の現行リソース使用量が新たな（減少した）実際のリソース境界に達していない限り、実際のリソース境界は一定のままであり、これはリソース境界が加法的に増加されることも乗法的に減少されることもないことを意味する。一旦動作の現行リソース使用量がリソース境界に達する（例、動作の現行リソース使用量がリソース境界以下である）と、動的ベース経過時間が更新され、リソース境界の加法的増加が再び始まる。
【００６０】
上に言及したとおり（例、図３および図４）、デュアル動作はリソースの使用のためのリソース要求を発行してもよい。前述を念頭に置いて、図６はリソース要求を処理するための例示的方法６００を示す流れ図である。この方法６００を開始する（ステップ６０２）のは、リソース要求を発行するステップ（ステップ６０４）である。次いでこの方法６００は、割り当てられたリソースの総数がグローバル・リソース限界（ＧＲＬ）に達したかどうかを判定する（ステップ６０６）。もしイエスであれば、そのリソース要求はマーク付けされて（ステップ６０８）、拒絶されてもよい（ステップ６２４）。もしノーであれば、この方法６００は、その動作に割り当てられたリソースの数がリソース境界に達したかどうかを判定する（ステップ６１０）。もしイエスであれば、そのリソース要求は拒絶されてもよい（ステップ６２４）。もしノーであれば、この方法６００は、その動作に割り当てられたリソースの数が静的割り当て量よりも低いかどうかを判定する（ステップ６１２）。もしイエスであれば、その動作の現行リソース・カウンタが増加されてもよく（ステップ６１８）、そのリソース要求は受諾されてもよい（ステップ６２０）。もしノーであれば、この方法６００は、他方の動作（例、この他方の動作はデュアル動作のより要求が高いものであっても低いものであってもよい）に割り当てられたリソースの数がそのリソース境界に達したかどうかを判定する（ステップ６１４）。もしイエスであれば、その動作の現行リソース・カウンタが増加されてもよく（ステップ６１８）、そのリソース要求は受諾されてもよい（ステップ６２０）。もしノーであれば、その動作の実際のリソース境界が定められてもよい（ステップ６１６）。次いでこの方法６００は、その動作に割り当てられたリソースの数がその実際のリソース境界に達したかどうかを判定する（ステップ６２２）。もしノーであれば、その動作の現行リソース・カウンタが増加されてもよく（ステップ６１８）、そのリソース要求は受諾されてもよい（ステップ６２０）。もしイエスであれば、そのリソース要求は拒絶されてもよい（ステップ６２４）。
【００６１】
代替的な実施形態において、本発明の好ましい実施形態の機構は、リソースの要求を受け取ると、（両方の動作に対して）それまでに割り当てられたリソースの総数がグローバル・リソース限界（ＧＲＬ）に達したかどうかを判定する。もしＧＲＬに達していれば、（いずれかの動作が自身のリソースのいくつかを解放するまで）割り当てるべきリソースが残っていないかもしれないため、その要求は拒絶され得る。その拒絶はマーク付けされてもよく、この機構は動的リソース境界（例、図２のリソース境界モジュール２５７）にその拒絶を通知する（図８を参照）。もしＧＲＬに達していなければ、この機構は、要求を出している動作に割り当てられたリソースの数がその動作のリソース限界に達したかどうかを判定する。もしそうであれば、ここでも（この動作が自身のリソースのいくつかを解放するまで）この動作に割り当てるために利用可能なリソースがないため、その要求は拒絶され得る。要求を出している動作に割り当てられたリソースの数がその動作のリソース限界に達していなければ、この機構は、要求を出している動作に割り当てられたリソースの数がその動作の静的割り当て量よりも低いかどうかを判定する。もしそうであれば、リソースは利用可能であり（割り当てられたリソースの総数がＧＲＬよりも低いため）、その動作の重み付けされたリソース・シェア（すなわち静的割り当て量）が消費されていないため、その動作は最終的にリソースを使用する資格を有してもよい。この機構はその動作の現行リソース使用量カウンタを増加して、その要求を受諾してもよい。要求を出している動作に割り当てられたリソースの数がその動作の静的割り当て量よりも高い場合は、この機構は、他方の動作（例、この他方の動作はより要求が高いデュアル動作であっても低いデュアル動作であってもよい）がその動作のリソース限界に達したかどうかを判定する。もしそうであれば、他方の動作はさらなるリソースを受け取ることもないし、そこにさらなるリソースが発行されることもない。よって利用可能なリソースが存在するため（割り当てられたリソースの総数がＧＲＬよりも低いため）、このリソース要求は安全に受諾され得る。この機構はその動作の現行リソース使用量カウンタを増加させてその要求を受諾してもよい。もし他方の動作（例、より要求の低いデュアル動作）がその動作のリソース限界に達していれば、その動作の境界が動的に定められてもよく（図７に記載されるとおり）、その境界がその動作の現行リソース使用量と比較されてもよい。もし現行リソース使用量がその動作の実際のリソース境界に達していれば、その要求は拒絶されてもよい。もし現行リソース使用量がその動作の実際のリソース境界に達していなければ、この機構はその動作の現行リソース使用量カウンタを増加させてその要求を受諾してもよい。最終的に、もしリソース要求が受諾されれば、その動作はそのリソースの使用が終了したときにリソース・アロケータ（例、図２のリソース・アロケータ・モジュール２５５）に通知してもよい。このリソース解放手順によって、その動作の現行リソース使用量カウンタが因子１だけ減少する（ただしこの因子１の減少は、ユーザの要求および実施要件に基づいて、たとえば２、３、４などのさまざまな因子だけ減少するように構成されてもよい）。
【００６２】
図６（ステップ６１６）に言及されるとおり、その動作の実際のリソース境界が定められてもよい。図７は、リソース境界を定めるための例示的方法７００を示す流れ図である。この方法７００を開始するのは、その動作が動的ベースを有するかどうかを判定するステップ（ステップ７０４）である。もしイエスであれば、次いでこの方法７００は、その動作が減少後待機モードであるかどうかを判定する（ステップ７０６）。もしノーであれば、次いでこの方法７００はその動作に対する動的ベースを作成する（ステップ７０８）。動的ベースが作成された後に、他方のデュアル動作の動的ベースが除去されてもよい（ステップ７１０）。減少後待機モードはオフに設定され（オフにされ）てもよく（ステップ７１２）、動的ベース経過時間がリセットされてもよい（ステップ７１４）。ここで実際のリソース境界が動的ベースになるか、もしくは動的ベースになるよう設定されるか、またはその両方であってもよい（ステップ７１６）。この方法７００は終了する（ステップ７２４）。ここでステップ７０６に戻って、もしその動作が減少後待機モードでなければ、実際のリソース境界は、加法的増加を付加された動的ベースになるか、もしくはそれになるよう設定されるか、またはその両方であってもよく（ステップ７２２）、次いでこの方法７００は終了する（ステップ７２４）。もしその動作が減少後待機モードであれば、この方法７００は、現行リソース使用量が動的ベースに達したかどうかを判定する（ステップ７２０）。もしイエスであれば、この方法７００はステップ７１２に移動し、減少後待機モードをオフに設定し（ステップ７１２）、ステップ７１２からのステップを続ける。もしノーであれば、実際のリソース境界が動的ベースになるか、もしくは動的ベースになるよう設定されるか、またはその両方であり（ステップ７１６）、次いでこの方法７００は終了する（ステップ７２４）。
【００６３】
代替的な実施形態において、動作の実際のリソース境界を判定するための機構は、その動作が動的モードであるかどうかをチェックする。もしその動作が動的ベースを有さなければ、その動作に対する動的ベースが作成されてもよく（その動作の静的割り当て量に初期化される）、動的ベース経過時間がリセットされてもよく、「減少後待機」モードがリセットされてもよい。デュアル動作のうちの１つだけが同時に動的ベースを有し得るため、他方の動作の動的ベースは除去されてもよい。動的ベース（この場合には動作の静的割り当て量に等しい）は戻されてもよい。もしその動作が動的ベースを有すれば、この手順はその動作が「減少後待機」モードであるかどうかをチェックする。減少後待機モードがアクティブでない場合、戻された実際のリソース境界は、動的加法的増加を加えた動的ベースであってもよい。もしその動作が確かに「減少後待機」モードであれば、この機構は、その動作の現行リソース使用量が動的ベースに達したかどうかをチェックする。もしその動作の現行リソース使用量が動的ベースに達していなければ、次いでその動作は「減少後待機」モードに残ってもよく、戻された境界が動的ベースであってもよい。もしその動作の現行リソース使用量が動的ベースに達していれば、次いで「減少後待機」モードは終了されてオフにされてもよい。動的ベース経過時間がリセットされてもよく（その動作が「減少後待機」モードに保持されていた時間を加法的増加機構がスキップするため）、その動作の実際のリソース境界として動的ベースが戻されてもよい。
【００６４】
上の図６（ステップ６０８）に言及されるとおり、もし要求が拒絶されれば、その拒絶がマーク付けされてもよい。この拒絶をマーク付けするステップをさらに示すために、図８はリソース要求の拒絶をマーク付けするための手順のための例示的方法８００を示す流れ図である。この方法８００を開始する（ステップ８０２）と、この方法８００はその動作が減少後待機モードであるかどうかを判定する（ステップ８０４）。もしノーであれば、この方法８００は、拒絶されなかった動作が動的ベースを有するかどうかを定める（ステップ８１４）。もしその動作が減少後待機モードであれば、この方法８００は、動的動作（より要求が高いデュアル動作）の現行リソース使用量がその動作の動的ベースに達したかどうかを判定する（ステップ８０６）。もしノーであれば、この方法８００はステップ８１４に戻って、拒絶されなかった動作が動的ベースを有するかどうかを定める。もしイエスであれば、減少後待機モードはオフに設定されても（オフにされても）よい（ステップ８１０）。動的ベース経過時間がリセットされてもよい（ステップ８１２）。動的ベース経過時間をリセットすると、この方法８００はステップ８１４に戻って、拒絶されなかった動作が動的ベースを有するかどうかを定める。もし拒絶されなかった動作が動的ベースを有すれば、この方法８００は、その動作が減少後待機モードであるかどうかを判定する（ステップ８１６）。もしイエスであれば、この方法８００は終了する（ステップ８２２）。もしノーであれば、この方法８００は動的ベースに乗法的減少を適用し、動的ベース経過時間をリセットする（ステップ８１８）。次いで減少後待機モードがオンに設定されても（オンにされても）よい（ステップ８２０）。次いでこの方法８００は終了する（ステップ８２２）。しかし、もし拒絶されなかった動作が動的ベースを有さなければ、この方法８００は終了する（ステップ８２２）。
【００６５】
リソース要求の拒絶をマーク付けするための代替的な実施形態において、この機構は、その動作が「減少後待機」モードであるかどうかを判定する。もしそうであれば、この機構は、「減少後待機」モードが終了すべきかどうか（すなわちこのモードに入った動作の現行リソース使用量がその動的ベース以下であるかどうか）をチェックする。もしそのモードをオフにすべきであれば、この機構はその状態を更新して動的ベース経過時間をリセットする。次にこの機構は、他方の動作（すなわち拒絶されなかったもの）が動的ベースを有するかどうかをチェックする。もしノーであれば、他方の動作の実際のリソース境界を動的に定めなくてもよいため、さらなる動作を行う必要はない。代替的に、もし他方の動作が動的ベースを有すれば、その他方の動作の実際のリソース境界を乗法的に減少させる必要があり得る。次いでこの機構は、「減少後待機」モードがオンにされているかどうかをチェックする。もしそうであれば、この機構はまだ前の減少が効果を示すのを待っている状態であるため、減少は行われない。もし他方の動作が動的ベースを有し、かつ「減少後待機」モードでなければ、実際のリソース境界が等式（３）に従って乗法的に減少されてもよい。動的ベースが変更されたため、動的ベース経過時間がリセットされてもよく、その機構が乗法的減少に対する調整を行えるように「減少後待機」モードがオンにされてもよい。
【００６６】
当業者に認識されるとおり、本発明の局面はシステム、方法またはコンピュータ・プログラム製品として具現化されてもよい。したがって本発明の局面は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはソフトウェアおよびハードウェアの局面を組み合わせた実施形態の形を取ってもよく、本明細書においてこれらはすべて一般的に「回路」、「モジュール」または「システム」と呼ばれることがある。さらに、本発明の局面は、コンピュータ読取り可能プログラム・コードが具現化されている１つまたはそれ以上のコンピュータ読取り可能媒体（単数または複数）において具現化されるコンピュータ・プログラム製品の形を取ってもよい。
【００６７】
１つまたはそれ以上のコンピュータ読取り可能媒体（単数または複数）のあらゆる組み合わせが用いられてもよい。コンピュータ読取り可能媒体は、コンピュータ読取り可能信号媒体またはコンピュータ読取り可能記憶媒体であってもよい。コンピュータ読取り可能記憶媒体は、たとえば電子、磁気、光学、電磁気、赤外、または半導体のシステム、装置、デバイス、または前述のもののあらゆる好適な組み合わせなどであってもよいがそれに限定されない。コンピュータ読取り可能記憶媒体のより特定的な例（非網羅的なリスト）は以下を含む。すなわち、１つまたはそれ以上のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ：ＲＡＭ）、リード・オンリ・メモリ（ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ：ＲＯＭ）、消去可能プログラマブル・リード・オンリ・メモリ（ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ：ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク・リード・オンリ・メモリ（ｃｏｍｐａｃｔ  ｄｉｓｃ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ：ＣＤ−ＲＯＭ）、光学記憶装置、磁気記憶装置、または前述のもののあらゆる好適な組み合わせである。本文書の状況において、コンピュータ読取り可能記憶媒体は、命令実行システム、装置またはデバイスによる使用、またはそれに関連する使用のためのプログラムを含有または保存し得るあらゆる有形の媒体であってもよい。
【００６８】
コンピュータ読取り可能媒体において具現化されるプログラム・コードは、ワイヤレス、ワイヤード、光ファイバ・ケーブル、ＲＦなど、または前述のもののあらゆる好適な組み合わせを含むがそれに限定されないあらゆる適切な媒体を用いて送信されてもよい。本発明の局面のための動作を行うためのコンピュータ・プログラム・コードは、オブジェクト指向プログラミング言語、たとえばＪａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋など、および従来の手続き型プログラミング言語、たとえば「Ｃ」プログラミング言語または類似のプログラミング言語などを含む、１つまたはそれ以上のプログラミング言語のあらゆる組み合わせで書かれていてもよい。プログラム・コードは、すべてがユーザのコンピュータで実行されてもよいし、スタンド・アロン・ソフトウェア・パッケージとして部分的にユーザのコンピュータで実行されてもよいし、一部がユーザのコンピュータで、一部がリモート・コンピュータで実行されてもよいし、すべてがリモート・コンピュータまたはサーバで実行されてもよい。後者のシナリオにおいて、リモート・コンピュータは、ローカル・エリア・ネットワーク（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ：ＬＡＮ）または広域ネットワーク（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ：ＷＡＮ）を含むあらゆるタイプのネットワークを通じてユーザのコンピュータに接続されてもよいし、（たとえば、インターネット・サービス・プロバイダを用いてインターネットを通じて）外部コンピュータへの接続が行われてもよい。
【００６９】
本発明の実施形態に従う方法、装置（システム）およびコンピュータ・プログラム製品の流れ図もしくはブロック図またはその両方を参照して、本発明の局面について上述した。流れ図もしくはブロック図またはその両方の各ブロック、および流れ図もしくはブロック図またはその両方におけるブロックの組み合わせは、コンピュータ・プログラム命令によって実現され得ることが理解されるだろう。これらのコンピュータ・プログラム命令が、汎用コンピュータもしくは特定目的のコンピュータのプロセッサ、またはマシンを生成するためのその他のプログラマブル・データ処理装置に与えられることによって、そのコンピュータのプロセッサまたはその他のプログラマブル・データ処理装置を介して実行された命令が、流れ図もしくはブロック図またはその両方の単数または複数のブロックにおいて指定された機能／動作を実現するための手段を作成するようにしてもよい。
【００７０】
これらのコンピュータ・プログラム命令は、コンピュータ、その他のプログラマブル・データ処理装置またはその他のデバイスに特定の態様で機能するよう指示できるコンピュータ読取り可能媒体の中に保存されることによって、コンピュータ読取り可能媒体に保存された命令が、流れ図もしくはブロック図またはその両方の単数または複数のブロックにおいて指定された機能／動作を実現する命令を含む製造品を生成するようにしてもよい。さらに、コンピュータ・プログラム命令は、コンピュータ、その他のプログラマブル・データ処理装置またはその他のデバイスにロードされて、そのコンピュータ、その他のプログラマブル装置またはその他のデバイスにおいて一連の動作ステップを行わせることにより、コンピュータまたはその他のプログラマブル装置において実行される命令が、流れ図もしくはブロック図またはその両方の単数または複数のブロックにおいて指定された機能／動作を実現するためのプロセスを提供するような、コンピュータに実現されるプロセスを生成してもよい。
【００７１】
上記図面中の流れ図およびブロック図は、本発明のさまざまな実施形態に従うシステム、方法およびコンピュータ・プログラム製品の実現可能なアーキテクチャ、機能および動作を例示するものである。これに関して、流れ図またはブロック図における各ブロックは、特定の論理関数（単数または複数）を実現するための１つまたはそれ以上の実行可能な命令を含むモジュール、セグメント、またはコードの部分を表していてもよい。さらに、いくつかの代替的な実現においては、ブロック中に示される機能が図面に示される以外の順序で起こってもよいことに留意すべきである。たとえば、連続して示される２つのブロックは、伴われる機能に依存して、実際には実質的に同時に実行されてもよいし、それらのブロックがときには逆の順序で実行されてもよい。さらに、ブロック図もしくは流れ図またはその両方の各ブロック、およびブロック図もしくは流れ図またはその両方のブロックの組み合わせは、指定された機能もしくは動作を行う特定目的のハードウェアに基づくシステム、または特定目的のハードウェアとコンピュータ命令との組み合わせによって実現され得ることを注記する。
【００７２】
本発明の１つまたはそれ以上の実施形態を詳細に例示したが、以下の請求項に示されるとおりの本発明の範囲から逸脱することなく、それらの実施形態に対する修正および適応が行われてもよいことを当業者は認識するだろう。
【図１】
0005972363.tif 000002
【図２】
0005972363.tif 000003
【図３】
0005972363.tif 000004
【図４】
0005972363.tif 000005
【図５】
0005972363.tif 000006
【図６】
0005972363.tif 000007
【図７】
0005972363.tif 000008
【図８】
0005972363.tif 000009