JP2001142858A - コンピュータ環境の中央処理装置を管理する方法、システム、およびプログラム製品 - Google Patents
コンピュータ環境の中央処理装置を管理する方法、システム、およびプログラム製品Info
- Publication number
- JP2001142858A JP2001142858A JP2000290086A JP2000290086A JP2001142858A JP 2001142858 A JP2001142858 A JP 2001142858A JP 2000290086 A JP2000290086 A JP 2000290086A JP 2000290086 A JP2000290086 A JP 2000290086A JP 2001142858 A JP2001142858 A JP 2001142858A
- Authority
- JP
- Japan
- Prior art keywords
- partition
- resources
- cpu
- weight
- partitions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
Abstract
(57)【要約】
【課題】 コンピュータ環境内の中央処理装置（ＣＰ
Ｕ）リソースを管理すること。 【解決手段】 コンピュータ環境の区画へのＣＰＵリソ
ースの割振りを調整しなければならない時に、割振り
が、動的に調整される。この動的調整は、コンピュータ
環境の少なくとも２つの区画にまたがる。この調整に
は、区画に関連するプロセッサ重みの変更が含まれる。
Ｕ）リソースを管理すること。 【解決手段】 コンピュータ環境の区画へのＣＰＵリソ
ースの割振りを調整しなければならない時に、割振り
が、動的に調整される。この動的調整は、コンピュータ
環境の少なくとも２つの区画にまたがる。この調整に
は、区画に関連するプロセッサ重みの変更が含まれる。
Description
【０００１】
【発明の属する技術分野】本発明は、全般的にはコンピ
ュータ・システム内のワークロードの管理に関し、具体
的には、論理分割されたシステムなどの分割されたシス
テムでのワークロードの管理に関する。
ュータ・システム内のワークロードの管理に関し、具体
的には、論理分割されたシステムなどの分割されたシス
テムでのワークロードの管理に関する。
【０００２】
【従来の技術】論理分割を用いると、単一の物理計算機
または中央演算処理装置複合システム（ＣＰＣ）内で複
数のシステム・イメージを確立することができる。各シ
ステム・イメージは、別々のコンピュータ・システムで
あるかのように動作することができる。すなわち、各論
理区画は、独立にリセットでき、論理区画ごとに異なる
ものとすることのできるオペレーティング・システムを
当初にロードでき、異なる入出力装置を使用して異なる
ソフトウェア・プログラムと共に動作することができ
る。
または中央演算処理装置複合システム（ＣＰＣ）内で複
数のシステム・イメージを確立することができる。各シ
ステム・イメージは、別々のコンピュータ・システムで
あるかのように動作することができる。すなわち、各論
理区画は、独立にリセットでき、論理区画ごとに異なる
ものとすることのできるオペレーティング・システムを
当初にロードでき、異なる入出力装置を使用して異なる
ソフトウェア・プログラムと共に動作することができ
る。
【０００３】論理分割されたコンピュータ・システムの
例は、たとえば、米国特許第４５６４９０３号明細書、
米国特許第４８４３５４１号明細書、および米国特許第
５５６４０４０号明細書に記載されている。
例は、たとえば、米国特許第４５６４９０３号明細書、
米国特許第４８４３５４１号明細書、および米国特許第
５５６４０４０号明細書に記載されている。
【０００４】論理分割されたシステムの商業実施形態に
は、たとえば、プロセッサ・リソース／システム管理機
構（ＰＲ／ＳＭ）を備えたＩＢＭ Ｓ／３９０プロセッ
サが含まれ、ＰＲ／ＳＭは、たとえば、ＩＢＭ社の出版
物「Processor Resource/Systems Manager Planning Gu
ide」、ＧＡ２２−７２３６−０４、１９９９年３月に
記載されている。
は、たとえば、プロセッサ・リソース／システム管理機
構（ＰＲ／ＳＭ）を備えたＩＢＭ Ｓ／３９０プロセッ
サが含まれ、ＰＲ／ＳＭは、たとえば、ＩＢＭ社の出版
物「Processor Resource/Systems Manager Planning Gu
ide」、ＧＡ２２−７２３６−０４、１９９９年３月に
記載されている。
【０００５】
【発明が解決しようとする課題】論理分割されたシステ
ムの重要な態様の１つが、そのシステムの区画内で稼動
するワークロードの管理である。たとえば、Ｓ／３９０
システムでは、ワークロード・マネージャを使用して、
区画内および区画間でワークロードを管理する。ワーク
ロード・マネージャは、作業をシステムの物理リソース
に移動することによって、ワークロードの平衡化を試み
る。しかし、作業を移動するためには、リロケートされ
る作業が必要とするデータが、移動先の位置にあること
を保証することが重要である。この必要が、作業の移動
を制限することがしばしばである。したがって、論理分
割されたシステム内でワークロードを平衡化するための
努力が行われてきたが、さらなる必要が存在し、さらな
る努力が必要である。
ムの重要な態様の１つが、そのシステムの区画内で稼動
するワークロードの管理である。たとえば、Ｓ／３９０
システムでは、ワークロード・マネージャを使用して、
区画内および区画間でワークロードを管理する。ワーク
ロード・マネージャは、作業をシステムの物理リソース
に移動することによって、ワークロードの平衡化を試み
る。しかし、作業を移動するためには、リロケートされ
る作業が必要とするデータが、移動先の位置にあること
を保証することが重要である。この必要が、作業の移動
を制限することがしばしばである。したがって、論理分
割されたシステム内でワークロードを平衡化するための
努力が行われてきたが、さらなる必要が存在し、さらな
る努力が必要である。
【０００６】
【課題を解決するための手段】コンピュータ環境内の中
央処理装置（ＣＰＵ）リソースを管理する方法を提供す
ることにより、従来技術の短所が克服され、追加の長所
がもたらされる。この方法には、たとえば、コンピュー
タ環境の区画へのＣＰＵリソースの割振りを調整しなけ
ればならないことを判定するステップと、その区画とコ
ンピュータ環境の別の区画との間で割振りを動的に調整
するステップが含まれる。
央処理装置（ＣＰＵ）リソースを管理する方法を提供す
ることにより、従来技術の短所が克服され、追加の長所
がもたらされる。この方法には、たとえば、コンピュー
タ環境の区画へのＣＰＵリソースの割振りを調整しなけ
ればならないことを判定するステップと、その区画とコ
ンピュータ環境の別の区画との間で割振りを動的に調整
するステップが含まれる。
【０００７】本発明のもう１つの実施形態では、動的調
整が、少なくともその区画のワークロード目標に応答す
る。さらに、もう１つの例では、動的調整は、コンピュ
ータ環境の複数の区画にまたがる。
整が、少なくともその区画のワークロード目標に応答す
る。さらに、もう１つの例では、動的調整は、コンピュ
ータ環境の複数の区画にまたがる。
【０００８】上で要約した方法に対応するシステムおよ
びコンピュータ・プログラム製品も、本明細書に記載さ
れ、請求される。
びコンピュータ・プログラム製品も、本明細書に記載さ
れ、請求される。
【０００９】有利なことに、本発明の少なくとも１つの
態様によって、コンピュータ環境内の中央処理装置リソ
ースの管理が可能になる。たとえば、ワークロード・マ
ネージャは、論理区画に関連するＣＰＵプロセッサ重み
を動的に調整することによって、論理区画にまたがって
ＣＰＵリソースを分配することができる。ＷＬＭは、た
とえば、それが稼動する区画の重みが低すぎるので重要
なワークロードが遅れている時を理解する。ＷＬＭは、
たとえば、この区画の重みを引き上げ、別の区画の重み
を引き下げ、これによって、追加のＣＰＵ容量を重要な
ワークロードに提供することによって、このワークロー
ドを助けることができる。本発明のこの態様によって、
有利なことに、ワークロード要件が変化する際に、必要
な区画に動的にＣＰＵリソースを移動することが可能に
なる。
態様によって、コンピュータ環境内の中央処理装置リソ
ースの管理が可能になる。たとえば、ワークロード・マ
ネージャは、論理区画に関連するＣＰＵプロセッサ重み
を動的に調整することによって、論理区画にまたがって
ＣＰＵリソースを分配することができる。ＷＬＭは、た
とえば、それが稼動する区画の重みが低すぎるので重要
なワークロードが遅れている時を理解する。ＷＬＭは、
たとえば、この区画の重みを引き上げ、別の区画の重み
を引き下げ、これによって、追加のＣＰＵ容量を重要な
ワークロードに提供することによって、このワークロー
ドを助けることができる。本発明のこの態様によって、
有利なことに、ワークロード要件が変化する際に、必要
な区画に動的にＣＰＵリソースを移動することが可能に
なる。
【００１０】追加の特徴および長所は、本発明の技法を
介して実現される。本発明の他の実施形態および態様
は、本明細書に記載されており、請求される発明の一部
とみなされる。
介して実現される。本発明の他の実施形態および態様
は、本明細書に記載されており、請求される発明の一部
とみなされる。
【００１１】
【発明の実施の形態】コンピュータ環境のリソースの割
振りの動的調整によって、その環境のワークロードを平
衡化できるようにする、ワークロード管理機能を提供す
る。一例では、コンピュータ環境に、複数の論理区画が
含まれ、ワークロードは、複数の区画にまたがって管理
される。
振りの動的調整によって、その環境のワークロードを平
衡化できるようにする、ワークロード管理機能を提供す
る。一例では、コンピュータ環境に、複数の論理区画が
含まれ、ワークロードは、複数の区画にまたがって管理
される。
【００１２】本発明のワークロード管理機能を組み込ま
れ、これを使用するコンピュータ環境の一実施形態を、
図１に関連して説明する。コンピュータ環境１００は、
たとえば、米国ニューヨーク州アーモンクのInternatio
nal Business Machines Corporationが提供するエンタ
ープライズ・システム・アーキテクチャー（ＥＳＡ）／
３９０に基づく。ＥＳＡ／３９０は、ＩＢＭ社の出版
物、「Enterprise Systems Architecture/390 Principl
es Of Operation」、ＩＢＭ Publication Ｎｏ．ＳＡ２
２−７２０１−０４、１９９７年６月に記載されてい
る。ＥＳＡ／３９０に基づくコンピュータ環境の一例
が、International Business Machines Corporationが
提供する9672 Parallel Enterprise Serverである。
れ、これを使用するコンピュータ環境の一実施形態を、
図１に関連して説明する。コンピュータ環境１００は、
たとえば、米国ニューヨーク州アーモンクのInternatio
nal Business Machines Corporationが提供するエンタ
ープライズ・システム・アーキテクチャー（ＥＳＡ）／
３９０に基づく。ＥＳＡ／３９０は、ＩＢＭ社の出版
物、「Enterprise Systems Architecture/390 Principl
es Of Operation」、ＩＢＭ Publication Ｎｏ．ＳＡ２
２−７２０１−０４、１９９７年６月に記載されてい
る。ＥＳＡ／３９０に基づくコンピュータ環境の一例
が、International Business Machines Corporationが
提供する9672 Parallel Enterprise Serverである。
【００１３】コンピュータ環境１００には、たとえば、
１つまたは複数の中央処理装置１０６（たとえばＣＰ１
ないしＣＰ４）、１つまたは複数の論理区画１０８（た
とえば論理区画（ＬＰ１ないしＬＰ４））、および少な
くとも１つの論理区画マネージャ１１０を有する中央演
算処理装置複合システム（ＣＰＣ）１０２が含まれる。
これらのそれぞれを、下で説明する。
１つまたは複数の中央処理装置１０６（たとえばＣＰ１
ないしＣＰ４）、１つまたは複数の論理区画１０８（た
とえば論理区画（ＬＰ１ないしＬＰ４））、および少な
くとも１つの論理区画マネージャ１１０を有する中央演
算処理装置複合システム（ＣＰＣ）１０２が含まれる。
これらのそれぞれを、下で説明する。
【００１４】中央処理装置１０６は、論理区画に割り振
られる物理プロセッサ・リソースである。具体的に言う
と、各論理区画１０８は、１つまたは複数の論理プロセ
ッサ（図を明瞭にするために特に図示せず）を有し、こ
の論理プロセッサのそれぞれが、その区画に割り振られ
た物理プロセッサである中央処理装置１０６のすべてま
たは共用部分を表す。特定の論理区画１０８の論理プロ
セッサは、その区画専用（その結果、基礎になる中央処
理装置１０６がその区画のために予約される）とする
か、別の区画と共用する（その結果、基礎になるプロセ
ッサ・リソースが、潜在的に別の区画から使用可能にな
る）のいずれかとすることができる。
られる物理プロセッサ・リソースである。具体的に言う
と、各論理区画１０８は、１つまたは複数の論理プロセ
ッサ（図を明瞭にするために特に図示せず）を有し、こ
の論理プロセッサのそれぞれが、その区画に割り振られ
た物理プロセッサである中央処理装置１０６のすべてま
たは共用部分を表す。特定の論理区画１０８の論理プロ
セッサは、その区画専用（その結果、基礎になる中央処
理装置１０６がその区画のために予約される）とする
か、別の区画と共用する（その結果、基礎になるプロセ
ッサ・リソースが、潜在的に別の区画から使用可能にな
る）のいずれかとすることができる。
【００１５】図示の特定の例では、論理区画ＬＰ１ない
しＬＰ４のそれぞれが、常駐するオペレーティング・シ
ステム１１２（論理区画ごとに異なるものとすることが
できる）と１つまたは複数のアプリケーション１１４を
有する別々のシステムとして機能する。一実施形態で
は、オペレーティング・システム１１２は、Internatio
nal Business Machines Corporationが提供するＯＳ／
３９０またはＭＶＳ／ＥＳＡオペレーティング・システ
ムである。
しＬＰ４のそれぞれが、常駐するオペレーティング・シ
ステム１１２（論理区画ごとに異なるものとすることが
できる）と１つまたは複数のアプリケーション１１４を
有する別々のシステムとして機能する。一実施形態で
は、オペレーティング・システム１１２は、Internatio
nal Business Machines Corporationが提供するＯＳ／
３９０またはＭＶＳ／ＥＳＡオペレーティング・システ
ムである。
【００１６】さらに、各オペレーティング・システム
（またはそのサブセット）には、区画内および区画間で
ワークロードを管理するためのワークロード・マネージ
ャ１１６が含まれる。ワークロード・マネージャの一例
が、International Business Machines Corporationが
提供するＷＬＭである。ＷＬＭは、たとえば、米国特許
第５４７３７７３号明細書および米国特許第５６７５７
３９号明細書に記載されている。
（またはそのサブセット）には、区画内および区画間で
ワークロードを管理するためのワークロード・マネージ
ャ１１６が含まれる。ワークロード・マネージャの一例
が、International Business Machines Corporationが
提供するＷＬＭである。ＷＬＭは、たとえば、米国特許
第５４７３７７３号明細書および米国特許第５６７５７
３９号明細書に記載されている。
【００１７】論理区画１０８は、中央処理装置１０６上
で稼動するマイクロコードによって実施される論理区画
マネージャ１１０によって管理される。論理区画１０８
（ＬＰ１ないしＬＰ４）および論理区画マネージャ１１
０のそれぞれには、中央処理装置に関連する中央記憶装
置のそれぞれの部分に常駐する１つまたは複数のプログ
ラムが含まれる。論理区画マネージャ１１０の一例が、
ＰＲ／ＳＭである。
で稼動するマイクロコードによって実施される論理区画
マネージャ１１０によって管理される。論理区画１０８
（ＬＰ１ないしＬＰ４）および論理区画マネージャ１１
０のそれぞれには、中央処理装置に関連する中央記憶装
置のそれぞれの部分に常駐する１つまたは複数のプログ
ラムが含まれる。論理区画マネージャ１１０の一例が、
ＰＲ／ＳＭである。
【００１８】コンピュータ環境のもう１つの実施形態で
は、複数の中央演算処理装置複合システムが、図２に示
されているように互いに結合されて、シスプレックスを
形成する。一例として、中央演算処理装置複合システム
（ＣＰＣ）１０２は、たとえば結合装置１２２を介し
て、１つまたは複数の他のＣＰＣ１２０に結合される。
は、複数の中央演算処理装置複合システムが、図２に示
されているように互いに結合されて、シスプレックスを
形成する。一例として、中央演算処理装置複合システム
（ＣＰＣ）１０２は、たとえば結合装置１２２を介し
て、１つまたは複数の他のＣＰＣ１２０に結合される。
【００１９】図示の例では、ＣＰＣ１２０に、複数の論
理区画１２４（たとえばＬＰ１ないしＬＰ３）が含ま
れ、これらの論理区画は、論理区画マネージャ１２６に
よって管理される。１つまたは複数の論理区画に、オペ
レーティング・システムが含まれ、この論理区画は、ワ
ークロード・マネージャおよび１つまたは複数のアプリ
ケーション・プログラムを有することができる（図を明
瞭にするためにこの例では図示せず）。さらに、ＣＰＣ
１２０には、複数の中央処理装置１２８（たとえばＣＰ
１ないしＣＰ３）が含まれ、その中央処理装置のリソー
スは、複数の論理区画の間で割り振られる。具体的に言
うと、リソースは、各区画の１つまたは複数の論理プロ
セッサ１３０の間で割り振られる（他の実施形態では、
各ＣＰＣが、１つまたは複数の論理区画と、１つまたは
複数の中央処理装置を有することができる）。
理区画１２４（たとえばＬＰ１ないしＬＰ３）が含ま
れ、これらの論理区画は、論理区画マネージャ１２６に
よって管理される。１つまたは複数の論理区画に、オペ
レーティング・システムが含まれ、この論理区画は、ワ
ークロード・マネージャおよび１つまたは複数のアプリ
ケーション・プログラムを有することができる（図を明
瞭にするためにこの例では図示せず）。さらに、ＣＰＣ
１２０には、複数の中央処理装置１２８（たとえばＣＰ
１ないしＣＰ３）が含まれ、その中央処理装置のリソー
スは、複数の論理区画の間で割り振られる。具体的に言
うと、リソースは、各区画の１つまたは複数の論理プロ
セッサ１３０の間で割り振られる（他の実施形態では、
各ＣＰＣが、１つまたは複数の論理区画と、１つまたは
複数の中央処理装置を有することができる）。
【００２０】結合装置１２２（別名、構造化外部ストレ
ージ（ＳＥＳ）プロセッサ）は、中央演算処理装置複合
システムによってアクセス可能な記憶装置を含み、ＣＰ
Ｃ内のプログラムによって要求される動作を実行する。
結合装置は、共用リソース再分配決定を行う際に使用さ
れる状態情報の共用のために本発明のさまざまな態様に
よって使用される（一実施形態では、各中央演算処理装
置複合システムが、複数の結合装置に結合される）。結
合装置の動作の諸態様は、米国特許第５３１７７３９号
明細書、米国特許第５５６１８０９号明細書、および米
国特許第５７０６４３２号明細書などの参考文献に詳細
に記載されている。
ージ（ＳＥＳ）プロセッサ）は、中央演算処理装置複合
システムによってアクセス可能な記憶装置を含み、ＣＰ
Ｃ内のプログラムによって要求される動作を実行する。
結合装置は、共用リソース再分配決定を行う際に使用さ
れる状態情報の共用のために本発明のさまざまな態様に
よって使用される（一実施形態では、各中央演算処理装
置複合システムが、複数の結合装置に結合される）。結
合装置の動作の諸態様は、米国特許第５３１７７３９号
明細書、米国特許第５５６１８０９号明細書、および米
国特許第５７０６４３２号明細書などの参考文献に詳細
に記載されている。
【００２１】一実施形態では、１つまたは複数の中央処
理装置が、少なくとも１つのチャネル・サブシステムに
結合され、このチャネル・サブシステムは、入出力装置
との通信に使用される。たとえば、中央処理装置２００
（図３）は、主記憶装置２０２および少なくとも１つの
チャネル・サブシステム２０４に結合される。チャネル
・サブシステム２０４は、さらに、１つまたは複数の制
御装置２０６に結合される。制御装置は、１つまたは複
数の入出力装置２０８に結合される。
理装置が、少なくとも１つのチャネル・サブシステムに
結合され、このチャネル・サブシステムは、入出力装置
との通信に使用される。たとえば、中央処理装置２００
（図３）は、主記憶装置２０２および少なくとも１つの
チャネル・サブシステム２０４に結合される。チャネル
・サブシステム２０４は、さらに、１つまたは複数の制
御装置２０６に結合される。制御装置は、１つまたは複
数の入出力装置２０８に結合される。
【００２２】チャネル・サブシステムは、入出力装置と
主記憶装置の間の情報の流れを指示する。チャネル・サ
ブシステムは、中央処理装置を、入出力装置と直接に通
信するという作業から解放し、入出力処理と並列にデー
タ処理を進行できるようにする。チャネル・サブシステ
ムは、入出力装置２０８との間の情報の流れを管理する
際の通信リンクとして、１つまたは複数のチャネル・パ
ス２１４を使用する。
主記憶装置の間の情報の流れを指示する。チャネル・サ
ブシステムは、中央処理装置を、入出力装置と直接に通
信するという作業から解放し、入出力処理と並列にデー
タ処理を進行できるようにする。チャネル・サブシステ
ムは、入出力装置２０８との間の情報の流れを管理する
際の通信リンクとして、１つまたは複数のチャネル・パ
ス２１４を使用する。
【００２３】各チャネル・パス２１４には、たとえば、
チャネル・サブシステム２０４のチャネル２１０、制御
装置２０６、およびチャネルと制御装置の間のリンク２
１２が含まれる。他の実施形態では、チャネル・パス
が、複数のチャネル、制御装置またはリンクを有するこ
とができる。さらに、もう１つの例では、チャネル・パ
スの一部として、１つまたは複数の動的交換機を有する
ことも可能である。動的交換機は、チャネルおよび制御
装置に結合され、交換機に付加されるリンクの任意の２
つを物理的に相互接続する能力を提供する。チャネル・
サブシステムに関するさらなる詳細は、参照によってそ
の全体を本明細書に組み込まれる米国特許第５５２６４
８４号明細書に記載されている。
チャネル・サブシステム２０４のチャネル２１０、制御
装置２０６、およびチャネルと制御装置の間のリンク２
１２が含まれる。他の実施形態では、チャネル・パス
が、複数のチャネル、制御装置またはリンクを有するこ
とができる。さらに、もう１つの例では、チャネル・パ
スの一部として、１つまたは複数の動的交換機を有する
ことも可能である。動的交換機は、チャネルおよび制御
装置に結合され、交換機に付加されるリンクの任意の２
つを物理的に相互接続する能力を提供する。チャネル・
サブシステムに関するさらなる詳細は、参照によってそ
の全体を本明細書に組み込まれる米国特許第５５２６４
８４号明細書に記載されている。
【００２４】本発明の一態様では、さまざまな物理リソ
ースが、１つまたは複数のワークロード・マネージャの
指示の下で、コンピュータ環境の論理区画の間で動的に
再分配される。この動的再分配は、アプリケーション・
サブシステムにとって透過的である。例として、再分配
される物理リソースには、ＣＰＵリソース、論理プロセ
ッサ・リソース、入出力リソース、コプロセッサ、チャ
ネル・リソース、ネットワーク・アダプタ、およびメモ
リ・リソースが含まれる。一例として、コプロセッサ
は、特定の機能をサービスする、ＣＰＣ内のマイクロプ
ロセッサ（ＣＰＵ以外の）である。コプロセッサの例に
は、たとえば、チャネル・サブシステム、ネットワーク
・アダプタ・カード、および暗号コプロセッサが含まれ
る。上記の物理リソースは、例として提供されるものに
すぎない。他の共用可能リソースも、本発明の主旨から
逸脱せずに再分配することができる。
ースが、１つまたは複数のワークロード・マネージャの
指示の下で、コンピュータ環境の論理区画の間で動的に
再分配される。この動的再分配は、アプリケーション・
サブシステムにとって透過的である。例として、再分配
される物理リソースには、ＣＰＵリソース、論理プロセ
ッサ・リソース、入出力リソース、コプロセッサ、チャ
ネル・リソース、ネットワーク・アダプタ、およびメモ
リ・リソースが含まれる。一例として、コプロセッサ
は、特定の機能をサービスする、ＣＰＣ内のマイクロプ
ロセッサ（ＣＰＵ以外の）である。コプロセッサの例に
は、たとえば、チャネル・サブシステム、ネットワーク
・アダプタ・カード、および暗号コプロセッサが含まれ
る。上記の物理リソースは、例として提供されるものに
すぎない。他の共用可能リソースも、本発明の主旨から
逸脱せずに再分配することができる。
【００２５】リソースの動的再分配を容易にするため
に、一実施形態では、論理区画が、グループの区画の間
でリソースを共用するためにグループ化される。各グル
ープのサイズは、１区画からｎ区画まで変更できる（一
実施形態では、１つまたは複数のグループに１つまたは
複数の区画が含まれるが、区画の数はコンピュータ環境
のすべての区画より少ない）。具体的に言うと、各グル
ープには、たとえば、計算機の独立のドメインで稼動す
る１つまたは複数のオペレーティング・システム・イメ
ージが含まれ、このドメインは、ワークロードおよびリ
ソースを分配するために共通のワークロード・マネージ
ャ機能によって管理される。一例では、これらのドメイ
ンは、論理分割モードで稼動する論理区画であり、オペ
レーティング・システムは、論理区画内で稼動するＯＳ
／３９０である。グループの論理区画は、システム（た
とえばＣＰＣ）またはシスプレックスの区画のサブセッ
ト、システムまたはシスプレックス全体、または、異な
るシスプレックス（たとえば単一のＣＰＣ上の）または
異なるシステムの区画とすることができる。
に、一実施形態では、論理区画が、グループの区画の間
でリソースを共用するためにグループ化される。各グル
ープのサイズは、１区画からｎ区画まで変更できる（一
実施形態では、１つまたは複数のグループに１つまたは
複数の区画が含まれるが、区画の数はコンピュータ環境
のすべての区画より少ない）。具体的に言うと、各グル
ープには、たとえば、計算機の独立のドメインで稼動す
る１つまたは複数のオペレーティング・システム・イメ
ージが含まれ、このドメインは、ワークロードおよびリ
ソースを分配するために共通のワークロード・マネージ
ャ機能によって管理される。一例では、これらのドメイ
ンは、論理分割モードで稼動する論理区画であり、オペ
レーティング・システムは、論理区画内で稼動するＯＳ
／３９０である。グループの論理区画は、システム（た
とえばＣＰＣ）またはシスプレックスの区画のサブセッ
ト、システムまたはシスプレックス全体、または、異な
るシスプレックス（たとえば単一のＣＰＣ上の）または
異なるシステムの区画とすることができる。
【００２６】中央演算処理装置複合システムの２つの論
理区画グループ（またはクラスタ）の一実施形態を、図
４に示す。図からわかるように、それぞれに１つまたは
複数の論理区画が含まれる、論理区画グループＡ３００
および論理区画グループＢ３０２がある。論理区画のグ
ループ化によって、リソース割振り（たとえば、優先順
位に基づくリソース割振り）を介するグループの区画の
間でのリソース共用が可能になる。
理区画グループ（またはクラスタ）の一実施形態を、図
４に示す。図からわかるように、それぞれに１つまたは
複数の論理区画が含まれる、論理区画グループＡ３００
および論理区画グループＢ３０２がある。論理区画のグ
ループ化によって、リソース割振り（たとえば、優先順
位に基づくリソース割振り）を介するグループの区画の
間でのリソース共用が可能になる。
【００２７】例として、共用されるリソースには、ＣＰ
Ｕリソース、入出力リソース、およびメモリならびに、
コプロセッサまたは他の、計算機が提供することのでき
る共用可能リソースが含まれる。特定の論理区画グルー
プは、特定の計算機のすべてのリソースへのアクセス権
を有する場合とそうでない場合がある。実際に、複数の
論理区画グループを、単一の計算機上で同時に動作する
ように定義することができる。各論理区画グループを効
率的に管理するために、特定の論理区画グループを構成
するリソースは、効果的にそのグループにスコーピング
される。
Ｕリソース、入出力リソース、およびメモリならびに、
コプロセッサまたは他の、計算機が提供することのでき
る共用可能リソースが含まれる。特定の論理区画グルー
プは、特定の計算機のすべてのリソースへのアクセス権
を有する場合とそうでない場合がある。実際に、複数の
論理区画グループを、単一の計算機上で同時に動作する
ように定義することができる。各論理区画グループを効
率的に管理するために、特定の論理区画グループを構成
するリソースは、効果的にそのグループにスコーピング
される。
【００２８】スコーピングには、各グループに割振り可
能であるリソースの識別が含まれる。具体的に言うと、
有効範囲によって、どのリソースがそのグループに制限
され、そのグループのために管理可能であるかが定義さ
れる。論理区画グループを構成する論理区画は、リソー
スのコンテナとみなすことができる。これらのコンテナ
は、論理区画から使用可能なリソース全体の組の境界の
中に存在する。一例では、これは、特定のＣＰＣ上で使
用可能なリソース全体の組である。
能であるリソースの識別が含まれる。具体的に言うと、
有効範囲によって、どのリソースがそのグループに制限
され、そのグループのために管理可能であるかが定義さ
れる。論理区画グループを構成する論理区画は、リソー
スのコンテナとみなすことができる。これらのコンテナ
は、論理区画から使用可能なリソース全体の組の境界の
中に存在する。一例では、これは、特定のＣＰＣ上で使
用可能なリソース全体の組である。
【００２９】特定の論理区画グループ（たとえば論理区
画グループＡ）を構成する論理区画には、共用可能なす
べてのリソースのうちの特定の部分が割り当てられる。
たとえば、共用可能なリソースがＣＰＵリソースである
と仮定する。共用ＣＰＵリソースについて、論理区画グ
ループＡに含まれる論理区画には、中央演算処理装置複
合システムＣＰＵリソース全体のうちの特定の部分が割
り当てられる。これらのリソースは、特定のグループ内
の論理区画ならびに、潜在的に、他の論理区画グループ
内の論理区画およびどの論理区画グループにも含まれな
い論理区画によって共用されている。したがって、グル
ープ内でのリソース移動（たとえば、論理区画グループ
内の１区画からそのグループ内の別の区画へ）に関する
決定を行おうとするワークロード・マネージャは、グル
ープを構成するリソースの理解ならびに、より大きいコ
ンテナ（たとえばＣＰＣ）に含まれるものの理解を有す
る必要がある。ワークロード・リソース管理に関する決
定を行うのに使用される測定フィードバック（たとえ
ば、結合装置に記憶された状態情報）は、上記のように
顧客が定義したコンテナを理解するのに十分なものでな
ければならない。
画グループＡ）を構成する論理区画には、共用可能なす
べてのリソースのうちの特定の部分が割り当てられる。
たとえば、共用可能なリソースがＣＰＵリソースである
と仮定する。共用ＣＰＵリソースについて、論理区画グ
ループＡに含まれる論理区画には、中央演算処理装置複
合システムＣＰＵリソース全体のうちの特定の部分が割
り当てられる。これらのリソースは、特定のグループ内
の論理区画ならびに、潜在的に、他の論理区画グループ
内の論理区画およびどの論理区画グループにも含まれな
い論理区画によって共用されている。したがって、グル
ープ内でのリソース移動（たとえば、論理区画グループ
内の１区画からそのグループ内の別の区画へ）に関する
決定を行おうとするワークロード・マネージャは、グル
ープを構成するリソースの理解ならびに、より大きいコ
ンテナ（たとえばＣＰＣ）に含まれるものの理解を有す
る必要がある。ワークロード・リソース管理に関する決
定を行うのに使用される測定フィードバック（たとえ
ば、結合装置に記憶された状態情報）は、上記のように
顧客が定義したコンテナを理解するのに十分なものでな
ければならない。
【００３０】この理解が確立された後に、ワークロード
・マネージャが指示する、所与のグループの論理区画で
のリソース割振りに対する変更は、通常は、コンテナ・
サイズ（すなわち、論理区画グループに割り振られるリ
ソース）を一定に保つ形で行われる。たとえば、管理さ
れるリソースがＣＰＵリソースであると仮定し、さら
に、各論理区画に、優先順位を示すＣＰＵ処理重みが割
り当てられると仮定する。ＣＰＵ相対重みを管理するた
めに、所与のグループ内の論理区画の相対重みの合計
が、たとえばワークロード・マネージャを介する、指示
された変更の前と後で一定にならなければならない。こ
れによって、顧客が指定した、グループおよび計算機上
に存在する他の論理区画へのリソースの割振りが維持さ
れる。
・マネージャが指示する、所与のグループの論理区画で
のリソース割振りに対する変更は、通常は、コンテナ・
サイズ（すなわち、論理区画グループに割り振られるリ
ソース）を一定に保つ形で行われる。たとえば、管理さ
れるリソースがＣＰＵリソースであると仮定し、さら
に、各論理区画に、優先順位を示すＣＰＵ処理重みが割
り当てられると仮定する。ＣＰＵ相対重みを管理するた
めに、所与のグループ内の論理区画の相対重みの合計
が、たとえばワークロード・マネージャを介する、指示
された変更の前と後で一定にならなければならない。こ
れによって、顧客が指定した、グループおよび計算機上
に存在する他の論理区画へのリソースの割振りが維持さ
れる。
【００３１】上記にもかかわらず、いくつかの場合に、
リソースが指定された所有者によって使用されていない
時に、区画のグループが、定義されたコンテナより多い
リソースを使用することが望ましく、可能である場合が
ある。しかし、リソースの競合が発生すると同時に、リ
ソースは、定義されたコンテナのサイズ（たとえば、こ
の例では処理重み）に従って、ＬＰＡＲマネージャによ
って管理される。しかし、そのコンテナを超えてグルー
プを拡張することを許可してはならない場合もありえ
る。これは、スコーピングに関してもありえる。他のリ
ソースは、リソースの使用の正確なイメージを得るため
に、単一のグループに完全にスコーピングされる必要が
ある可能性がある。この形での制限によって、所与のグ
ループの外部の論理区画がそのリソースにアクセスでき
なくなる。
リソースが指定された所有者によって使用されていない
時に、区画のグループが、定義されたコンテナより多い
リソースを使用することが望ましく、可能である場合が
ある。しかし、リソースの競合が発生すると同時に、リ
ソースは、定義されたコンテナのサイズ（たとえば、こ
の例では処理重み）に従って、ＬＰＡＲマネージャによ
って管理される。しかし、そのコンテナを超えてグルー
プを拡張することを許可してはならない場合もありえ
る。これは、スコーピングに関してもありえる。他のリ
ソースは、リソースの使用の正確なイメージを得るため
に、単一のグループに完全にスコーピングされる必要が
ある可能性がある。この形での制限によって、所与のグ
ループの外部の論理区画がそのリソースにアクセスでき
なくなる。
【００３２】上記に加えて、論理区画グループ内のリソ
ースの可用性に対する外部変更の影響にも考慮を払う。
たとえば、ユーザが、なんらかの外部手段を介して（ワ
ークロード・マネージャの指示の下ではなく）リソース
の割振りを変更する可能性がある。これは、ある計算機
での実際のワークロードの変化、またはグループ間また
は他の論理区画間のビジネス優先順位のシフトが原因で
行われる可能性がある。これらの変更が行われる時に
は、これらの変更は、ワークロード・マネージャによっ
て理解されなければならず、これらの変更の影響は、合
理的に分配されなければならない。変更は、論理区画が
グループに追加または除去される時、グループの外部の
他の論理区画が追加または除去される時、または、単に
外部手段を介して処理重みの変更が行われる時に、発生
する可能性がある。これらの外部変更が実行される時に
は、コンテナのサイズが変更される可能性があり、ワー
クロード・マネージャは、その新しいサイズのコンテナ
のマネージャになる。
ースの可用性に対する外部変更の影響にも考慮を払う。
たとえば、ユーザが、なんらかの外部手段を介して（ワ
ークロード・マネージャの指示の下ではなく）リソース
の割振りを変更する可能性がある。これは、ある計算機
での実際のワークロードの変化、またはグループ間また
は他の論理区画間のビジネス優先順位のシフトが原因で
行われる可能性がある。これらの変更が行われる時に
は、これらの変更は、ワークロード・マネージャによっ
て理解されなければならず、これらの変更の影響は、合
理的に分配されなければならない。変更は、論理区画が
グループに追加または除去される時、グループの外部の
他の論理区画が追加または除去される時、または、単に
外部手段を介して処理重みの変更が行われる時に、発生
する可能性がある。これらの外部変更が実行される時に
は、コンテナのサイズが変更される可能性があり、ワー
クロード・マネージャは、その新しいサイズのコンテナ
のマネージャになる。
【００３３】グループの特定の論理区画に属するリソー
スが外部から変更される時には、グループ内のリソース
の再分配が必要になる可能性がある。たとえば、論理区
画がグループから除去される時には、その論理区画に関
連する処理重みが、そのグループから除去される。その
論理区画について現在ワークロード・マネージャが割り
当てている重みが、除去される論理区画の重み（すなわ
ち、当初に論理区画に関連する処理重み）より大きい場
合には、これらの重みの間の差が、そのグループ内の他
の論理区画に追加される。これは、たとえば、グループ
内の他の論理区画での重みの既存の分配に比例して行わ
れる。論理区画について現在ワークロード・マネージャ
が割り当てている重みが、論理区画の初期重みより小さ
い場合には、これらの重みの間の差が、グループ内の他
の論理区画から減算される。やはり、これは、一例とし
て、他の論理区画の重みの割り当てに比例して行われ
る。
スが外部から変更される時には、グループ内のリソース
の再分配が必要になる可能性がある。たとえば、論理区
画がグループから除去される時には、その論理区画に関
連する処理重みが、そのグループから除去される。その
論理区画について現在ワークロード・マネージャが割り
当てている重みが、除去される論理区画の重み（すなわ
ち、当初に論理区画に関連する処理重み）より大きい場
合には、これらの重みの間の差が、そのグループ内の他
の論理区画に追加される。これは、たとえば、グループ
内の他の論理区画での重みの既存の分配に比例して行わ
れる。論理区画について現在ワークロード・マネージャ
が割り当てている重みが、論理区画の初期重みより小さ
い場合には、これらの重みの間の差が、グループ内の他
の論理区画から減算される。やはり、これは、一例とし
て、他の論理区画の重みの割り当てに比例して行われ
る。
【００３４】上で説明したように、グループは、グルー
プに割り当てられたリソースおよび変更を許可されたリ
ソースへのハンドルを得るためにスコーピングされ、そ
の結果、ワークロード・マネージャは、次に何を行うか
に関して正しい決定を行えるようになる。スコーピング
によって、グループが識別され、プログラムが理解でき
る情報がプログラムに供給される。グループが変更され
る時には、リソースは、その変更を満足するために動的
に調整される。
プに割り当てられたリソースおよび変更を許可されたリ
ソースへのハンドルを得るためにスコーピングされ、そ
の結果、ワークロード・マネージャは、次に何を行うか
に関して正しい決定を行えるようになる。スコーピング
によって、グループが識別され、プログラムが理解でき
る情報がプログラムに供給される。グループが変更され
る時には、リソースは、その変更を満足するために動的
に調整される。
【００３５】一実施形態では、リソースごとに別々のグ
ループ（クラスタ）を設けることができる。たとえば、
論理区画グループＡをＣＰＵリソースに関するものと
し、論理区画グループＢを入出力リソースに関するもの
とすることができる。しかし、他の実施形態では、１つ
の論理区画グループを、リソースのサブセットまたはす
べてに関するものとすることも可能である。
ループ（クラスタ）を設けることができる。たとえば、
論理区画グループＡをＣＰＵリソースに関するものと
し、論理区画グループＢを入出力リソースに関するもの
とすることができる。しかし、他の実施形態では、１つ
の論理区画グループを、リソースのサブセットまたはす
べてに関するものとすることも可能である。
【００３６】ＬＰＡＲグループ有効範囲を確立するため
に、一例では、論理区画が、１つまたは複数の区画のグ
ループに対してそれ自体を識別する。グループへの加入
に関連する論理の一実施形態を、図５に関連して説明す
る。たとえば、論理区画グループに加入するために、論
理区画で稼動するオペレーティング・システム（たとえ
ばＯＳ／３９０）は、その論理区画がその一部になろう
とするＬＰＡＲグループがどれであるかをＬＰＡＲマネ
ージャに示す（ステップ４００）。一例として、命令を
使用して、ＬＰＡＲグループ名をＬＰＡＲマネージャに
渡す。オペレーティング・システムは、ＬＰＡＲグルー
プ内で管理されるリソースのタイプごとに名前を指定す
る。したがって、他のリソースがある場合には（問合せ
４０２）、他の名前を指定する。たとえば、あるグルー
プ名が、ＣＰＵリソースについて与えられ、もう１つの
名前が、入出力リソースについて与えられる。望むなら
ば、各リソース・タイプについて同一のＬＰＡＲグルー
プ名を指定することができる。
に、一例では、論理区画が、１つまたは複数の区画のグ
ループに対してそれ自体を識別する。グループへの加入
に関連する論理の一実施形態を、図５に関連して説明す
る。たとえば、論理区画グループに加入するために、論
理区画で稼動するオペレーティング・システム（たとえ
ばＯＳ／３９０）は、その論理区画がその一部になろう
とするＬＰＡＲグループがどれであるかをＬＰＡＲマネ
ージャに示す（ステップ４００）。一例として、命令を
使用して、ＬＰＡＲグループ名をＬＰＡＲマネージャに
渡す。オペレーティング・システムは、ＬＰＡＲグルー
プ内で管理されるリソースのタイプごとに名前を指定す
る。したがって、他のリソースがある場合には（問合せ
４０２）、他の名前を指定する。たとえば、あるグルー
プ名が、ＣＰＵリソースについて与えられ、もう１つの
名前が、入出力リソースについて与えられる。望むなら
ば、各リソース・タイプについて同一のＬＰＡＲグルー
プ名を指定することができる。
【００３７】このＯＳ／３９０による宣言によって、計
算機上で新しいＬＰＡＲグループが確立される（論理区
画がその名前を使用する最初の論理区画である場合）
か、この論理区画がそのリソース・タイプに関する同一
の名前の既存のＬＰＡＲグループに加入することになる
かのいずれかになる。たとえば、グループ名が指定され
た（ステップ４０４）（図６）後に、それが新しい名前
であるかどうかに関する判定を行なう（問合せ４０
６）。そうである場合には、新しいグループを作成する
（ステップ４０８）。そうでない場合には、既存のグル
ープに加入する（ステップ４１０）。その後、リソース
をグループにスコーピングする（ステップ４１２）。
算機上で新しいＬＰＡＲグループが確立される（論理区
画がその名前を使用する最初の論理区画である場合）
か、この論理区画がそのリソース・タイプに関する同一
の名前の既存のＬＰＡＲグループに加入することになる
かのいずれかになる。たとえば、グループ名が指定され
た（ステップ４０４）（図６）後に、それが新しい名前
であるかどうかに関する判定を行なう（問合せ４０
６）。そうである場合には、新しいグループを作成する
（ステップ４０８）。そうでない場合には、既存のグル
ープに加入する（ステップ４１０）。その後、リソース
をグループにスコーピングする（ステップ４１２）。
【００３８】具体的に言うと、ＬＰＡＲグループにバイ
ンドされるグループ・タイプのリソースは、ＬＰＡＲグ
ループ内で稼動するＷＬＭがそうする必要があると判定
した場合に、その時に、その論理区画が使用するために
使用可能にされる。スコーピングを必要とするＬＰＡＲ
グループの特定のタイプのリソースには、少なくとも２
つの変形すなわち、追加リソースおよび固定リソースが
含まれる。
ンドされるグループ・タイプのリソースは、ＬＰＡＲグ
ループ内で稼動するＷＬＭがそうする必要があると判定
した場合に、その時に、その論理区画が使用するために
使用可能にされる。スコーピングを必要とするＬＰＡＲ
グループの特定のタイプのリソースには、少なくとも２
つの変形すなわち、追加リソースおよび固定リソースが
含まれる。
【００３９】追加リソース：いくつかの場合に、ＬＰＡ
Ｒグループへの加入によって、本質的に、論理区画が加
入したばかりのＬＰＡＲグループにリソースが追加され
る。この一例が、ＣＰＵ処理重みであり、これは、たと
えば、顧客によって、ハードウェア・コンソールで論理
区画に割り当てられる。論理区画の現在の（使用中の）
処理重みは、論理区画が活動化される時に、この顧客が
割り当てた重みから初期設定される。論理区画がＣＰＵ
リソースに関するＬＰＡＲグループに加入する時には、
その論理区画に顧客が割り当てた処理重みが、ＬＰＡＲ
グループ内での使用のために使用可能な総処理重みの一
部になり、したがって、ＷＬＭによってＬＰＡＲグルー
プ内で再割り当てすることが可能になる。ＬＰＡＲグル
ープに加入したばかりの論理区画は、寄与が行われたば
かりのＬＰＡＲグループ・リソースのより大きい組を使
用する潜在能力を有する。
Ｒグループへの加入によって、本質的に、論理区画が加
入したばかりのＬＰＡＲグループにリソースが追加され
る。この一例が、ＣＰＵ処理重みであり、これは、たと
えば、顧客によって、ハードウェア・コンソールで論理
区画に割り当てられる。論理区画の現在の（使用中の）
処理重みは、論理区画が活動化される時に、この顧客が
割り当てた重みから初期設定される。論理区画がＣＰＵ
リソースに関するＬＰＡＲグループに加入する時には、
その論理区画に顧客が割り当てた処理重みが、ＬＰＡＲ
グループ内での使用のために使用可能な総処理重みの一
部になり、したがって、ＷＬＭによってＬＰＡＲグルー
プ内で再割り当てすることが可能になる。ＬＰＡＲグル
ープに加入したばかりの論理区画は、寄与が行われたば
かりのＬＰＡＲグループ・リソースのより大きい組を使
用する潜在能力を有する。
【００４０】固定リソース：いくつかの場合に、リソー
スの組が、特定のＬＰＡＲグループに属するものとして
事前に定義される。この一例が、管理対象（浮動）チャ
ネル・パスである。管理対象チャネル・パスとは、ワー
クロード目標を達成するのを助けるためにそのリソース
を再割り当てすることができるチャネル・パスである。
特定のＬＰＡＲグループによる使用のための管理対象チ
ャネル・パスの組は、当初は、チャネル・パス（ＣＨＰ
ＩＤ）をＬＰＡＲグループに関連付ける入出力構成定義
処理を介して定義される。論理区画は、このＬＰＡＲグ
ループに加入する時に、このチャネル・パスの組へのア
クセスを許可される。論理区画自体は、このリソース・
プールに全く寄与しない（このリソースのプールは、や
はり動的に変更することができるが、要点は、論理区画
がＬＰＡＲグループに加入し、離脱する際にリソースが
論理区画と共に移動しないことである）。
スの組が、特定のＬＰＡＲグループに属するものとして
事前に定義される。この一例が、管理対象（浮動）チャ
ネル・パスである。管理対象チャネル・パスとは、ワー
クロード目標を達成するのを助けるためにそのリソース
を再割り当てすることができるチャネル・パスである。
特定のＬＰＡＲグループによる使用のための管理対象チ
ャネル・パスの組は、当初は、チャネル・パス（ＣＨＰ
ＩＤ）をＬＰＡＲグループに関連付ける入出力構成定義
処理を介して定義される。論理区画は、このＬＰＡＲグ
ループに加入する時に、このチャネル・パスの組へのア
クセスを許可される。論理区画自体は、このリソース・
プールに全く寄与しない（このリソースのプールは、や
はり動的に変更することができるが、要点は、論理区画
がＬＰＡＲグループに加入し、離脱する際にリソースが
論理区画と共に移動しないことである）。
【００４１】ＬＰＡＲスコープも、リソースのタイプに
応じてリソースに対して異なる形で実施することができ
る。
応じてリソースに対して異なる形で実施することができ
る。
【００４２】追加リソース：ＬＰＡＲグループ内のオペ
レーティング・システムは、そのＬＰＡＲグループのこ
のタイプのリソースの完全な組を問い合わせることがで
きる。一例として、ＣＰＵ処理重みの場合、これは、命
令を介して達成される。オペレーティング・システム
は、ＬＰＡＲグループ内のこのリソース・タイプの組全
体、グループ内の論理区画へのリソースの割振り、およ
び現在の計算機上で使用可能なリソース・プールの完全
なサイズを知る。これらの構成要素のすべてが、全物理
リソースのうちのどれだけが論理区画に割り振られるか
を理解するのに使用される。その後、オペレーティング
・システムは、ＬＰＡＲグループ内の論理区画への割振
りを更新して、グループ内のリソースを再割当てする。
オペレーティング・システムは、一例では、ＬＰＡＲグ
ループに割り振られるリソースの総量を変更することを
許可されない。ＬＰＡＲマネージャは、ＬＰＡＲグルー
プのすべての部分が、更新で考慮され、ＬＰＡＲグルー
プの外部の論理区画がそのリソースに影響を受けないよ
うにすることによって、これを実施する。
レーティング・システムは、そのＬＰＡＲグループのこ
のタイプのリソースの完全な組を問い合わせることがで
きる。一例として、ＣＰＵ処理重みの場合、これは、命
令を介して達成される。オペレーティング・システム
は、ＬＰＡＲグループ内のこのリソース・タイプの組全
体、グループ内の論理区画へのリソースの割振り、およ
び現在の計算機上で使用可能なリソース・プールの完全
なサイズを知る。これらの構成要素のすべてが、全物理
リソースのうちのどれだけが論理区画に割り振られるか
を理解するのに使用される。その後、オペレーティング
・システムは、ＬＰＡＲグループ内の論理区画への割振
りを更新して、グループ内のリソースを再割当てする。
オペレーティング・システムは、一例では、ＬＰＡＲグ
ループに割り振られるリソースの総量を変更することを
許可されない。ＬＰＡＲマネージャは、ＬＰＡＲグルー
プのすべての部分が、更新で考慮され、ＬＰＡＲグルー
プの外部の論理区画がそのリソースに影響を受けないよ
うにすることによって、これを実施する。
【００４３】固定リソース：ＬＰＡＲグループ内のオペ
レーティング・システムは、このタイプのリソースにつ
いて、そのＬＰＡＲグループに関連するリソースの組を
問い合わせる。たとえば、管理対象チャネル・パスにつ
いて、特定のＬＰＡＲグループについて定義された管理
対象チャネル・パスのリストを、命令を介してＬＰＡＲ
マネージャから取り出すことができる。ＬＰＡＲマネー
ジャは、これらのリソースのスクリーニングも行って、
これらが正しいＬＰＡＲグループによってのみ使用され
るようにする。管理対象チャネルの場合、これは、管理
対象チャネル・パスを、その管理対象チャネル・パスに
ついて定義された名前と一致するＬＰＡＲグループ名を
宣言した論理区画に対してオンラインに構成することだ
けが許可されることを意味する。
レーティング・システムは、このタイプのリソースにつ
いて、そのＬＰＡＲグループに関連するリソースの組を
問い合わせる。たとえば、管理対象チャネル・パスにつ
いて、特定のＬＰＡＲグループについて定義された管理
対象チャネル・パスのリストを、命令を介してＬＰＡＲ
マネージャから取り出すことができる。ＬＰＡＲマネー
ジャは、これらのリソースのスクリーニングも行って、
これらが正しいＬＰＡＲグループによってのみ使用され
るようにする。管理対象チャネルの場合、これは、管理
対象チャネル・パスを、その管理対象チャネル・パスに
ついて定義された名前と一致するＬＰＡＲグループ名を
宣言した論理区画に対してオンラインに構成することだ
けが許可されることを意味する。
【００４４】ＬＰＡＲグループの一部である論理区画
が、システム・リセット、再ＩＰＬ、または非活動化さ
れる時には、その論理区画が１つまたは複数のＬＰＡＲ
グループに関して有した所属のすべてが除去される。グ
ループからの論理区画の除去に関連する論理の一実施形
態を、図７に関連して説明する。リセットの一部とし
て、論理区画マネージャは、宣言されたＬＰＡＲ区画グ
ループ名を論理区画から除去する（ステップ５００）。
次に、リソースに応じて（問合せ５０２）、その論理区
画のＬＰＡＲグループ・リソース割振り解除を完了する
ための１つまたは複数の他の処置を実行する。
が、システム・リセット、再ＩＰＬ、または非活動化さ
れる時には、その論理区画が１つまたは複数のＬＰＡＲ
グループに関して有した所属のすべてが除去される。グ
ループからの論理区画の除去に関連する論理の一実施形
態を、図７に関連して説明する。リセットの一部とし
て、論理区画マネージャは、宣言されたＬＰＡＲ区画グ
ループ名を論理区画から除去する（ステップ５００）。
次に、リソースに応じて（問合せ５０２）、その論理区
画のＬＰＡＲグループ・リソース割振り解除を完了する
ための１つまたは複数の他の処置を実行する。
【００４５】リソースが追加リソースの場合には、以下
が行われる。このような、論理区画がＬＰＡＲグループ
に加入した時にＬＰＡＲグループに追加されたリソース
は、ＬＰＡＲグループから除去される（ステップ５０
４）。これには、このタイプのリソースの、ＬＰＡＲグ
ループの残りのメンバへの現在の割振りの調整が含まれ
る場合がある。たとえば、処理重みの場合、グループを
離脱する論理区画の初期処理重みが、ＬＰＡＲグループ
の有効範囲から除去される。ＷＬＭが、論理区画の現在
の処理重みを変更している場合には、調整を行う必要が
ある。論理区画の現在の処理重みが、その初期処理重み
より大きい場合には、この２つの間の差が、残りのＬＰ
ＡＲグループ・メンバに、その現在の処理重みに比例し
て再分配される。論理区画の現在の処理重みが、その初
期処理重みより小さい場合には、この２つの間の差が、
残りのＬＰＡＲグループ・メンバから、その現在の処理
重みに比例して除去される。この調整の結果として、結
果のＬＰＡＲグループに対する処理重みコンテナの内容
が再確立される。
が行われる。このような、論理区画がＬＰＡＲグループ
に加入した時にＬＰＡＲグループに追加されたリソース
は、ＬＰＡＲグループから除去される（ステップ５０
４）。これには、このタイプのリソースの、ＬＰＡＲグ
ループの残りのメンバへの現在の割振りの調整が含まれ
る場合がある。たとえば、処理重みの場合、グループを
離脱する論理区画の初期処理重みが、ＬＰＡＲグループ
の有効範囲から除去される。ＷＬＭが、論理区画の現在
の処理重みを変更している場合には、調整を行う必要が
ある。論理区画の現在の処理重みが、その初期処理重み
より大きい場合には、この２つの間の差が、残りのＬＰ
ＡＲグループ・メンバに、その現在の処理重みに比例し
て再分配される。論理区画の現在の処理重みが、その初
期処理重みより小さい場合には、この２つの間の差が、
残りのＬＰＡＲグループ・メンバから、その現在の処理
重みに比例して除去される。この調整の結果として、結
果のＬＰＡＲグループに対する処理重みコンテナの内容
が再確立される。
【００４６】その一方で、リソースが固定リソースの場
合には、以下が行われる。このようなリソースは、リセ
ットされる論理区画の構成から単純に除去される（ステ
ップ５０６）。たとえば、管理対象チャネル・パスの場
合、チャネル・パスは、リセットされる論理区画から構
成解除される。これによって、ＬＰＡＲグループのメン
バだけが、ＬＰＡＲグループのリソースにアクセスでき
ることが、もう一度再確立される。
合には、以下が行われる。このようなリソースは、リセ
ットされる論理区画の構成から単純に除去される（ステ
ップ５０６）。たとえば、管理対象チャネル・パスの場
合、チャネル・パスは、リセットされる論理区画から構
成解除される。これによって、ＬＰＡＲグループのメン
バだけが、ＬＰＡＲグループのリソースにアクセスでき
ることが、もう一度再確立される。
【００４７】ＬＰＡＲグループ環境内のＷＬＭによって
管理されるリソースの一部が、グループ・スコーピング
の必要を有しない場合があることにも留意されたい。そ
のようなリソースの一例が、論理区画のためにオンライ
ンになる論理中央処理装置（ＣＰ）の数である。ＬＰＡ
Ｒグループ内の特定の論理区画の効果的な挙動は、その
論理区画に対してオンラインである論理ＣＰの数によっ
て大きく影響される可能性がある。論理区画が定義する
ことのできるまたはオンラインである論理ＣＰの数は、
その論理区画がＬＰＡＲグループに含まれるか否かに無
関係に論理区画の特性であり、したがって、このリソー
スは、実際にはリソースのより大きいプールの一部には
ならない。しかし、ＬＰＡＲグループでのその効果は、
それによって、別のＬＰＡＲグループ・メンバに対して
あるＬＰＡＲグループ・メンバ内で効果的に動作させる
ことができるワークロードのタイプを変更できることで
ある。
管理されるリソースの一部が、グループ・スコーピング
の必要を有しない場合があることにも留意されたい。そ
のようなリソースの一例が、論理区画のためにオンライ
ンになる論理中央処理装置（ＣＰ）の数である。ＬＰＡ
Ｒグループ内の特定の論理区画の効果的な挙動は、その
論理区画に対してオンラインである論理ＣＰの数によっ
て大きく影響される可能性がある。論理区画が定義する
ことのできるまたはオンラインである論理ＣＰの数は、
その論理区画がＬＰＡＲグループに含まれるか否かに無
関係に論理区画の特性であり、したがって、このリソー
スは、実際にはリソースのより大きいプールの一部には
ならない。しかし、ＬＰＡＲグループでのその効果は、
それによって、別のＬＰＡＲグループ・メンバに対して
あるＬＰＡＲグループ・メンバ内で効果的に動作させる
ことができるワークロードのタイプを変更できることで
ある。
【００４８】一例では、複数の論理区画の間で共用され
るリソースが、ＣＰＵリソースである。本発明の一態様
では、ＯＳ／３９０ワークロード・マネージャは、論理
区画に関連する１つまたは複数の相対プロセッサ重みを
動的に調整することによって、論理区画の間でＣＰＵリ
ソースを再分配する。ＷＬＭは、重要なワークロードが
稼動する区画の重みが低すぎるので重要なワークロード
が遅延される時を理解する。ＷＬＭは、この区画の重み
を引き上げ、別の区画の重みを引き下げることによって
このワークロードを助けることができ、これによって、
追加のＣＰＵ容量が重要なワークロードに与えられる。
ＣＰＵリソースは、ワークロード要件が変化する際に、
必要な区画に動的に移動される。
るリソースが、ＣＰＵリソースである。本発明の一態様
では、ＯＳ／３９０ワークロード・マネージャは、論理
区画に関連する１つまたは複数の相対プロセッサ重みを
動的に調整することによって、論理区画の間でＣＰＵリ
ソースを再分配する。ＷＬＭは、重要なワークロードが
稼動する区画の重みが低すぎるので重要なワークロード
が遅延される時を理解する。ＷＬＭは、この区画の重み
を引き上げ、別の区画の重みを引き下げることによって
このワークロードを助けることができ、これによって、
追加のＣＰＵ容量が重要なワークロードに与えられる。
ＣＰＵリソースは、ワークロード要件が変化する際に、
必要な区画に動的に移動される。
【００４９】一実施形態では、論理区画重みのＷＬＭ管
理の有効範囲が、論理区画グループである。一例とし
て、ＷＬＭは、論理区画重みを調整するが、グループ内
の区画の重みの合計を一定に維持する。合計を一定に維
持することによって、グループに割り振られる総ＣＰＵ
リソースが、同一の物理コンピュータ上の他の独立のグ
ループに対して相対的に同一に保たれる。したがって、
ＷＬＭは、ある区画の重みを引き上げる時に、同一のグ
ループ内の別の区画の重みを下げる。
理の有効範囲が、論理区画グループである。一例とし
て、ＷＬＭは、論理区画重みを調整するが、グループ内
の区画の重みの合計を一定に維持する。合計を一定に維
持することによって、グループに割り振られる総ＣＰＵ
リソースが、同一の物理コンピュータ上の他の独立のグ
ループに対して相対的に同一に保たれる。したがって、
ＷＬＭは、ある区画の重みを引き上げる時に、同一のグ
ループ内の別の区画の重みを下げる。
【００５０】論理区画重みの管理は、ＷＬＭの目標指向
リソース割振り技法に対する機能強化であり、これは、
たとえば、米国特許第５４７３７７３号明細書および米
国特許第５６７５７３９号明細書に記載されている。
リソース割振り技法に対する機能強化であり、これは、
たとえば、米国特許第５４７３７７３号明細書および米
国特許第５６７５７３９号明細書に記載されている。
【００５１】上記の特許明細書に記載されているよう
に、ＷＬＭは、ＣＰＵディスパッチ優先順位を調整する
ことによって、論理区画内のＣＰＵリソースの割振りを
制御する。ＣＰＵディスパッチ優先順位は、サービス・
クラス・レベルで作業に割り当てられる。しかし、ディ
スパッチ優先順位の調整がサービス・クラスを助けな
い、さまざまな状況がある。たとえば、 １）サービス・クラスが、単独で、すでに非システム作
業に許可される最高のＣＰＵディスパッチ優先順位であ
る。 ２）サービス・クラスを助けるためのＣＰＵディスパッ
チ優先順位の変更が、それ以上の重要性を有する他のサ
ービス・クラスに及ぼす悪影響が大きすぎる。
に、ＷＬＭは、ＣＰＵディスパッチ優先順位を調整する
ことによって、論理区画内のＣＰＵリソースの割振りを
制御する。ＣＰＵディスパッチ優先順位は、サービス・
クラス・レベルで作業に割り当てられる。しかし、ディ
スパッチ優先順位の調整がサービス・クラスを助けな
い、さまざまな状況がある。たとえば、 １）サービス・クラスが、単独で、すでに非システム作
業に許可される最高のＣＰＵディスパッチ優先順位であ
る。 ２）サービス・クラスを助けるためのＣＰＵディスパッ
チ優先順位の変更が、それ以上の重要性を有する他のサ
ービス・クラスに及ぼす悪影響が大きすぎる。
【００５２】したがって、ＷＬＭは、サービス・クラス
が、ＣＰＵ遅延に起因してその目標を失いつつあり、そ
れをＣＰＵ優先順位の調節によって助けることができな
いことを見つけた時に、ＷＬＭは、失敗しつつあるサー
ビス・クラスに関連する区画の重みの調節を検討する。
が、ＣＰＵ遅延に起因してその目標を失いつつあり、そ
れをＣＰＵ優先順位の調節によって助けることができな
いことを見つけた時に、ＷＬＭは、失敗しつつあるサー
ビス・クラスに関連する区画の重みの調節を検討する。
【００５３】ＷＬＭが追加リソースの割振りを検討する
サービス・クラスを、レシーバ・サービス・クラスと呼
ぶ。ＷＬＭは、上に示した理由のどれかのために助ける
ことができない、所与の区画でのＣＰＵ遅延に起因して
目標を失いつつあるレシーバ・サービス・クラスを見つ
けた時に、ＷＬＭは、その区画の重みを引き上げること
を検討する。レシーバ・サービス・クラスを助けるため
に区画の重みを引き上げることができるかどうかを判定
するためにＷＬＭが従う論理の一実施形態を、図８に関
連して下で説明する。
サービス・クラスを、レシーバ・サービス・クラスと呼
ぶ。ＷＬＭは、上に示した理由のどれかのために助ける
ことができない、所与の区画でのＣＰＵ遅延に起因して
目標を失いつつあるレシーバ・サービス・クラスを見つ
けた時に、ＷＬＭは、その区画の重みを引き上げること
を検討する。レシーバ・サービス・クラスを助けるため
に区画の重みを引き上げることができるかどうかを判定
するためにＷＬＭが従う論理の一実施形態を、図８に関
連して下で説明する。
【００５４】１．区画の重みを増やすことがレシーバ・
クラスに及ぼす影響を見積もる（ステップ６００）。区
画の重みを増やすと、その区画のＣＰＵ容量が増える。
レシーバ・クラスでの作業のＣＰＵ需要は、一定と仮定
されるので、区画のＣＰＵ容量を増やすと、レシーバ・
サービス・クラスが必要とする、この容量の比率が減
る。レシーバ・サービス・クラスに対する利益の見積も
りは、レシーバ・サービス・クラスと、システム需要に
対する他の作業の両方の、使用可能なＣＰＵ容量の比率
のこの減少に基づく。
クラスに及ぼす影響を見積もる（ステップ６００）。区
画の重みを増やすと、その区画のＣＰＵ容量が増える。
レシーバ・クラスでの作業のＣＰＵ需要は、一定と仮定
されるので、区画のＣＰＵ容量を増やすと、レシーバ・
サービス・クラスが必要とする、この容量の比率が減
る。レシーバ・サービス・クラスに対する利益の見積も
りは、レシーバ・サービス・クラスと、システム需要に
対する他の作業の両方の、使用可能なＣＰＵ容量の比率
のこの減少に基づく。
【００５５】２．その重みを減らされる候補になる、論
理区画グループ内の別の区画を見つける（ステップ６０
２）。この区画を、候補ドナー区画と称する。候補ドナ
ー区画は、たとえば、区画の重みを下げることによっ
て、最も重要さの少ない作業が影響を受ける可能性が高
い区画を探すことによって、選択される。
理区画グループ内の別の区画を見つける（ステップ６０
２）。この区画を、候補ドナー区画と称する。候補ドナ
ー区画は、たとえば、区画の重みを下げることによっ
て、最も重要さの少ない作業が影響を受ける可能性が高
い区画を探すことによって、選択される。
【００５６】３．その重みを下げられる候補ドナー区画
で稼動する作業を有するすべてのサービス・クラスに対
する影響を見積もる（ステップ６０４）。候補ドナー区
画の重みを減らすことによって、候補ドナー区画のＣＰ
Ｕ容量が減る。このＣＰＵ容量の減少は、候補ドナーの
容量の比率としての、候補ドナーで稼動する作業を有す
るサービス・クラスのＣＰＵ需要が増えることを意味す
る。候補ドナーの重みを減らすことの悪影響の見積もり
は、これらのサービス・クラスが必要とする使用可能Ｃ
ＰＵ容量の比率のこの減少に基づく。
で稼動する作業を有するすべてのサービス・クラスに対
する影響を見積もる（ステップ６０４）。候補ドナー区
画の重みを減らすことによって、候補ドナー区画のＣＰ
Ｕ容量が減る。このＣＰＵ容量の減少は、候補ドナーの
容量の比率としての、候補ドナーで稼動する作業を有す
るサービス・クラスのＣＰＵ需要が増えることを意味す
る。候補ドナーの重みを減らすことの悪影響の見積もり
は、これらのサービス・クラスが必要とする使用可能Ｃ
ＰＵ容量の比率のこの減少に基づく。
【００５７】４．この重みの変更が正味の値を有するか
どうかを判定する（問合せ６０６）。すなわち、レシー
バ・サービス・クラスに対する利益が、関係するサービ
ス・クラスの目標および重要性に基づく、候補ドナー区
画の作業に対する悪影響に優越するかどうかを判定す
る。
どうかを判定する（問合せ６０６）。すなわち、レシー
バ・サービス・クラスに対する利益が、関係するサービ
ス・クラスの目標および重要性に基づく、候補ドナー区
画の作業に対する悪影響に優越するかどうかを判定す
る。
【００５８】５．重みの調節が正味の値を有する場合に
は、提案された区画の重みに対する変更を実施する（ス
テップ６０８）。正味の値がない場合には、ほかに候補
ドナー区画があるかどうかに関する判定を行う（問合せ
６１０）。そうである場合には、もう１つの候補ドナー
区画を選択し（ステップ６１２）、処理はステップ３
（ステップ６０４）で続行する。ほかに候補ドナー区画
がない場合には、処理を終了する（ステップ６１４）。
は、提案された区画の重みに対する変更を実施する（ス
テップ６０８）。正味の値がない場合には、ほかに候補
ドナー区画があるかどうかに関する判定を行う（問合せ
６１０）。そうである場合には、もう１つの候補ドナー
区画を選択し（ステップ６１２）、処理はステップ３
（ステップ６０４）で続行する。ほかに候補ドナー区画
がない場合には、処理を終了する（ステップ６１４）。
【００５９】ある区画で稼動するＷＬＭが、別の区画で
稼動する作業に対する区画重み変更の効果の見積もりを
行えるようにするために、各区画は、グループ内の各論
理区画に関する性能データを含む共用データ構造へのア
クセス権を有する。この区画レベルの性能データには、
たとえば以下が含まれる。 ・サービス・クラスによって区画で実行される作業のＣ
ＰＵ要件 ・各サービス・クラスが、その目標に向かってその区画
上でどの程度良好に動作しているか ・区画のＣＰＵディスパッチ優先順位によるＣＰＵ使用
量
稼動する作業に対する区画重み変更の効果の見積もりを
行えるようにするために、各区画は、グループ内の各論
理区画に関する性能データを含む共用データ構造へのア
クセス権を有する。この区画レベルの性能データには、
たとえば以下が含まれる。 ・サービス・クラスによって区画で実行される作業のＣ
ＰＵ要件 ・各サービス・クラスが、その目標に向かってその区画
上でどの程度良好に動作しているか ・区画のＣＰＵディスパッチ優先順位によるＣＰＵ使用
量
【００６０】本発明のＯＳ／３９０実施形態では、この
共用データ構造が、結合装置内で作成され、維持され
る。しかし、メッセージ交換または共用ディスクなどの
他のデータ共用手法を使用して、このデータ構造を実施
することができる。
共用データ構造が、結合装置内で作成され、維持され
る。しかし、メッセージ交換または共用ディスクなどの
他のデータ共用手法を使用して、このデータ構造を実施
することができる。
【００６１】上で説明したのは、コンピュータ環境のＣ
ＰＵリソースを動的に再分配する能力である。リソース
は、一例として、論理区画重みを動的に調整することに
よって、論理区画の間で再分配される。
ＰＵリソースを動的に再分配する能力である。リソース
は、一例として、論理区画重みを動的に調整することに
よって、論理区画の間で再分配される。
【００６２】コンピュータ環境のＣＰＵリソースの動的
調整のほかに、本発明のもう１つの態様では、論理プロ
セッサ・リソースも動的に調整することができる。
調整のほかに、本発明のもう１つの態様では、論理プロ
セッサ・リソースも動的に調整することができる。
【００６３】論理区画は、１つまたは複数の論理プロセ
ッサと共に構成され、この論理プロセッサは、中央演算
処理装置複合システムの物理中央処理装置上で、作業を
実行するためにディスパッチされる。区画がそれに割り
当てられたＣＰＵ容量を消費できるようにするために、
十分な論理プロセッサを論理区画に構成しなければなら
ない。たとえば、１０個のＣＰＵを有するＣＰＣ上で稼
動する論理区画Ａの場合を検討する。ワークロード・マ
ネージャが、論理区画ＡにＣＰＣの容量の５０％を割り
当てる場合、論理区画Ａは、少なくとも５つの論理プロ
セッサをそれに構成されることを必要とする（５つの論
理プロセッサは、ＣＰＵのうちの５つすなわちＣＰＣの
容量の５０％で稼動することができる）。論理区画Ａ
に、その後、ＣＰＣの容量の９５％が割り当てられた場
合、論理区画Ａは、１０個の論理プロセッサを有するよ
うに構成されるはずである。ＷＬＭは、静的に定義され
た論理プロセッサ構成を用いて論理区画Ａに割り当てら
れた容量を動的に調整することができるので、すべての
可能な容量割当てを収めるために、１０個の論理プロセ
ッサが論理区画Ａに構成される。しかし、論理区画Ａ
に、たとえばＣＰＣの容量の２０％だけが割り当てられ
る場合には、静的に定義された論理プロセッサから次の
２つ問題が生じる。１）１０個の論理プロセッサのそれ
ぞれが、平均して、物理ＣＰＵの容量の０．２の比率で
物理ＣＰＵリソースを消費することしかできない（１０
個のＣＰＵの２０％を１０個の論理プロセッサによって
分割すると、１論理プロセッサあたり０．２ＣＰＵにな
る）。これは、スループットが単一のタスクによってゲ
ーティングされるワークロードを厳しく制限する可能性
がある。というのは、その単一のタスクを、物理ＣＰＵ
の容量の０．２倍で実行することしかできなくなるから
である。これを、ショート・エンジン効果（short engi
ne effect）と称することがしばしばである。２）２つ
の論理プロセッサだけが必要な時に１０個の論理プロセ
ッサを管理しなければならない時に、ソフトウェアおよ
びハードウェアの効率が大きく低下する。
ッサと共に構成され、この論理プロセッサは、中央演算
処理装置複合システムの物理中央処理装置上で、作業を
実行するためにディスパッチされる。区画がそれに割り
当てられたＣＰＵ容量を消費できるようにするために、
十分な論理プロセッサを論理区画に構成しなければなら
ない。たとえば、１０個のＣＰＵを有するＣＰＣ上で稼
動する論理区画Ａの場合を検討する。ワークロード・マ
ネージャが、論理区画ＡにＣＰＣの容量の５０％を割り
当てる場合、論理区画Ａは、少なくとも５つの論理プロ
セッサをそれに構成されることを必要とする（５つの論
理プロセッサは、ＣＰＵのうちの５つすなわちＣＰＣの
容量の５０％で稼動することができる）。論理区画Ａ
に、その後、ＣＰＣの容量の９５％が割り当てられた場
合、論理区画Ａは、１０個の論理プロセッサを有するよ
うに構成されるはずである。ＷＬＭは、静的に定義され
た論理プロセッサ構成を用いて論理区画Ａに割り当てら
れた容量を動的に調整することができるので、すべての
可能な容量割当てを収めるために、１０個の論理プロセ
ッサが論理区画Ａに構成される。しかし、論理区画Ａ
に、たとえばＣＰＣの容量の２０％だけが割り当てられ
る場合には、静的に定義された論理プロセッサから次の
２つ問題が生じる。１）１０個の論理プロセッサのそれ
ぞれが、平均して、物理ＣＰＵの容量の０．２の比率で
物理ＣＰＵリソースを消費することしかできない（１０
個のＣＰＵの２０％を１０個の論理プロセッサによって
分割すると、１論理プロセッサあたり０．２ＣＰＵにな
る）。これは、スループットが単一のタスクによってゲ
ーティングされるワークロードを厳しく制限する可能性
がある。というのは、その単一のタスクを、物理ＣＰＵ
の容量の０．２倍で実行することしかできなくなるから
である。これを、ショート・エンジン効果（short engi
ne effect）と称することがしばしばである。２）２つ
の論理プロセッサだけが必要な時に１０個の論理プロセ
ッサを管理しなければならない時に、ソフトウェアおよ
びハードウェアの効率が大きく低下する。
【００６４】上記の欠陥に対処するために、論理区画の
構成は、本発明の一態様によれば、静的に定義されるの
ではなく、動的に調整される。一例では、区画を管理
し、動的調整を行うのは、ＷＬＭである。ＷＬＭは、コ
ンピュータ環境（またはＬＰＡＲグループ内）の各論理
区画についてこれを行うことができる。論理プロセッサ
の構成の動的調整に関連する論理の一実施形態を、図９
に関連して説明する。
構成は、本発明の一態様によれば、静的に定義されるの
ではなく、動的に調整される。一例では、区画を管理
し、動的調整を行うのは、ＷＬＭである。ＷＬＭは、コ
ンピュータ環境（またはＬＰＡＲグループ内）の各論理
区画についてこれを行うことができる。論理プロセッサ
の構成の動的調整に関連する論理の一実施形態を、図９
に関連して説明する。
【００６５】当初、論理区画を、ワークロード・マネー
ジャによって論理区画に割り当てられた容量（または、
実際に使用されている容量の方が大きい場合にはその容
量）を消費できるようにするのに必要な最小の個数の論
理プロセッサを用いて構成する（ステップ７００）。論
理区画の容量割り当て（または容量使用量）が変化する
際に（問合せ７０２）、評価を行って、論理区画に構成
される論理プロセッサの数を変更しなければならないか
どうかを判定する（ステップ７０４）。一例では、論理
区画に構成される論理プロセッサの数は、論理区画に割
り当てられた（または論理区画によって消費される）Ｃ
ＰＣ容量を提供するのに必要な物理ＣＰＵの数に近いま
まになる。したがって、各論理プロセッサは、物理ＣＰ
Ｕの容量に近い状態で実行され、管理される論理プロセ
ッサの数が、最小になる。
ジャによって論理区画に割り当てられた容量（または、
実際に使用されている容量の方が大きい場合にはその容
量）を消費できるようにするのに必要な最小の個数の論
理プロセッサを用いて構成する（ステップ７００）。論
理区画の容量割り当て（または容量使用量）が変化する
際に（問合せ７０２）、評価を行って、論理区画に構成
される論理プロセッサの数を変更しなければならないか
どうかを判定する（ステップ７０４）。一例では、論理
区画に構成される論理プロセッサの数は、論理区画に割
り当てられた（または論理区画によって消費される）Ｃ
ＰＣ容量を提供するのに必要な物理ＣＰＵの数に近いま
まになる。したがって、各論理プロセッサは、物理ＣＰ
Ｕの容量に近い状態で実行され、管理される論理プロセ
ッサの数が、最小になる。
【００６６】論理構成を変更するかどうかの評価を行う
ために、一例では次の式を使用する。 Ｌ＝floor［max（Ｗ，Ｕ）×Ｐ＋１．５］（最大値Ｌ＝
Ｐ） ここで、Ｌ＝論理区画に構成される論理プロセッサの
数、Ｗ＝論理区画に割り当てられるＣＰＣ容量の比率、
Ｕ＝論理区画によって現在使用されているＣＰＣ容量の
比率、Ｐ＝ＣＰＣ上の物理ＣＰＵの数である（ステップ
７０５）。
ために、一例では次の式を使用する。 Ｌ＝floor［max（Ｗ，Ｕ）×Ｐ＋１．５］（最大値Ｌ＝
Ｐ） ここで、Ｌ＝論理区画に構成される論理プロセッサの
数、Ｗ＝論理区画に割り当てられるＣＰＣ容量の比率、
Ｕ＝論理区画によって現在使用されているＣＰＣ容量の
比率、Ｐ＝ＣＰＣ上の物理ＣＰＵの数である（ステップ
７０５）。
【００６７】Ｌは、たとえば定期的で頻繁なインターバ
ル（たとえば１０秒ごと）に、Ｐ、Ｗ、およびＵの現在
の値に基づいて、ワークロード・マネージャによって評
価される。閾値を使用して、論理区画のＬの実際の値
（Ｌ−ａｃｔ）を上げるか下げるかしなければならない
かどうかを判定する。新たに計算されたＬの値（Ｌ−ｃ
ａｌｃ）が、Ｌ−ａｃｔの現在の値より高い場合（問合
せ７０６）、Ｌ−ａｃｔをＬ−ｃａｌｃまで引き上げる
（ステップ７０８）。そうでない場合に、Ｌ−ｃａｌｃ
がＬ−ａｃｔより２つ以上小さい値である場合（問合せ
７１０）、Ｌ−ａｃｔにＬ−ｃａｌｃ−１をセットする
（ステップ７１２）。Ｌ−ｃａｌｃが、Ｌ−ａｃｔと等
しいか、Ｌ−ａｃｔより１つだけ小さい場合には、論理
区画のＬ−ａｃｔの値の変更は行われない（ステップ７
１４）。これらの閾値の使用を介して、ワークロードの
すばやく高まる容量需要に応答しながらも、小さいワー
クロード変動に起因するＬ−ａｃｔの無用な変更が回避
される。
ル（たとえば１０秒ごと）に、Ｐ、Ｗ、およびＵの現在
の値に基づいて、ワークロード・マネージャによって評
価される。閾値を使用して、論理区画のＬの実際の値
（Ｌ−ａｃｔ）を上げるか下げるかしなければならない
かどうかを判定する。新たに計算されたＬの値（Ｌ−ｃ
ａｌｃ）が、Ｌ−ａｃｔの現在の値より高い場合（問合
せ７０６）、Ｌ−ａｃｔをＬ−ｃａｌｃまで引き上げる
（ステップ７０８）。そうでない場合に、Ｌ−ｃａｌｃ
がＬ−ａｃｔより２つ以上小さい値である場合（問合せ
７１０）、Ｌ−ａｃｔにＬ−ｃａｌｃ−１をセットする
（ステップ７１２）。Ｌ−ｃａｌｃが、Ｌ−ａｃｔと等
しいか、Ｌ−ａｃｔより１つだけ小さい場合には、論理
区画のＬ−ａｃｔの値の変更は行われない（ステップ７
１４）。これらの閾値の使用を介して、ワークロードの
すばやく高まる容量需要に応答しながらも、小さいワー
クロード変動に起因するＬ−ａｃｔの無用な変更が回避
される。
【００６８】もう１つの例示として、次の例を検討され
たい。Ｐ＝１０、Ｗ＝Ｕ＝２４％と仮定する。論理プロ
セッサの静的構成では、Ｗが９０％を超えて増加する場
合を扱うために、Ｌ（静的）＝１０が必要になるはずで
ある。しかし、本発明のこの態様によれば、Ｌ（動的）
＝floor［max（．２４，．２４）×１０＋１．５］＝３
である。したがって、この例では、Ｌ（静的）では、単
一のタスクが物理ＣＰＵの０．２４で実行されるように
制約されるが、Ｌ（動的）では、単一のタスクが、物理
ＣＰＵの０．８０で実行されることが可能であり、これ
によって、単一タスク性能によってゲーティングされる
ワークロードのスループットの２３３％の向上がもたら
される。さらに、この例では、Ｌ（静的）に必要な１０
個の論理プロセッサではなく、３つの論理プロセッサだ
けが管理されるので、本発明のこの態様に起因して、ソ
フトウェアおよびハードウェアの効率が大幅に改善され
る。
たい。Ｐ＝１０、Ｗ＝Ｕ＝２４％と仮定する。論理プロ
セッサの静的構成では、Ｗが９０％を超えて増加する場
合を扱うために、Ｌ（静的）＝１０が必要になるはずで
ある。しかし、本発明のこの態様によれば、Ｌ（動的）
＝floor［max（．２４，．２４）×１０＋１．５］＝３
である。したがって、この例では、Ｌ（静的）では、単
一のタスクが物理ＣＰＵの０．２４で実行されるように
制約されるが、Ｌ（動的）では、単一のタスクが、物理
ＣＰＵの０．８０で実行されることが可能であり、これ
によって、単一タスク性能によってゲーティングされる
ワークロードのスループットの２３３％の向上がもたら
される。さらに、この例では、Ｌ（静的）に必要な１０
個の論理プロセッサではなく、３つの論理プロセッサだ
けが管理されるので、本発明のこの態様に起因して、ソ
フトウェアおよびハードウェアの効率が大幅に改善され
る。
【００６９】コンピュータ環境の、管理されるもう１つ
の共用可能リソースは、本発明の一態様によれば、入出
力リソースなどの非同期リソースである。具体的に言う
と、コプロセッサ（たとえばチャネル・サブシステム）
内の入出力動作または入出力要求が管理される。この管
理には、優先順位の高い入出力動作がすばやく処理され
る、より高い優先順位の入出力動作がチャネルのより多
くの帯域幅を割り当てられる、もしくはその両方などの
入出力動作の優先順位付けが含まれる。
の共用可能リソースは、本発明の一態様によれば、入出
力リソースなどの非同期リソースである。具体的に言う
と、コプロセッサ（たとえばチャネル・サブシステム）
内の入出力動作または入出力要求が管理される。この管
理には、優先順位の高い入出力動作がすばやく処理され
る、より高い優先順位の入出力動作がチャネルのより多
くの帯域幅を割り当てられる、もしくはその両方などの
入出力動作の優先順位付けが含まれる。
【００７０】現在の大規模多重プログラミング・コンピ
ュータ・システムでは、付加された入出力装置の読取、
書込、および制御のための入出力動作などの長時間稼動
する処理の開始および実行は、通常は、複数の独立に動
作する計算要素（図１０参照）の使用によって達成され
る。たとえば、中央処理装置８００内で実行中のプログ
ラムは、付加された装置８０４との入出力動作を要求す
ることができる。しかし、付加された装置との入出力動
作の実際の開始および実行は、通常はチャネル・サブシ
ステム８０２と呼ばれる、１つまたは複数の別々に独立
に実行する、一緒に動作するプロセッサによって実行さ
れる。一般に、非同期入出力処理方法は、比較的長時間
稼動する入出力装置の実行と並列に他の作業のために中
央処理装置を最適化し効率的に使用するために使用され
る。すなわち、そうしなければ付加された入出力装置に
アクセスし、読み書きするために必要になるはずの総プ
ロセッサ・オーバーヘッド、処理時間、およびプロセッ
サ待ち時間を最小にするためである。そのような方法
は、大規模多重プログラミング・システムで他のプロセ
ッサ作業の実行と入出力動作との、最大のオーバーラッ
プまたは実行の並列性を達成するように設計される。
ュータ・システムでは、付加された入出力装置の読取、
書込、および制御のための入出力動作などの長時間稼動
する処理の開始および実行は、通常は、複数の独立に動
作する計算要素（図１０参照）の使用によって達成され
る。たとえば、中央処理装置８００内で実行中のプログ
ラムは、付加された装置８０４との入出力動作を要求す
ることができる。しかし、付加された装置との入出力動
作の実際の開始および実行は、通常はチャネル・サブシ
ステム８０２と呼ばれる、１つまたは複数の別々に独立
に実行する、一緒に動作するプロセッサによって実行さ
れる。一般に、非同期入出力処理方法は、比較的長時間
稼動する入出力装置の実行と並列に他の作業のために中
央処理装置を最適化し効率的に使用するために使用され
る。すなわち、そうしなければ付加された入出力装置に
アクセスし、読み書きするために必要になるはずの総プ
ロセッサ・オーバーヘッド、処理時間、およびプロセッ
サ待ち時間を最小にするためである。そのような方法
は、大規模多重プログラミング・システムで他のプロセ
ッサ作業の実行と入出力動作との、最大のオーバーラッ
プまたは実行の並列性を達成するように設計される。
【００７１】そのような非同期入出力処理システムで
は、中央処理装置が、Ｓ／３９０ ＳＴＡＲＴ ＳＵＢ
ＣＨＡＮＮＥＬ命令などの入出力命令の使用によってプ
ログラムが要求した入出力動作の実行を開始する。その
ような命令は、通常は、次の２つの責任を負う。 １．チャネル・サブシステムの入出力作業キューに入出
力動作要求をエンキュー（追加）し、 ２．入出力作業キューを処理するために非同期に実行中
のチャネル・サブシステムにシグナルを送る。
は、中央処理装置が、Ｓ／３９０ ＳＴＡＲＴ ＳＵＢ
ＣＨＡＮＮＥＬ命令などの入出力命令の使用によってプ
ログラムが要求した入出力動作の実行を開始する。その
ような命令は、通常は、次の２つの責任を負う。 １．チャネル・サブシステムの入出力作業キューに入出
力動作要求をエンキュー（追加）し、 ２．入出力作業キューを処理するために非同期に実行中
のチャネル・サブシステムにシグナルを送る。
【００７２】その後、中央処理装置は、他の作業／命令
を実行することができ、入出力装置との要求された入出
力動作の実際の実行に直接にはかかわらない。
を実行することができ、入出力装置との要求された入出
力動作の実際の実行に直接にはかかわらない。
【００７３】１）上の処理の非同期な性質、２）中央処
理装置とチャネル・サブシステム・プロセッサの独立動
作、３）中央処理装置の実行速度と比較して相対的に長
い、入出力動作の実行時間、および４）装置をチャネル
・サブシステムに接続するチャネル・パスなどのチャネ
ル・サブシステム・リソースの一部またはすべてが、入
出力動作がプログラムによって要求された時に他の動作
の実行で使用中である可能性があるという事実に起因し
て、複数の入出力要求が、チャネル・サブシステム入出
力作業キューに同時にエンキューされる可能性が非常に
高い。すなわち、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ命
令は、チャネル・サブシステムが要求された入出力動作
を実行する能力より高い速度で中央処理装置によって実
行され、これによって、保留入出力動作要求のＮレベル
の深さの入出力作業キューが継続的に引き起こされる。
理装置とチャネル・サブシステム・プロセッサの独立動
作、３）中央処理装置の実行速度と比較して相対的に長
い、入出力動作の実行時間、および４）装置をチャネル
・サブシステムに接続するチャネル・パスなどのチャネ
ル・サブシステム・リソースの一部またはすべてが、入
出力動作がプログラムによって要求された時に他の動作
の実行で使用中である可能性があるという事実に起因し
て、複数の入出力要求が、チャネル・サブシステム入出
力作業キューに同時にエンキューされる可能性が非常に
高い。すなわち、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ命
令は、チャネル・サブシステムが要求された入出力動作
を実行する能力より高い速度で中央処理装置によって実
行され、これによって、保留入出力動作要求のＮレベル
の深さの入出力作業キューが継続的に引き起こされる。
【００７４】保留入出力要求を処理するために、チャネ
ル・サブシステムを構成するマイクロプロセッサは、そ
れぞれの入出力作業キューを検査し（図１０参照）、１
つまたは複数の入出力要求をこれらのキューからデキュ
ーし、それぞれの入出力装置に関するデキューされた入
出力要求の開始を試みる。この活動の発端は、チャネル
・サブシステム内の問題のマイクロプロセッサおよび作
業キューに応じて変化する。たとえば、中央処理装置と
対話するチャネル・サブシステム入出力プロセッサは、
他の作業の実行に使用中でない時に周期的に、１つまた
は複数の中央処理装置ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥ
Ｌ信号の結果として、またはこの両方の組合せで、この
処理を開始する可能性がある。
ル・サブシステムを構成するマイクロプロセッサは、そ
れぞれの入出力作業キューを検査し（図１０参照）、１
つまたは複数の入出力要求をこれらのキューからデキュ
ーし、それぞれの入出力装置に関するデキューされた入
出力要求の開始を試みる。この活動の発端は、チャネル
・サブシステム内の問題のマイクロプロセッサおよび作
業キューに応じて変化する。たとえば、中央処理装置と
対話するチャネル・サブシステム入出力プロセッサは、
他の作業の実行に使用中でない時に周期的に、１つまた
は複数の中央処理装置ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥ
Ｌ信号の結果として、またはこの両方の組合せで、この
処理を開始する可能性がある。
【００７５】チャネル・サブシステムのさまざまな作業
キューの一例を、図１０に関連して説明する。前に述べ
たように、入出力要求は、たとえばＳＴＡＲＴ ＳＵＢ
ＣＨＡＮＮＥＬ命令によって、入出力プロセッサ作業キ
ュー８０６にエンキューされる。その後、入出力要求
は、入出力プロセッサ８０８によって、入出力プロセッ
サ作業キューからデキューされる。入出力プロセッサ作
業キューからデキューされた要求は、入出力プロセッサ
によって、チャネル・プロセッサ作業キュー８１０にエ
ンキューされる。その後、これらの要求は、チャネル・
プロセッサ８１２によってデキューされ、制御装置作業
キュー８１４にエンキューされる。チャネル・プロセッ
サは、制御装置作業キューから要求をデキューして、チ
ャネル・パスを介して制御装置へ、最終的には入出力装
置へ送る。
キューの一例を、図１０に関連して説明する。前に述べ
たように、入出力要求は、たとえばＳＴＡＲＴ ＳＵＢ
ＣＨＡＮＮＥＬ命令によって、入出力プロセッサ作業キ
ュー８０６にエンキューされる。その後、入出力要求
は、入出力プロセッサ８０８によって、入出力プロセッ
サ作業キューからデキューされる。入出力プロセッサ作
業キューからデキューされた要求は、入出力プロセッサ
によって、チャネル・プロセッサ作業キュー８１０にエ
ンキューされる。その後、これらの要求は、チャネル・
プロセッサ８１２によってデキューされ、制御装置作業
キュー８１４にエンキューされる。チャネル・プロセッ
サは、制御装置作業キューから要求をデキューして、チ
ャネル・パスを介して制御装置へ、最終的には入出力装
置へ送る。
【００７６】現在、Ｓ／３９０プロダクト・ファミリー
のシステム内では、チャネル・サブシステムのデキュー
処理および作業初期設定処理は、先入れ先出し法（ＦＩ
ＦＯ）に基づいて実行される。この処理は、論理的に実
施が最も単純であり、スループットの最適化を目的と
し、過去には、保留作業キューの平均深さが比較的浅
く、入出力作業保留時間が比較的短い持続時間にとどま
る（すなわち、さまざまな入出力作業キューの保留入出
力要求の平均数が、高い重要性のプログラムまたはリア
ルタイム・クリティカル・プログラムに関連する入出力
動作の総入出力応答時間を大幅に引き延ばさない）なら
ば、さまざまな非同期処理要素の間の作業転送のために
許容される戦略であった。
のシステム内では、チャネル・サブシステムのデキュー
処理および作業初期設定処理は、先入れ先出し法（ＦＩ
ＦＯ）に基づいて実行される。この処理は、論理的に実
施が最も単純であり、スループットの最適化を目的と
し、過去には、保留作業キューの平均深さが比較的浅
く、入出力作業保留時間が比較的短い持続時間にとどま
る（すなわち、さまざまな入出力作業キューの保留入出
力要求の平均数が、高い重要性のプログラムまたはリア
ルタイム・クリティカル・プログラムに関連する入出力
動作の総入出力応答時間を大幅に引き延ばさない）なら
ば、さまざまな非同期処理要素の間の作業転送のために
許容される戦略であった。
【００７７】しかし、クリティカルな作業または時間依
存の作業の適時な処理に関するユーザの需要をサポート
するためにアプリケーション／プログラム優先順位付け
機能を提供するオペレーティング・システムでは、保留
入出力要求に関するＦＩＦＯ処理戦略は、ＦＩＦＯ作業
キューの平均深さが増えるにつれて、ますます許容され
なくなる。たとえば、ＩＢＭ Enterprise Storage Serv
erと共に使用される並列アクセス・ボリュームでは、チ
ャネル・サブシステムの平均キュー深さが増える。これ
は、通常は、重要性が低いかタイム・クリティカルでな
い入出力要求が、ＦＩＦＯ作業キュー上でより重要な要
求の前にキューに置かれる可能性があり、したがって、
よりクリティカルな入出力要求の前に開始されることに
なるという事実に起因する。頻繁に、クリティカルでな
い作業は、長時間にわたってリソースを束縛する入出力
を実行し、より重要な作業が遭遇する遅延が増える。こ
れは、通常は、より重要な入出力要求の遅延の可能性が
高まることをもたらす。
存の作業の適時な処理に関するユーザの需要をサポート
するためにアプリケーション／プログラム優先順位付け
機能を提供するオペレーティング・システムでは、保留
入出力要求に関するＦＩＦＯ処理戦略は、ＦＩＦＯ作業
キューの平均深さが増えるにつれて、ますます許容され
なくなる。たとえば、ＩＢＭ Enterprise Storage Serv
erと共に使用される並列アクセス・ボリュームでは、チ
ャネル・サブシステムの平均キュー深さが増える。これ
は、通常は、重要性が低いかタイム・クリティカルでな
い入出力要求が、ＦＩＦＯ作業キュー上でより重要な要
求の前にキューに置かれる可能性があり、したがって、
よりクリティカルな入出力要求の前に開始されることに
なるという事実に起因する。頻繁に、クリティカルでな
い作業は、長時間にわたってリソースを束縛する入出力
を実行し、より重要な作業が遭遇する遅延が増える。こ
れは、通常は、より重要な入出力要求の遅延の可能性が
高まることをもたらす。
【００７８】入出力保留時間とも称する遅延時間（総リ
アルタイム遅延または中央処理装置の速度と比較した時
の相対時間遅れのいずれかとすることができる）の増加
は、チャネル・サブシステムおよび付加された装置が、
クリティカルな入出力要求の適時の完了に影響しない入
出力実行の速度を維持する能力がないこと（言い換える
と、高い重要性／時間にクリティカルなプログラムの実
行時間の許容不能な延長をもたらさない実行速度を維持
する能力がないこと）に起因することがしばしばであ
る。上で述べたように、クリティカルな入出力要求に関
する総入出力応答時間の許容不能な延長の確率は、ＦＩ
ＦＯ作業処理方法が使用される時に、一般に高まる。こ
の遅延の確率は、中央処理装置の速度および数が、付加
される入出力装置および、装置が付加されるチャネル・
パスなどの他の必要なチャネル・サブシステム要素の速
度の向上より高い割合で向上する際に、さらに大きくな
る。一般に、入出力速度の向上の割合に対する中央処理
装置の速度の向上の割合の不一致は、現在の大規模シス
テム環境で増大を続け、その結果、クリティカルな作業
のキューイング遅延およびより大きい入出力応答時間
（リアルタイムまたは相対時間のいずれか）の確率がま
すます高まる。
アルタイム遅延または中央処理装置の速度と比較した時
の相対時間遅れのいずれかとすることができる）の増加
は、チャネル・サブシステムおよび付加された装置が、
クリティカルな入出力要求の適時の完了に影響しない入
出力実行の速度を維持する能力がないこと（言い換える
と、高い重要性／時間にクリティカルなプログラムの実
行時間の許容不能な延長をもたらさない実行速度を維持
する能力がないこと）に起因することがしばしばであ
る。上で述べたように、クリティカルな入出力要求に関
する総入出力応答時間の許容不能な延長の確率は、ＦＩ
ＦＯ作業処理方法が使用される時に、一般に高まる。こ
の遅延の確率は、中央処理装置の速度および数が、付加
される入出力装置および、装置が付加されるチャネル・
パスなどの他の必要なチャネル・サブシステム要素の速
度の向上より高い割合で向上する際に、さらに大きくな
る。一般に、入出力速度の向上の割合に対する中央処理
装置の速度の向上の割合の不一致は、現在の大規模シス
テム環境で増大を続け、その結果、クリティカルな作業
のキューイング遅延およびより大きい入出力応答時間
（リアルタイムまたは相対時間のいずれか）の確率がま
すます高まる。
【００７９】例として、チャネル・サブシステムでのキ
ューイング遅延に起因する、高い重要性の入出力動作お
よび時間にクリティカルな入出力動作の長い入出力応答
時間の頻度を最小にするために、優先順位処理技法を定
義して、１つまたは複数のチャネル・サブシステム保留
入出力作業キューを処理する。
ューイング遅延に起因する、高い重要性の入出力動作お
よび時間にクリティカルな入出力動作の長い入出力応答
時間の頻度を最小にするために、優先順位処理技法を定
義して、１つまたは複数のチャネル・サブシステム保留
入出力作業キューを処理する。
【００８０】２つの独立に実行されるプロセッサまたは
プロセスの間の優先順位処理技法の実施の例には、以下
が含まれる。 １．エンキュー・プロセッサ（またはプロセス）が、プ
ログラム指定の（たとえばＷＬＭによる）優先順位番号
に基づく優先順位シーケンシング技法を使用して、チャ
ネル・サブシステム入出力作業キュー（処理の段階に依
存する特定のキュー）に入出力要求を追加する。チャネ
ル・サブシステムは、その後、ＦＩＦＩ技法を使用し
て、作業キューから最初の最も優先順位の高い入出力要
求を除去する。または、 ２．エンキュー・プロセッサ（またはプロセス）が、Ｆ
ＩＦＯエンキュー技法を使用して、入出力作業キューの
最下部に入出力要求を追加する。チャネル・サブシステ
ムは、優先順位選択技法を使用して、その後、作業キュ
ーのすべての入出力要求要素を探索し、最も高いプログ
ラム指定の優先順位番号を有する入出力要求を除去し、
処理する。
プロセスの間の優先順位処理技法の実施の例には、以下
が含まれる。 １．エンキュー・プロセッサ（またはプロセス）が、プ
ログラム指定の（たとえばＷＬＭによる）優先順位番号
に基づく優先順位シーケンシング技法を使用して、チャ
ネル・サブシステム入出力作業キュー（処理の段階に依
存する特定のキュー）に入出力要求を追加する。チャネ
ル・サブシステムは、その後、ＦＩＦＩ技法を使用し
て、作業キューから最初の最も優先順位の高い入出力要
求を除去する。または、 ２．エンキュー・プロセッサ（またはプロセス）が、Ｆ
ＩＦＯエンキュー技法を使用して、入出力作業キューの
最下部に入出力要求を追加する。チャネル・サブシステ
ムは、優先順位選択技法を使用して、その後、作業キュ
ーのすべての入出力要求要素を探索し、最も高いプログ
ラム指定の優先順位番号を有する入出力要求を除去し、
処理する。
【００８１】ＦＩＦＯエンキュー技法（技法２）では、
必要な命令が少なく、したがって、中央処理装置が、入
出力要求スケジューリング処理をよりすばやく完了する
ことができる。これによって、中央処理装置は、よりす
ばやく他の作業を実行できるようになる。チャネル・サ
ブシステムを構成するさまざまなマイクロプロセッサの
間のエンキュー／デキュー処理について、選択すべき技
法は、通常は、参加するプロセッサのどれが、その処理
容量および適時性の要件に関して最も制約されるかに依
存する。すなわち、エンキュー・プロセッサが最も制約
される場合には、第２の技法を選択する。デキュー・プ
ロセッサが最も制約される場合には、通常は第１の技法
を選択する。
必要な命令が少なく、したがって、中央処理装置が、入
出力要求スケジューリング処理をよりすばやく完了する
ことができる。これによって、中央処理装置は、よりす
ばやく他の作業を実行できるようになる。チャネル・サ
ブシステムを構成するさまざまなマイクロプロセッサの
間のエンキュー／デキュー処理について、選択すべき技
法は、通常は、参加するプロセッサのどれが、その処理
容量および適時性の要件に関して最も制約されるかに依
存する。すなわち、エンキュー・プロセッサが最も制約
される場合には、第２の技法を選択する。デキュー・プ
ロセッサが最も制約される場合には、通常は第１の技法
を選択する。
【００８２】これらの技法のどちらを使用するかに無関
係に、その結果は、チャネル・サブシステムが、到着時
刻またはＦＩＦＯ方法ではなく、優先順位付け方法に基
づく保留入出力要求の開始および実行を優先することで
ある。
係に、その結果は、チャネル・サブシステムが、到着時
刻またはＦＩＦＯ方法ではなく、優先順位付け方法に基
づく保留入出力要求の開始および実行を優先することで
ある。
【００８３】さらに、一実施形態では、使用されるエン
キュー技法および選択技法に無関係に、処理される要求
の優先順位付けまたは選択もしくはその両方に、さまざ
まな判断基準が使用される。一例では、この判断基準に
以下が含まれる。
キュー技法および選択技法に無関係に、処理される要求
の優先順位付けまたは選択もしくはその両方に、さまざ
まな判断基準が使用される。一例では、この判断基準に
以下が含まれる。
【００８４】１．各異なる番号が独自の優先順位レベル
に対応する、プログラム指定の優先順位番号に基づく保
留入出力要求の選択。たとえば、連続する独自の番号の
範囲を設け、数の範囲全体が、優先順位の区別を必要と
する別個の作業カテゴリの総数以上になるようにする。
たとえば、システムが、通常のＳ／３９０システムで可
能であるように、Ｎ個の異なるオペレーティング・シス
テムを同時に実行する能力を有する場合には、チャネル
・サブシステム優先順位技法は、Ｎ個以上の別個の優先
順位レベルを提供しなければならない。最低のレベルか
ら最高のレベルまでまたはその逆の各優先順位レベル
は、０からＮ−１までの範囲の独自の数によって表され
るはずである。
に対応する、プログラム指定の優先順位番号に基づく保
留入出力要求の選択。たとえば、連続する独自の番号の
範囲を設け、数の範囲全体が、優先順位の区別を必要と
する別個の作業カテゴリの総数以上になるようにする。
たとえば、システムが、通常のＳ／３９０システムで可
能であるように、Ｎ個の異なるオペレーティング・シス
テムを同時に実行する能力を有する場合には、チャネル
・サブシステム優先順位技法は、Ｎ個以上の別個の優先
順位レベルを提供しなければならない。最低のレベルか
ら最高のレベルまでまたはその逆の各優先順位レベル
は、０からＮ−１までの範囲の独自の数によって表され
るはずである。
【００８５】２．優先順位に無関係にすべてのエンキュ
ーされた要求に「フェアネス」も適用する技法を使用す
る、保留入出力要求の優先順位選択。これは、通常は、
たとえば、長時間にわたってチャネル・サブシステムに
不相応に多数の高い優先順位の要求が提示されることに
起因して発生する可能性がある、低い優先順位の要求が
長時間にわたって処理されない確率を最低にするために
所望される。フェアネス選択は、他の考慮点に応じて、
同一の優先順位の保留要求に適用することもできる。た
とえば、まだ選択されていない他の同一優先順位の要求
と共に、すでにデキューされ、開始に失敗し、複数回再
キューイングされた保留要求にフェアネスを提供するこ
とである。このような技法を、図１１に関連して説明す
る。この技法では、複数の異なるカテゴリの保留要求
に、優先順位とフェアネスの両方を適用する。
ーされた要求に「フェアネス」も適用する技法を使用す
る、保留入出力要求の優先順位選択。これは、通常は、
たとえば、長時間にわたってチャネル・サブシステムに
不相応に多数の高い優先順位の要求が提示されることに
起因して発生する可能性がある、低い優先順位の要求が
長時間にわたって処理されない確率を最低にするために
所望される。フェアネス選択は、他の考慮点に応じて、
同一の優先順位の保留要求に適用することもできる。た
とえば、まだ選択されていない他の同一優先順位の要求
と共に、すでにデキューされ、開始に失敗し、複数回再
キューイングされた保留要求にフェアネスを提供するこ
とである。このような技法を、図１１に関連して説明す
る。この技法では、複数の異なるカテゴリの保留要求
に、優先順位とフェアネスの両方を適用する。
【００８６】３．下記に関する外部ユーザ／オペレータ
の制御 １．優先順位処理技法のグローバルな使用可能化／使用
不能化。この制御は、優先順位技法が不要であるか、非
類型的なプログラム実行環境に適当に対応することがで
きない場合に、保留要求のＦＩＦＯ処理を共生するため
に必要になる場合がある。 ２．複数の論理区画の並列実行を提供するシステムの場
合の、所与の論理区画に関連する入出力要求の「デフォ
ルト」優先順位値をユーザが指定できるようにする外部
制御。これは、論理区画内で実行中のオペレーティング
・システムが、その入出力要求の優先順位値を指定する
ように設計されていないが、それでも、入出力優先順位
付けを指定する他の論理区画内で実行中の他のオペレー
ティング・システムと成功裡に競合しなければならない
時に使用される。 ３．複数の論理区画の並列実行を提供するシステムの場
合の、チャネル・サブシステムによって供給される値の
組全体からの、各論理区画の優先順位値のサブセット最
小最大範囲をユーザが指定できるようにするための外部
制御。この制御は、別々の論理区画内で実行中の複数の
オペレーティング・システムが、入出力優先順位を独立
に、それを使用する他の区画の知識なしに使用する時に
使用される。すなわち、各使用する区画によって開始さ
れる要求の優先順位に基づく分離を可能にするための制
御である。
の制御 １．優先順位処理技法のグローバルな使用可能化／使用
不能化。この制御は、優先順位技法が不要であるか、非
類型的なプログラム実行環境に適当に対応することがで
きない場合に、保留要求のＦＩＦＯ処理を共生するため
に必要になる場合がある。 ２．複数の論理区画の並列実行を提供するシステムの場
合の、所与の論理区画に関連する入出力要求の「デフォ
ルト」優先順位値をユーザが指定できるようにする外部
制御。これは、論理区画内で実行中のオペレーティング
・システムが、その入出力要求の優先順位値を指定する
ように設計されていないが、それでも、入出力優先順位
付けを指定する他の論理区画内で実行中の他のオペレー
ティング・システムと成功裡に競合しなければならない
時に使用される。 ３．複数の論理区画の並列実行を提供するシステムの場
合の、チャネル・サブシステムによって供給される値の
組全体からの、各論理区画の優先順位値のサブセット最
小最大範囲をユーザが指定できるようにするための外部
制御。この制御は、別々の論理区画内で実行中の複数の
オペレーティング・システムが、入出力優先順位を独立
に、それを使用する他の区画の知識なしに使用する時に
使用される。すなわち、各使用する区画によって開始さ
れる要求の優先順位に基づく分離を可能にするための制
御である。
【００８７】上の項目３．２および３．３について、一
実施形態では、中央処理装置が、論理区画内で実行中の
プログラムのユーザ指定のデフォルト優先順位値または
ユーザ指定の最大／最小許容優先順位を、その区画で動
作するプログラムに透過的な形で、暗黙のうちに割り当
てる。Ｓ／３９０システムでは、これは、論理区画マネ
ージャ（ハイパーバイザ）および中央処理装置のＳＴＡ
ＲＴ ＳＵＢＣＨＡＮＮＥＬ命令によって共同で達成す
ることができる。
実施形態では、中央処理装置が、論理区画内で実行中の
プログラムのユーザ指定のデフォルト優先順位値または
ユーザ指定の最大／最小許容優先順位を、その区画で動
作するプログラムに透過的な形で、暗黙のうちに割り当
てる。Ｓ／３９０システムでは、これは、論理区画マネ
ージャ（ハイパーバイザ）および中央処理装置のＳＴＡ
ＲＴ ＳＵＢＣＨＡＮＮＥＬ命令によって共同で達成す
ることができる。
【００８８】論理区画内で動作するプログラムが、入出
力動作を開始するためにＳＴＡＲＴＳＵＢＣＨＡＮＮＥ
Ｌを実行する時には、中央処理装置でのＳＴＡＲＴ Ｓ
ＵＢＣＨＡＮＮＥＬ命令の解釈実行で、暗黙のうちに、
ＳＩＥ（Start Interpretive Execution）ＳＤ（State
Description）テーブルから、デフォルト優先順位番号
および最大／最小許容優先順位番号の両方が獲得され
る。このテーブルは、論理区画ハイパーバイザが区画を
実行状態にするためにＳＩＥ命令を実行する時に、その
論理区画ハイパーバイザによって、中央処理装置内に作
成され、ロードされる。その後、ＳＴＡＲＴ ＳＵＢＣ
ＨＡＮＮＥＬの解釈実行では、ＳＩＥ状態記述テーブル
のデフォルト優先順位値および最大／最小優先順位値を
使用して、論理区画内で動作するプログラムによる関与
なしで、適当な優先順位値を入出力要求に暗黙のうちに
セットする。
力動作を開始するためにＳＴＡＲＴＳＵＢＣＨＡＮＮＥ
Ｌを実行する時には、中央処理装置でのＳＴＡＲＴ Ｓ
ＵＢＣＨＡＮＮＥＬ命令の解釈実行で、暗黙のうちに、
ＳＩＥ（Start Interpretive Execution）ＳＤ（State
Description）テーブルから、デフォルト優先順位番号
および最大／最小許容優先順位番号の両方が獲得され
る。このテーブルは、論理区画ハイパーバイザが区画を
実行状態にするためにＳＩＥ命令を実行する時に、その
論理区画ハイパーバイザによって、中央処理装置内に作
成され、ロードされる。その後、ＳＴＡＲＴ ＳＵＢＣ
ＨＡＮＮＥＬの解釈実行では、ＳＩＥ状態記述テーブル
のデフォルト優先順位値および最大／最小優先順位値を
使用して、論理区画内で動作するプログラムによる関与
なしで、適当な優先順位値を入出力要求に暗黙のうちに
セットする。
【００８９】優先順位値が、論理区画内で実行中のプロ
グラムによって指定されない時には、ＳＴＡＲＴ ＳＵ
ＢＣＨＡＮＮＥＬの解釈で、ユーザ指定のデフォルト優
先順位値が入出力要求に割り当てられる。論理区画内で
実行中のプログラムが、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮ
ＥＬを実行する時に優先順位番号を指定する時には、Ｓ
ＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬの解釈実行で、プログ
ラム指定の優先順位値を、状態記述テーブル内のハイパ
ーバイザ指定の最小／最大優先順位値と比較する。プロ
グラム指定の優先順位が、ハイパーバイザ指定の最小値
より小さい時には、状態記述テーブルからの最小値によ
って、暗黙のうちにプログラム指定の値を置換する。プ
ログラム指定の優先順位値が、ハイパーバイザ指定の最
大優先順位を超える時には、状態記述テーブルからの最
大優先順位値によって、プログラム指定の値を置換す
る。
グラムによって指定されない時には、ＳＴＡＲＴ ＳＵ
ＢＣＨＡＮＮＥＬの解釈で、ユーザ指定のデフォルト優
先順位値が入出力要求に割り当てられる。論理区画内で
実行中のプログラムが、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮ
ＥＬを実行する時に優先順位番号を指定する時には、Ｓ
ＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬの解釈実行で、プログ
ラム指定の優先順位値を、状態記述テーブル内のハイパ
ーバイザ指定の最小／最大優先順位値と比較する。プロ
グラム指定の優先順位が、ハイパーバイザ指定の最小値
より小さい時には、状態記述テーブルからの最小値によ
って、暗黙のうちにプログラム指定の値を置換する。プ
ログラム指定の優先順位値が、ハイパーバイザ指定の最
大優先順位を超える時には、状態記述テーブルからの最
大優先順位値によって、プログラム指定の値を置換す
る。
【００９０】上記の判断基準のうちの０個以上を使用し
て、優先順位選択技法を導出することができる。上記の
判断基準の少なくともいくつかを使用する、処理される
要求を選択するための技法の一実施形態を、図１１に関
連して説明する。
て、優先順位選択技法を導出することができる。上記の
判断基準の少なくともいくつかを使用する、処理される
要求を選択するための技法の一実施形態を、図１１に関
連して説明する。
【００９１】当初は、保留作業キューにアクセスする
（ステップ９００）。たとえば、入出力プロセッサ作業
キュー、チャネル・プロセッサ作業キュー、または制御
装置作業キューのいずれかにアクセスする。その後、デ
キューされた保留要求のカウントを１つ増分する（たと
えば、ＤＱＣＯＵＮＴ＝ＤＱＣＯＵＮＴ＋１）（ステッ
プ９０２）。
（ステップ９００）。たとえば、入出力プロセッサ作業
キュー、チャネル・プロセッサ作業キュー、または制御
装置作業キューのいずれかにアクセスする。その後、デ
キューされた保留要求のカウントを１つ増分する（たと
えば、ＤＱＣＯＵＮＴ＝ＤＱＣＯＵＮＴ＋１）（ステッ
プ９０２）。
【００９２】その後、どのカテゴリの保留要求を処理す
るかに関する判定を行う（ステップ９０４）。一例で
は、選択されるカテゴリが、（ＤＱＣｏｕｎｔ ＭＯＤ
ＵＬＵＳ カテゴリ数）に等しい。したがって、この例
では４つのカテゴリがあるので、選択されるカテゴリ
は、ＤＱＣｏｕｎｔ ＭＯＤＵＬＵＳ ４に等しい。結
果が０の場合には、任意の優先順位の最初の要求をデキ
ューする（ステップ９０６）。しかし、選択されるカテ
ゴリが１の場合には、前にデキューされていない最高優
先順位の最初の要求を選択する（ステップ９０８）。さ
らに、選択されるカテゴリが２の場合には、前にデキュ
ーされ、開始に成功しなかった最高の優先順位の最初の
要求を選択する（ステップ９１０）。しかし、結果が３
の場合には、前にデキューされていない任意の優先順位
の最初の要求を選択する（ステップ９１２）。その後、
選択された要求をデキューし、処理する（ステップ９１
４）。
るかに関する判定を行う（ステップ９０４）。一例で
は、選択されるカテゴリが、（ＤＱＣｏｕｎｔ ＭＯＤ
ＵＬＵＳ カテゴリ数）に等しい。したがって、この例
では４つのカテゴリがあるので、選択されるカテゴリ
は、ＤＱＣｏｕｎｔ ＭＯＤＵＬＵＳ ４に等しい。結
果が０の場合には、任意の優先順位の最初の要求をデキ
ューする（ステップ９０６）。しかし、選択されるカテ
ゴリが１の場合には、前にデキューされていない最高優
先順位の最初の要求を選択する（ステップ９０８）。さ
らに、選択されるカテゴリが２の場合には、前にデキュ
ーされ、開始に成功しなかった最高の優先順位の最初の
要求を選択する（ステップ９１０）。しかし、結果が３
の場合には、前にデキューされていない任意の優先順位
の最初の要求を選択する（ステップ９１２）。その後、
選択された要求をデキューし、処理する（ステップ９１
４）。
【００９３】上で詳細に説明したのは、コプロセッサ内
の非同期要求のための優先順位付け機構である。入出力
要求およびチャネル・サブシステムに関連して例を説明
したが、これらは例にすぎない。本発明は、他の非同期
要求およびコプロセッサに同等に適用可能である。さら
に、上に記載の例は、キューイングに関連して説明した
が、同様の優先順位付け機構を使用して、複数の動作を
同時に実行できるチャネル上のリソース（たとえば帯域
幅）の割り当てを調整することができ、これによって、
すべてを同等に実行するのではなく、優先順位の高い動
作により多くのチャネル・リソースを与えることができ
る。
の非同期要求のための優先順位付け機構である。入出力
要求およびチャネル・サブシステムに関連して例を説明
したが、これらは例にすぎない。本発明は、他の非同期
要求およびコプロセッサに同等に適用可能である。さら
に、上に記載の例は、キューイングに関連して説明した
が、同様の優先順位付け機構を使用して、複数の動作を
同時に実行できるチャネル上のリソース（たとえば帯域
幅）の割り当てを調整することができ、これによって、
すべてを同等に実行するのではなく、優先順位の高い動
作により多くのチャネル・リソースを与えることができ
る。
【００９４】さらに、本明細書に記載のさまざまな例
は、論理分割されたシステムに関連して説明されるが、
本発明の入出力優先順位機能を含むがそれに制限されな
い本発明のさまざまな態様は、論理区画を有しないかサ
ポートしないシステム内で使用可能である。
は、論理分割されたシステムに関連して説明されるが、
本発明の入出力優先順位機能を含むがそれに制限されな
い本発明のさまざまな態様は、論理区画を有しないかサ
ポートしないシステム内で使用可能である。
【００９５】本発明のもう１つの態様によれば、人間の
介入なしに使用可能なチャネル・リソースを必要な場所
に移動するか、余分のチャネル・リソースを除去するた
めに、コンピュータ環境の入出力構成（たとえばチャネ
ル・パス構成）を動的に変更することができる。これに
よって、入出力を構成するのに必要な技術が減り、総合
的なシステム可用性が強化され、導入されたチャネルの
利用度が最大になり、使用可能入出力容量を分配するの
にワークロードの相対優先順位が使用される。一実施形
態では、「最良」の変更を決定するために、変更を行う
前に１つまたは複数の要因を調べる。この要因には、た
とえば、応答時間または入出力速度に対する影響、特定
のワークロード目標を達成するための応答時間に対する
影響、宛先ポートが使用中であるかどうか、結果の可用
性特性（たとえば、共通の単一障害点がないパスの追
加）、および結果の入出力構成の複雑さ（またはエント
ロピ）が含まれる。
介入なしに使用可能なチャネル・リソースを必要な場所
に移動するか、余分のチャネル・リソースを除去するた
めに、コンピュータ環境の入出力構成（たとえばチャネ
ル・パス構成）を動的に変更することができる。これに
よって、入出力を構成するのに必要な技術が減り、総合
的なシステム可用性が強化され、導入されたチャネルの
利用度が最大になり、使用可能入出力容量を分配するの
にワークロードの相対優先順位が使用される。一実施形
態では、「最良」の変更を決定するために、変更を行う
前に１つまたは複数の要因を調べる。この要因には、た
とえば、応答時間または入出力速度に対する影響、特定
のワークロード目標を達成するための応答時間に対する
影響、宛先ポートが使用中であるかどうか、結果の可用
性特性（たとえば、共通の単一障害点がないパスの追
加）、および結果の入出力構成の複雑さ（またはエント
ロピ）が含まれる。
【００９６】入出力構成の動的調整に関連する論理の一
実施形態を、図１２ないし１７に関連して詳細に説明す
る。当初、基本平衡化処理は、たとえばコンピュータ環
境のワークロード・マネージャ構成要素によって、定期
的にスケジューリングされるタイム・インターバル、た
とえば１０秒ごとに呼び出される。基本平衡化処理の機
能は、サブシステム（たとえば論理制御装置）（浮動
（すなわち管理対象）チャネルを定義されている）にま
たがって均等に入出力速度を継続的に平衡化し、好まし
くは共通の単一障害点のない、複数のパスを介してすべ
ての装置にアクセスできるようにし、ハードウェア障害
の後にサブシステムの再平衡化を行うことである。この
処理には、データ収集（図１２のステップ１０００）お
よび平衡検査（ステップ１００２）という２つの構成要
素が含まれる。データ収集は、環境の各論理区画内（環
境が論理分割されると仮定する。論理分割されていない
場合には、各システム内）で各インターバルに１回実行
され、平衡検査は、グループ化されたＬＰＡＲ（やはり
グループ化を仮定する）ごとにインターバルごとに１回
だけ実行される。
実施形態を、図１２ないし１７に関連して詳細に説明す
る。当初、基本平衡化処理は、たとえばコンピュータ環
境のワークロード・マネージャ構成要素によって、定期
的にスケジューリングされるタイム・インターバル、た
とえば１０秒ごとに呼び出される。基本平衡化処理の機
能は、サブシステム（たとえば論理制御装置）（浮動
（すなわち管理対象）チャネルを定義されている）にま
たがって均等に入出力速度を継続的に平衡化し、好まし
くは共通の単一障害点のない、複数のパスを介してすべ
ての装置にアクセスできるようにし、ハードウェア障害
の後にサブシステムの再平衡化を行うことである。この
処理には、データ収集（図１２のステップ１０００）お
よび平衡検査（ステップ１００２）という２つの構成要
素が含まれる。データ収集は、環境の各論理区画内（環
境が論理分割されると仮定する。論理分割されていない
場合には、各システム内）で各インターバルに１回実行
され、平衡検査は、グループ化されたＬＰＡＲ（やはり
グループ化を仮定する）ごとにインターバルごとに１回
だけ実行される。
【００９７】この処理のデータ収集部分の直列化は、ど
のシステムでもＷＬＭだけがインターバルごとに１回基
本平衡化技法を呼び出すという事実によって得られる。
さらに、収集した情報を更新する時には、バージョン番
号検査が使用される。たとえば、結合装置内に記憶され
た制御ブロックを直列化して、収集された情報を更新す
る。これらの制御ブロックによって、グループ・レベル
のデータ収集が可能になり、これによって、同一ＣＰＣ
上のグループのメンバにまたがるチャネルの管理が可能
になる。
のシステムでもＷＬＭだけがインターバルごとに１回基
本平衡化技法を呼び出すという事実によって得られる。
さらに、収集した情報を更新する時には、バージョン番
号検査が使用される。たとえば、結合装置内に記憶され
た制御ブロックを直列化して、収集された情報を更新す
る。これらの制御ブロックによって、グループ・レベル
のデータ収集が可能になり、これによって、同一ＣＰＣ
上のグループのメンバにまたがるチャネルの管理が可能
になる。
【００９８】平衡検査を直列化するために、特にその目
的のためのグループ有効範囲を有する直列化を使用す
る。通常、平衡化がデータ収集の直後に呼び出される時
には、グループ単位の直列化が要求される。直列化が得
られる場合には、平衡検査が進行し、そうでない場合に
は、平衡検査が、グループ化されたＬＰＡＲ内ですでに
行われつつあり、このインターバル中にもう一度実行す
る必要はない。
的のためのグループ有効範囲を有する直列化を使用す
る。通常、平衡化がデータ収集の直後に呼び出される時
には、グループ単位の直列化が要求される。直列化が得
られる場合には、平衡検査が進行し、そうでない場合に
は、平衡検査が、グループ化されたＬＰＡＲ内ですでに
行われつつあり、このインターバル中にもう一度実行す
る必要はない。
【００９９】図１２のデータ収集処理を、図１３に関連
してさらに説明する。一実施形態では、定義されたサブ
システム（たとえば論理制御装置）ごとに、測定データ
を収集し、更新する（ステップ１１００）。測定データ
には、たとえば、接続時間、保留時間、サブシステム使
用中、装置使用中、宛先ポート使用中時間、および宛先
ポート使用中カウントが含まれる。更新された測定デー
タは、結合装置などの共用メモリ内の制御ブロックと共
に、プロセッサ・メモリ内の制御ブロックに記憶され
る。
してさらに説明する。一実施形態では、定義されたサブ
システム（たとえば論理制御装置）ごとに、測定データ
を収集し、更新する（ステップ１１００）。測定データ
には、たとえば、接続時間、保留時間、サブシステム使
用中、装置使用中、宛先ポート使用中時間、および宛先
ポート使用中カウントが含まれる。更新された測定デー
タは、結合装置などの共用メモリ内の制御ブロックと共
に、プロセッサ・メモリ内の制御ブロックに記憶され
る。
【０１００】測定データの更新の後に、各サブシステム
のデフォルト目標入出力速度を計算する（ステップ１１
０２）。この入出力速度は、追加のチャネル帯域幅が必
要または望まれるかどうかを示す。一例として、デフォ
ルト目標入出力速度は、接続時間によって重みを付けら
れる。この計算を実行するために、一例では、以下のス
テップが行われる。ＤＣＭによって管理されるサブシス
テムごとに、前のインターバル中にそのサブシステムが
与えた接続時間の量と共に、現在の速度または実際の速
度を得る。その後、入出力速度に接続時間を乗じて、結
果を得る。サブシステムの結果を足し合わせて、合計を
得る。接続時間によって重みを付けられたデフォルト目
標入出力速度を決定するために、この合計を総接続時間
で割る。
のデフォルト目標入出力速度を計算する（ステップ１１
０２）。この入出力速度は、追加のチャネル帯域幅が必
要または望まれるかどうかを示す。一例として、デフォ
ルト目標入出力速度は、接続時間によって重みを付けら
れる。この計算を実行するために、一例では、以下のス
テップが行われる。ＤＣＭによって管理されるサブシス
テムごとに、前のインターバル中にそのサブシステムが
与えた接続時間の量と共に、現在の速度または実際の速
度を得る。その後、入出力速度に接続時間を乗じて、結
果を得る。サブシステムの結果を足し合わせて、合計を
得る。接続時間によって重みを付けられたデフォルト目
標入出力速度を決定するために、この合計を総接続時間
で割る。
【０１０１】図１２に戻って、データ収集を実行した後
に、本明細書に記載されているように、平衡検査を実行
する（ステップ１００２）。平衡検査に関連する論理の
一実施形態を、図１４に関連して説明する。当初、平衡
検査をこの瞬間に実行しなければならないかどうかを判
定するために、直列化を実行する（問合せ１２００）。
グループ単位の直列化を得る試みが不成功の場合には、
平衡検査論理は実行されない（ステップ１２０２）。し
かし、直列化が得られる場合には、目標範囲から外れて
いるサブシステムを探す（ステップ１２０４）。
に、本明細書に記載されているように、平衡検査を実行
する（ステップ１００２）。平衡検査に関連する論理の
一実施形態を、図１４に関連して説明する。当初、平衡
検査をこの瞬間に実行しなければならないかどうかを判
定するために、直列化を実行する（問合せ１２００）。
グループ単位の直列化を得る試みが不成功の場合には、
平衡検査論理は実行されない（ステップ１２０２）。し
かし、直列化が得られる場合には、目標範囲から外れて
いるサブシステムを探す（ステップ１２０４）。
【０１０２】たとえば、すべてのサブシステムについて
実際の入出力速度を得、平均をとる（一例では、動的Ｃ
ＨＰＩＤ管理（ＤＣＭ）によって管理されるサブシステ
ムだけが、この平均に含まれる）。平均を判定した後
に、範囲を作成する。一例では、範囲は、たとえば、平
均値の±５％である。その後、各サブシステムの目標入
出力速度を、目標範囲と比較する。目標入出力速度が指
定されていない場合には、デフォルト目標入出力速度を
使用する。この比較の結果として、２つのリストが作成
される（ステップ１２０６）。一方のリストには、目標
範囲を超えるサブシステムが含まれ、もう一方には、目
標を達成しないサブシステムが含まれる。どの場合で
も、最近（たとえば最近の１０秒以内）に変更されたサ
ブシステムは、リストから排除される。
実際の入出力速度を得、平均をとる（一例では、動的Ｃ
ＨＰＩＤ管理（ＤＣＭ）によって管理されるサブシステ
ムだけが、この平均に含まれる）。平均を判定した後
に、範囲を作成する。一例では、範囲は、たとえば、平
均値の±５％である。その後、各サブシステムの目標入
出力速度を、目標範囲と比較する。目標入出力速度が指
定されていない場合には、デフォルト目標入出力速度を
使用する。この比較の結果として、２つのリストが作成
される（ステップ１２０６）。一方のリストには、目標
範囲を超えるサブシステムが含まれ、もう一方には、目
標を達成しないサブシステムが含まれる。どの場合で
も、最近（たとえば最近の１０秒以内）に変更されたサ
ブシステムは、リストから排除される。
【０１０３】その後、達成されない目標のリストをソー
トする（ステップ１２０８）。一例では、ＷＬＭを使用
してこのリストをソートする。というのは、ＷＬＭが、
どのサブシステムが最も重要であるかを決定する位置に
あるからである。したがって、ＷＬＭは、ＷＬＭがサー
ビスしようとする順序でサブシステムを並べる。
トする（ステップ１２０８）。一例では、ＷＬＭを使用
してこのリストをソートする。というのは、ＷＬＭが、
どのサブシステムが最も重要であるかを決定する位置に
あるからである。したがって、ＷＬＭは、ＷＬＭがサー
ビスしようとする順序でサブシステムを並べる。
【０１０４】リストをソートした後に、リストの１つま
たは複数のサブシステムが、たとえば利用度の低いサブ
システムから過度に利用されているサブシステムへ容量
をシフトすることによって、サービスされる（ステップ
１２１０）。割り当てられた時間内でサービスできる数
のサブシステムが調整される。
たは複数のサブシステムが、たとえば利用度の低いサブ
システムから過度に利用されているサブシステムへ容量
をシフトすることによって、サービスされる（ステップ
１２１０）。割り当てられた時間内でサービスできる数
のサブシステムが調整される。
【０１０５】容量の調整に関連する論理の一実施形態
を、図１５ないし１６に関連して説明する。当初は、リ
ストからサブシステムを選択する（ステップ１３００、
図１５）。一例では、選択されるのは、リストの最初の
サブシステムである。その後、問題が宛先ポート使用中
であるかどうかに関する判定を行う（問合せ１３０
２）。具体的に言うと、競合（たとえば宛先ポート使用
中時間）が高いかどうかに関する判定を行い、そうであ
る場合には、それに接続されるさまざまなインターフェ
ースに関してそれが変動するかどうかを判定する。宛先
ポート使用中がすべてのインターフェースで高い場合に
は、これは、別のチャネル・パスを追加する必要がある
ことを意味する。しかし、１つのインターフェースだけ
で高い場合には、チャネル・パスを別のインターフェー
スに移動する（ステップ１３０４）。したがって、既存
のパスが、過度な宛先ポート使用中時間を有するインタ
ーフェースから別のインターフェースに移動され、処理
は変更の実施（ステップ１３０６、図１６）に続行す
る。
を、図１５ないし１６に関連して説明する。当初は、リ
ストからサブシステムを選択する（ステップ１３００、
図１５）。一例では、選択されるのは、リストの最初の
サブシステムである。その後、問題が宛先ポート使用中
であるかどうかに関する判定を行う（問合せ１３０
２）。具体的に言うと、競合（たとえば宛先ポート使用
中時間）が高いかどうかに関する判定を行い、そうであ
る場合には、それに接続されるさまざまなインターフェ
ースに関してそれが変動するかどうかを判定する。宛先
ポート使用中がすべてのインターフェースで高い場合に
は、これは、別のチャネル・パスを追加する必要がある
ことを意味する。しかし、１つのインターフェースだけ
で高い場合には、チャネル・パスを別のインターフェー
スに移動する（ステップ１３０４）。したがって、既存
のパスが、過度な宛先ポート使用中時間を有するインタ
ーフェースから別のインターフェースに移動され、処理
は変更の実施（ステップ１３０６、図１６）に続行す
る。
【０１０６】変更を実施する方法の説明は、米国特許第
５２５７３７９号明細書、米国特許第５２５７３６８号
明細書、および米国特許第５２２０６５４号明細書に記
載されている。
５２５７３７９号明細書、米国特許第５２５７３６８号
明細書、および米国特許第５２２０６５４号明細書に記
載されている。
【０１０７】変更を実施した後に、目標範囲内にない他
のサブシステムがあるかどうかに関する判定を行う（問
合せ１３０８）。ない場合には、不平衡訂正の処理が完
了する。しかし、他のサブシステムが範囲内にない場合
には、この処理は、ステップ１３００「リストの次のサ
ブシステムを選択する」（図１５）に継続する。
のサブシステムがあるかどうかに関する判定を行う（問
合せ１３０８）。ない場合には、不平衡訂正の処理が完
了する。しかし、他のサブシステムが範囲内にない場合
には、この処理は、ステップ１３００「リストの次のサ
ブシステムを選択する」（図１５）に継続する。
【０１０８】問合せ１３０２に戻って、問題が競合に起
因するものでない場合には、処理は、本明細書で説明す
るように続行される。
因するものでない場合には、処理は、本明細書で説明す
るように続行される。
【０１０９】具体的に言うと、一例では、サブシステム
に追加することが可能なチャネル・パスを判定する（ス
テップ１３１０）。この判定には、物理トポロジ内で
の、その特定のサブシステムに到達することができるす
べてのチャネルの検査と、そのサブシステムに到達する
ことが可能な方法（パス）の判定が含まれる。パスは、
ハードウェア要素がそれを介して接続される接続性の順
列であり、これには、チャネルとサブシステムの両方が
含まれる。これらのパスのすべて（または、望むならば
サブセット）が、可能なパスに含まれる。
に追加することが可能なチャネル・パスを判定する（ス
テップ１３１０）。この判定には、物理トポロジ内で
の、その特定のサブシステムに到達することができるす
べてのチャネルの検査と、そのサブシステムに到達する
ことが可能な方法（パス）の判定が含まれる。パスは、
ハードウェア要素がそれを介して接続される接続性の順
列であり、これには、チャネルとサブシステムの両方が
含まれる。これらのパスのすべて（または、望むならば
サブセット）が、可能なパスに含まれる。
【０１１０】同様に、除去が可能なパスに関する判定を
行う（ステップ１３１２）。一例として、同一チャネル
上に複数のサブシステムがある場合に、共用するサブシ
ステムに接続されたパスの１つが、除去の候補とみなさ
れる。
行う（ステップ１３１２）。一例として、同一チャネル
上に複数のサブシステムがある場合に、共用するサブシ
ステムに接続されたパスの１つが、除去の候補とみなさ
れる。
【０１１１】その後、その変更によって影響を受けるサ
ブシステムに関する判定を行う（ステップ１３１４）。
さらに、変更される構成の複雑さを示すエントロピ・イ
ンデックスも、下で説明するように判定する。
ブシステムに関する判定を行う（ステップ１３１４）。
さらに、変更される構成の複雑さを示すエントロピ・イ
ンデックスも、下で説明するように判定する。
【０１１２】影響を受けるサブシステムの判定に関連す
る論理の一実施形態を、図１７に関連して説明する。当
初、サブシステムのサブシステム制御ブロック（ＳＳＣ
Ｂ）リストおよびチャネルのＣＨＰＩＤリストを、後の
使用のためにクリアする（ステップ１４００）。その
後、チャネル・パスＩＤを、提案されたチャネルに関連
する判断選択ブロック（ＤＳＢ）から取り出し、ＣＨＰ
ＩＤリストに追加する（ステップ１４０２）。具体的に
言うと、各パスは、判断選択ブロックを関連付けられて
いる。判断選択ブロックとは、たとえばチャネル・パス
のＩＤ（ＣＨＰＩＤ）、チャネル・パスに関連する論理
制御装置を示すサブシステム制御ブロック（ＳＳＣＢ）
ポインタ、および影響を受けるＳＳＣＢの配列を含む、
さまざまな情報を含む制御ブロックである。各ＳＳＣＢ
には、サブシステムに接続されたチャネルのすべてが含
まれる。
る論理の一実施形態を、図１７に関連して説明する。当
初、サブシステムのサブシステム制御ブロック（ＳＳＣ
Ｂ）リストおよびチャネルのＣＨＰＩＤリストを、後の
使用のためにクリアする（ステップ１４００）。その
後、チャネル・パスＩＤを、提案されたチャネルに関連
する判断選択ブロック（ＤＳＢ）から取り出し、ＣＨＰ
ＩＤリストに追加する（ステップ１４０２）。具体的に
言うと、各パスは、判断選択ブロックを関連付けられて
いる。判断選択ブロックとは、たとえばチャネル・パス
のＩＤ（ＣＨＰＩＤ）、チャネル・パスに関連する論理
制御装置を示すサブシステム制御ブロック（ＳＳＣＢ）
ポインタ、および影響を受けるＳＳＣＢの配列を含む、
さまざまな情報を含む制御ブロックである。各ＳＳＣＢ
には、サブシステムに接続されたチャネルのすべてが含
まれる。
【０１１３】その後、援助されるＳＳＣＢに関連するす
べてのＣＨＰＩＤも、ＣＨＰＩＤリストに追加する（ス
テップ１４０４）。具体的に言うと、ＳＳＣＢポインタ
を、援助されるＳＳＣＢを示すＤＳＢから取り出す。そ
の後、ＳＳＣＢのＣＨＰＩＤのすべてを、ＣＨＰＩＤリ
ストに追加する。
べてのＣＨＰＩＤも、ＣＨＰＩＤリストに追加する（ス
テップ１４０４）。具体的に言うと、ＳＳＣＢポインタ
を、援助されるＳＳＣＢを示すＤＳＢから取り出す。そ
の後、ＳＳＣＢのＣＨＰＩＤのすべてを、ＣＨＰＩＤリ
ストに追加する。
【０１１４】その後、リスト内のＣＨＰＩＤのそれぞれ
について、チャネル・パスに関連するＳＳＣＢを、ＳＳ
ＣＢリストに追加する（ステップ１４０６）。一例で
は、この情報は、各ＣＨＰＩＤに接続されたＳＳＣＢを
示すチャネル・パス・テーブルから入手される。
について、チャネル・パスに関連するＳＳＣＢを、ＳＳ
ＣＢリストに追加する（ステップ１４０６）。一例で
は、この情報は、各ＣＨＰＩＤに接続されたＳＳＣＢを
示すチャネル・パス・テーブルから入手される。
【０１１５】その後、ＳＳＣＢがリストに追加されたか
どうかに関する判定を行う（問合せ１４０８）。そうで
ある場合には、リスト内のＳＳＣＢのそれぞれについ
て、ステップ１４０４に関して上で説明したように、ま
だＣＨＰＩＤリストに含まれていないＣＨＰＩＤを追加
する（ステップ１４１０）。
どうかに関する判定を行う（問合せ１４０８）。そうで
ある場合には、リスト内のＳＳＣＢのそれぞれについ
て、ステップ１４０４に関して上で説明したように、ま
だＣＨＰＩＤリストに含まれていないＣＨＰＩＤを追加
する（ステップ１４１０）。
【０１１６】その後、リストに追加されたＣＨＰＩＤが
あったかどうかに関するもう１つの判定を行う（問合せ
１４１２）。リストに追加された他のＣＨＰＩＤがあっ
た場合には、処理はステップ１４０６で継続される。し
かし、リストに追加されたＳＳＣＢもＣＨＰＩＤもない
場合には（問合せ１４０８および１４１２）、リストの
ＳＳＣＢのそれぞれについて、ＤＳＢ配列要素を作成す
る（ステップ１４１４）。すなわち、ＳＳＣＢのそれぞ
れを、影響を受けるＳＳＣＢの配列に追加する。さら
に、配列要素のそれぞれを、実際の入出力速度、目標入
出力速度、目標入出力速度と実際の入出力速度の間の現
在のデルタ、およびＳＳＣＢポインタを用いて更新する
（ステップ１４１６）。
あったかどうかに関するもう１つの判定を行う（問合せ
１４１２）。リストに追加された他のＣＨＰＩＤがあっ
た場合には、処理はステップ１４０６で継続される。し
かし、リストに追加されたＳＳＣＢもＣＨＰＩＤもない
場合には（問合せ１４０８および１４１２）、リストの
ＳＳＣＢのそれぞれについて、ＤＳＢ配列要素を作成す
る（ステップ１４１４）。すなわち、ＳＳＣＢのそれぞ
れを、影響を受けるＳＳＣＢの配列に追加する。さら
に、配列要素のそれぞれを、実際の入出力速度、目標入
出力速度、目標入出力速度と実際の入出力速度の間の現
在のデルタ、およびＳＳＣＢポインタを用いて更新する
（ステップ１４１６）。
【０１１７】図１５に戻って、上記に加えて、各パスの
可用性インデックスを計算する（ステップ１３１６）。
一例では、可用性インデックスは、提案されたパスがサ
ブシステムへの既存のパスと共通して有する単一障害点
の個数を示す数である。チャネル・パスを追加する場合
には、単一障害点を有しないことが望まれる。チャネル
・パスを削除する場合には、通常は、最も多数の単一障
害点を有するパスが選択される。
可用性インデックスを計算する（ステップ１３１６）。
一例では、可用性インデックスは、提案されたパスがサ
ブシステムへの既存のパスと共通して有する単一障害点
の個数を示す数である。チャネル・パスを追加する場合
には、単一障害点を有しないことが望まれる。チャネル
・パスを削除する場合には、通常は、最も多数の単一障
害点を有するパスが選択される。
【０１１８】その後、影響を受けるシステムに対する影
響を見積もる（ステップ１３１８）。具体的に言うと、
一例では、各サブシステムに対する現在の負荷を調べ
て、変更を行った場合にそれがどれほど異なるかを判定
する。この情報を使用して、最適のオプションを選択す
る（ステップ１３２０）。最適のオプションを選択する
ために、たとえば下記を含むさまざまな要因を検討する
ことができる。 ・どのオプションでサブシステムが目標の最も近くに移
動されるか ・どのオプションが最良の可用性をもたらすか ・どのオプションが最良の対称性（最小のエントロピ）
をもたらすか ・このオプションでパスの総数が２未満に減るか ・このオプションは、明示的な目標のどれかに違反する
か（ＷＬＭは、デフォルト目標の代わりに使用される明
示的目標を供給することができる） ・このオプションは、アーキテクチャ的制限のどれかに
違反するか ・このオプションは、導入先によって定義される構成に
違反するか ・このオプションは、現在使用不能なリソースの使用を
試みるか
響を見積もる（ステップ１３１８）。具体的に言うと、
一例では、各サブシステムに対する現在の負荷を調べ
て、変更を行った場合にそれがどれほど異なるかを判定
する。この情報を使用して、最適のオプションを選択す
る（ステップ１３２０）。最適のオプションを選択する
ために、たとえば下記を含むさまざまな要因を検討する
ことができる。 ・どのオプションでサブシステムが目標の最も近くに移
動されるか ・どのオプションが最良の可用性をもたらすか ・どのオプションが最良の対称性（最小のエントロピ）
をもたらすか ・このオプションでパスの総数が２未満に減るか ・このオプションは、明示的な目標のどれかに違反する
か（ＷＬＭは、デフォルト目標の代わりに使用される明
示的目標を供給することができる） ・このオプションは、アーキテクチャ的制限のどれかに
違反するか ・このオプションは、導入先によって定義される構成に
違反するか ・このオプションは、現在使用不能なリソースの使用を
試みるか
【０１１９】１特定の例では、当初、どの状況の下でも
実施できない判断選択ブロック（ＤＳＢ）を排除する。
これには、たとえば、アーキテクチャ的制限に違反する
もの、パスの総数が２未満に減るもの、導入先によって
定義される構成に違反するもの（たとえば、定義で許容
される最大個数を超える浮動チャネル・パスを使用する
もの）、および現在使用不能なリソースの使用を試みる
もの（たとえば、使用不能にされたポートの使用を試み
るもの）が含まれる（この機能は、この処理のより早い
段階に移動し、その結果、可用性インデックスおよびサ
ブシステムに対する影響の見積もりが、絶対に選択でき
ないＤＳＢについて計算されないようにすることができ
る）。
実施できない判断選択ブロック（ＤＳＢ）を排除する。
これには、たとえば、アーキテクチャ的制限に違反する
もの、パスの総数が２未満に減るもの、導入先によって
定義される構成に違反するもの（たとえば、定義で許容
される最大個数を超える浮動チャネル・パスを使用する
もの）、および現在使用不能なリソースの使用を試みる
もの（たとえば、使用不能にされたポートの使用を試み
るもの）が含まれる（この機能は、この処理のより早い
段階に移動し、その結果、可用性インデックスおよびサ
ブシステムに対する影響の見積もりが、絶対に選択でき
ないＤＳＢについて計算されないようにすることができ
る）。
【０１２０】現在サブシステムへのパスが１つだけ存在
する場合（おそらくはシステム始動のすぐ後または障害
の後）、最適の可用性インデックスを有するパスを選択
する。複数のパスが同等の可用性インデックスを有する
場合には、目標サブシステムを目標入出力速度目標内に
移動する最低のエントロピ・インデックスを有するパス
を選択する。複数存在する場合には、その見積もられた
デルタの合計（ＤＳＢからの「Σ見積もられたデル
タ」）が最小であるパスを選択する。
する場合（おそらくはシステム始動のすぐ後または障害
の後）、最適の可用性インデックスを有するパスを選択
する。複数のパスが同等の可用性インデックスを有する
場合には、目標サブシステムを目標入出力速度目標内に
移動する最低のエントロピ・インデックスを有するパス
を選択する。複数存在する場合には、その見積もられた
デルタの合計（ＤＳＢからの「Σ見積もられたデル
タ」）が最小であるパスを選択する。
【０１２１】現在サブシステムへのパスが複数存在する
場合には、最良の可用性インデックスを有するＤＳＢの
組を見つける。その組から、目標サブシステムを目標入
出力速度の許容範囲内にする、最も低いエントロピ・イ
ンデックスを有するオプションを探す。複数存在する場
合には、その見積もられたデルタの合計（ＤＳＢからの
「Σ見積もられたデルタ」）が最小であるパスを選択す
る。
場合には、最良の可用性インデックスを有するＤＳＢの
組を見つける。その組から、目標サブシステムを目標入
出力速度の許容範囲内にする、最も低いエントロピ・イ
ンデックスを有するオプションを探す。複数存在する場
合には、その見積もられたデルタの合計（ＤＳＢからの
「Σ見積もられたデルタ」）が最小であるパスを選択す
る。
【０１２２】そのようなオプションが存在しない場合に
は、次によい可用性インデックスを有するパスの組を見
つけ、再度試みる。
は、次によい可用性インデックスを有するパスの組を見
つけ、再度試みる。
【０１２３】どのオプションでもサブシステムを許容範
囲内にすることができない場合には、可用性インデック
スおよびエントロピ・インデックスを考慮せずに、サブ
システムを目標に最も近づけるものを選択する（上で説
明した最適オプション選択のための技法は、一例にすぎ
ない。さまざまな追加、削除、および変更を、本発明の
主旨から逸脱せずに行うことができる。さらに、他の技
法を使用して、最適オプションを選択することができ
る）。
囲内にすることができない場合には、可用性インデック
スおよびエントロピ・インデックスを考慮せずに、サブ
システムを目標に最も近づけるものを選択する（上で説
明した最適オプション選択のための技法は、一例にすぎ
ない。さまざまな追加、削除、および変更を、本発明の
主旨から逸脱せずに行うことができる。さらに、他の技
法を使用して、最適オプションを選択することができ
る）。
【０１２４】最適オプションの選択を試みた後に、明示
的目標を有するサブシステムに影響せずに新しい目標を
達成できるかどうかに関する判定を行う（問合せ１３２
２）。言い換えると、最適オプションが、ＷＬＭによっ
て設定された明示的目標を有するサブシステムに悪影響
を及ぼすかどうかを判定する。そうである場合には、ワ
ークロード・マネージャを呼び出して、適当なパスを選
択する（ステップ１３２４）。具体的に言うと、ワーク
ロード・マネージャは、パスを選択し、ドナーの新しい
目標を選択する。
的目標を有するサブシステムに影響せずに新しい目標を
達成できるかどうかに関する判定を行う（問合せ１３２
２）。言い換えると、最適オプションが、ＷＬＭによっ
て設定された明示的目標を有するサブシステムに悪影響
を及ぼすかどうかを判定する。そうである場合には、ワ
ークロード・マネージャを呼び出して、適当なパスを選
択する（ステップ１３２４）。具体的に言うと、ワーク
ロード・マネージャは、パスを選択し、ドナーの新しい
目標を選択する。
【０１２５】その後、または、明示的目標を有するサブ
システムに悪影響を及ぼさずに新しい目標を達成できる
場合に、変更を実施し（ステップ１３０６）、処理は、
目標範囲内にない他のサブシステムが存在するかどうか
の判定（問合せ１３０８）に継続する。
システムに悪影響を及ぼさずに新しい目標を達成できる
場合に、変更を実施し（ステップ１３０６）、処理は、
目標範囲内にない他のサブシステムが存在するかどうか
の判定（問合せ１３０８）に継続する。
【０１２６】上で述べたように、ＷＬＭは、明示的入出
力速度目標を設定することができ、これは、デフォルト
平均入出力速度目標の代わりに使用される。一実施形態
では、サービス・クラスがその目標を満たさないことを
ＷＬＭが見つけた時に、ＷＬＭが明示的目標を設定す
る。明示的サブシステム入出力速度目標の設定に関連す
る論理の一実施形態を、図１８に関連して説明する。
力速度目標を設定することができ、これは、デフォルト
平均入出力速度目標の代わりに使用される。一実施形態
では、サービス・クラスがその目標を満たさないことを
ＷＬＭが見つけた時に、ＷＬＭが明示的目標を設定す
る。明示的サブシステム入出力速度目標の設定に関連す
る論理の一実施形態を、図１８に関連して説明する。
【０１２７】当初、入出力が最大の遅延を引き起こして
いるかどうかを判定する（問合せ１５００）。そうでな
い場合には、本発明のこの態様においては処理が完了す
る。しかし、入出力が最大の遅延を引き起こしている場
合には、入出力優先順位調整を試みる（ステップ１５０
２）。その後、サービス・クラスがその目標を満たして
いるかどうかに関する判定を行う（問合せ１５０４）。
サービス・クラスがその目標を満たしている場合には、
処理が完了する。しかし、サービス・クラスが、まだそ
の目標を満たしていない場合には、そのサービス・クラ
スによって使用されており、低い入出力速度を有するサ
ブシステムを探す（ステップ１５０６）。突きとめられ
た１つまたは複数のサブシステムについて、新しいサブ
システム入出力速度目標を設定する。一例では、定義済
みの量だけ現在の目標を増やし、サブシステムに対する
影響を見積もることによって、サブシステム入出力目標
が設定される。影響が十分である（たとえば、レシーバ
値を超える）場合には、処理が完了する。そうでない場
合には、目標をもう一度増やし、この処理を繰り返す。
いるかどうかを判定する（問合せ１５００）。そうでな
い場合には、本発明のこの態様においては処理が完了す
る。しかし、入出力が最大の遅延を引き起こしている場
合には、入出力優先順位調整を試みる（ステップ１５０
２）。その後、サービス・クラスがその目標を満たして
いるかどうかに関する判定を行う（問合せ１５０４）。
サービス・クラスがその目標を満たしている場合には、
処理が完了する。しかし、サービス・クラスが、まだそ
の目標を満たしていない場合には、そのサービス・クラ
スによって使用されており、低い入出力速度を有するサ
ブシステムを探す（ステップ１５０６）。突きとめられ
た１つまたは複数のサブシステムについて、新しいサブ
システム入出力速度目標を設定する。一例では、定義済
みの量だけ現在の目標を増やし、サブシステムに対する
影響を見積もることによって、サブシステム入出力目標
が設定される。影響が十分である（たとえば、レシーバ
値を超える）場合には、処理が完了する。そうでない場
合には、目標をもう一度増やし、この処理を繰り返す。
【０１２８】上で詳細に説明したのは、入出力構成の動
的調整を提供する動的ＣＨＰＩＤ管理（ＤＣＭ）であ
る。ＤＣＭは、ＷＬＭに有利に統合され、これによっ
て、ワークロードおよび目標の理解を用いて判断を行え
るようになる。さらに、ＤＣＭを用いると、複数の区画
（たとえば区画のグループの区画）にまたがるチャネル
の管理が可能になる。これによって、必要な場所へのリ
ソースの追加、ならびに余分なリソースの除去が可能に
なる。
的調整を提供する動的ＣＨＰＩＤ管理（ＤＣＭ）であ
る。ＤＣＭは、ＷＬＭに有利に統合され、これによっ
て、ワークロードおよび目標の理解を用いて判断を行え
るようになる。さらに、ＤＣＭを用いると、複数の区画
（たとえば区画のグループの区画）にまたがるチャネル
の管理が可能になる。これによって、必要な場所へのリ
ソースの追加、ならびに余分なリソースの除去が可能に
なる。
【０１２９】上で説明したように、動的ＣＨＰＩＤ管理
（ＤＣＭ）を用いて、サブシステムに追加（またはそれ
から除去）される「最適の」チャネルが選択される。こ
れを行うために、たとえば結果の入出力構成の複雑さ
（またはエントロピ）を含む、１つまたは複数の属性が
試験される。
（ＤＣＭ）を用いて、サブシステムに追加（またはそれ
から除去）される「最適の」チャネルが選択される。こ
れを行うために、たとえば結果の入出力構成の複雑さ
（またはエントロピ）を含む、１つまたは複数の属性が
試験される。
【０１３０】エントロピの増加は、入出力構成を過度に
複雑にし、ＤＣＭの処理の過度な時間、影響を受けるサ
ブシステムの過剰な数に起因する不正確な結果、性能報
告の複雑さ、および問題判定の複雑さをもたらす。した
がって、本発明の一態様では、異なる選択肢の相対エン
トロピを判定し、その結果、構成をどのように調整する
かの選択を行う時に、入出力速度および可用性などの他
の検討点と共に、相対エントロピを検討できるようにす
る機能が提供される。
複雑にし、ＤＣＭの処理の過度な時間、影響を受けるサ
ブシステムの過剰な数に起因する不正確な結果、性能報
告の複雑さ、および問題判定の複雑さをもたらす。した
がって、本発明の一態様では、異なる選択肢の相対エン
トロピを判定し、その結果、構成をどのように調整する
かの選択を行う時に、入出力速度および可用性などの他
の検討点と共に、相対エントロピを検討できるようにす
る機能が提供される。
【０１３１】相対エントロピを判定する際には、エント
ロピ・インデックスを計算する。たとえば、パスを追加
する場合には、エントロピ・インデックスは、結果の構
成のチャネル数およびサブシステム数の合計になる。さ
らに、パスを削除する場合には、エントロピ・インデッ
クスは、パスが削除された後に目標サブシステムに相互
接続されているチャネルおよびサブシステムの組を反映
する。これには、もはやその組に含まれないチャネルお
よびサブシステムは含まれない。
ロピ・インデックスを計算する。たとえば、パスを追加
する場合には、エントロピ・インデックスは、結果の構
成のチャネル数およびサブシステム数の合計になる。さ
らに、パスを削除する場合には、エントロピ・インデッ
クスは、パスが削除された後に目標サブシステムに相互
接続されているチャネルおよびサブシステムの組を反映
する。これには、もはやその組に含まれないチャネルお
よびサブシステムは含まれない。
【０１３２】各オプションのエントロピの度合を計算す
るために、その決定が実施されると仮定して、一緒に接
続されるチャネルおよびサブシステムの数を使用する。
エントロピ技法の基本的な前提の１つが、複数の提案さ
れたトポロジの間の比較と、どのトポロジがより対称で
あるか、またはより少ないエントロピを有するかの判定
とを可能にするインデックスを計算することである。こ
れの目的は、大規模な相互接続されたトポロジを避ける
ことである。このようなトポロジは、入出力速度技法の
精度を下げ、過度に複雑なトポロジに起因して、事後に
性能問題を分析することを困難にすると思われる。
るために、その決定が実施されると仮定して、一緒に接
続されるチャネルおよびサブシステムの数を使用する。
エントロピ技法の基本的な前提の１つが、複数の提案さ
れたトポロジの間の比較と、どのトポロジがより対称で
あるか、またはより少ないエントロピを有するかの判定
とを可能にするインデックスを計算することである。こ
れの目的は、大規模な相互接続されたトポロジを避ける
ことである。このようなトポロジは、入出力速度技法の
精度を下げ、過度に複雑なトポロジに起因して、事後に
性能問題を分析することを困難にすると思われる。
【０１３３】エントロピ判定技法の一実施形態を、さま
ざまな例に関連して説明する。たとえば、図１９は、２
つのサブシステム１６０４に接続された２つのチャネル
１６０２を含む構成１６００の一例を示す図である。サ
ブシステム２２は、追加リソースを必要とする場合に、
少なくとも２つの場所からそれを入手することができ
る。サブシステム２２は、チャネル１またはチャネル３
のいずれかからそれを受け取ることができる。サブシス
テム２２がチャネル３からそれを入手する場合、結果の
構成は、３つのチャネルと２つのサブシステムを有する
（図２０）。これによって、この構成に５（３＋２）の
エントロピ・インデックスが与えられる。しかし、サブ
システム２２が、チャネル１から追加リソースを受け取
る場合（図２１）、結果の構成は、元々有したもの以上
のチャネルもサブシステムも有しておらず、結果のエン
トロピ・インデックスは２になる。この例では、第２の
オプションが最小のエントロピを有する。
ざまな例に関連して説明する。たとえば、図１９は、２
つのサブシステム１６０４に接続された２つのチャネル
１６０２を含む構成１６００の一例を示す図である。サ
ブシステム２２は、追加リソースを必要とする場合に、
少なくとも２つの場所からそれを入手することができ
る。サブシステム２２は、チャネル１またはチャネル３
のいずれかからそれを受け取ることができる。サブシス
テム２２がチャネル３からそれを入手する場合、結果の
構成は、３つのチャネルと２つのサブシステムを有する
（図２０）。これによって、この構成に５（３＋２）の
エントロピ・インデックスが与えられる。しかし、サブ
システム２２が、チャネル１から追加リソースを受け取
る場合（図２１）、結果の構成は、元々有したもの以上
のチャネルもサブシステムも有しておらず、結果のエン
トロピ・インデックスは２になる。この例では、第２の
オプションが最小のエントロピを有する。
【０１３４】もう１つの例を検討されたい。図２２に示
された例では、サブシステム２２が、追加リソースを必
要としている。その追加リソースは、チャネル２または
チャネル４から入手することができる。チャネル２が使
用される場合（図２３）、結果のエントロピ・インデッ
クスは５になる（すなわち、ある構成で３つのチャネル
が２つのサブシステムに相互接続されているが、チャネ
ル４は、接続されていないのでカウントされない）。チ
ャネル４が使用される場合（図２４）、結果のインデッ
クスは３になる。したがって、第２の選択肢が最小のエ
ントロピを有する。
された例では、サブシステム２２が、追加リソースを必
要としている。その追加リソースは、チャネル２または
チャネル４から入手することができる。チャネル２が使
用される場合（図２３）、結果のエントロピ・インデッ
クスは５になる（すなわち、ある構成で３つのチャネル
が２つのサブシステムに相互接続されているが、チャネ
ル４は、接続されていないのでカウントされない）。チ
ャネル４が使用される場合（図２４）、結果のインデッ
クスは３になる。したがって、第２の選択肢が最小のエ
ントロピを有する。
【０１３５】次に、構成が分割される場合を検討して、
これがエントロピにどのように影響するかを判定する。
これがエントロピにどのように影響するかを判定する。
【０１３６】図２５を参照すると、サブシステム２３
が、過度の容量を有する場合に、チャネル２またはチャ
ネル３を除去することができる。チャネル２を除去する
場合（図２６）、構成が分割され、両方の構成のエント
ロピ・インデックスが下がる。チャネル３を除去する場
合（図２７）、まだ１つの構成が存在するが、エントロ
ピ・インデックスは元のインデックスより低い。一実施
形態では、構成を２つに分割するという決定は、２つの
より複雑でないネットワークをもたらし、よりよい選択
肢であると思われる。
が、過度の容量を有する場合に、チャネル２またはチャ
ネル３を除去することができる。チャネル２を除去する
場合（図２６）、構成が分割され、両方の構成のエント
ロピ・インデックスが下がる。チャネル３を除去する場
合（図２７）、まだ１つの構成が存在するが、エントロ
ピ・インデックスは元のインデックスより低い。一実施
形態では、構成を２つに分割するという決定は、２つの
より複雑でないネットワークをもたらし、よりよい選択
肢であると思われる。
【０１３７】削除の際に、既存の構成（図２８）のイン
デックスならびに考慮中のサブシステムを含む提案され
た構成（図２９の右側）のインデックスが既知である場
合には、もう一方の構成（図２９の左側）のインデック
スは、減算によって計算することができる。この例で
は、もう一方の構成のインデックスは、２に等しい（４
−３＝１かつ２−１＝１、したがって１＋１＝２）。図
３０のように、減算がサブシステムまたはチャネルの数
としての０をもたらす場合には、エントロピは、構成を
分割せずに減らされている（たとえば、２サブシステム
−２サブシステム＝０）。一実施形態では、分割が好ま
しい。
デックスならびに考慮中のサブシステムを含む提案され
た構成（図２９の右側）のインデックスが既知である場
合には、もう一方の構成（図２９の左側）のインデック
スは、減算によって計算することができる。この例で
は、もう一方の構成のインデックスは、２に等しい（４
−３＝１かつ２−１＝１、したがって１＋１＝２）。図
３０のように、減算がサブシステムまたはチャネルの数
としての０をもたらす場合には、エントロピは、構成を
分割せずに減らされている（たとえば、２サブシステム
−２サブシステム＝０）。一実施形態では、分割が好ま
しい。
【０１３８】以下の例では、サブシステム２３が、過剰
なリソースを有する（図３１）。チャネル２またはチャ
ネル３を除去することができる。チャネル３を除去する
場合（図３２）、結果のエントロピ・インデックスは７
になる。チャネル２を除去する場合（図３３）、構成が
２つの構成に分割され、考慮中の構成（サブシステム２
３を有する構成）は、５のエントロピ・インデックスを
有し、結果の第２の構成は、３のエントロピ・インデッ
クスを有する。一実施形態では、構成の分割が好まし
い。
なリソースを有する（図３１）。チャネル２またはチャ
ネル３を除去することができる。チャネル３を除去する
場合（図３２）、結果のエントロピ・インデックスは７
になる。チャネル２を除去する場合（図３３）、構成が
２つの構成に分割され、考慮中の構成（サブシステム２
３を有する構成）は、５のエントロピ・インデックスを
有し、結果の第２の構成は、３のエントロピ・インデッ
クスを有する。一実施形態では、構成の分割が好まし
い。
【０１３９】次に、結果のエントロピ値ではなく、削除
の際に分割を探すことだけが望まれる場合を判定するた
めの例を検討する。
の際に分割を探すことだけが望まれる場合を判定するた
めの例を検討する。
【０１４０】図３４に示された例では、サブシステム２
３が、多すぎる帯域幅を有する。チャネル２またはチャ
ネル４のいずれかを除去することができる。チャネル２
を除去する場合（図３５）、新しいエントロピ・インデ
ックス６が得られ、残りの第２の構成のエントロピ・イ
ンデックスは３である。チャネル４を除去する場合（図
３６）、新しいエントロピ・インデックス５が得られ、
残りの第２の構成のエントロピ・インデックスは４であ
る。５および４のエントロピ・インデックスを有する構
成が、よりよい選択肢である。したがって、一実施形態
では、分割の種類が重要である。
３が、多すぎる帯域幅を有する。チャネル２またはチャ
ネル４のいずれかを除去することができる。チャネル２
を除去する場合（図３５）、新しいエントロピ・インデ
ックス６が得られ、残りの第２の構成のエントロピ・イ
ンデックスは３である。チャネル４を除去する場合（図
３６）、新しいエントロピ・インデックス５が得られ、
残りの第２の構成のエントロピ・インデックスは４であ
る。５および４のエントロピ・インデックスを有する構
成が、よりよい選択肢である。したがって、一実施形態
では、分割の種類が重要である。
【０１４１】図３７に示された例では、サブシステム２
３が、追加リソースを必要としている。サブシステム２
１をチャネル２から除去し（図３８）、サブシステム２
３にチャネル２のすべてのリソースを与えることがで
き、また、サブシステム２５をチャネル４から除去し
（図３９）、サブシステム２３にチャネル４のすべての
リソースを与えることができる。
３が、追加リソースを必要としている。サブシステム２
１をチャネル２から除去し（図３８）、サブシステム２
３にチャネル２のすべてのリソースを与えることがで
き、また、サブシステム２５をチャネル４から除去し
（図３９）、サブシステム２３にチャネル４のすべての
リソースを与えることができる。
【０１４２】サブシステム２１をチャネル２から除去す
る場合、結果のエントロピ・インデックスは７であり、
結果の第２の構成のエントロピ・インデックスは２であ
る。サブシステム２５をチャネル４から除去する場合、
結果のエントロピ・インデックスは６であり、残りの第
２の構成は３である。一実施形態では、分割が均等によ
り近いので、第２の選択肢がより良いと思われる。
る場合、結果のエントロピ・インデックスは７であり、
結果の第２の構成のエントロピ・インデックスは２であ
る。サブシステム２５をチャネル４から除去する場合、
結果のエントロピ・インデックスは６であり、残りの第
２の構成は３である。一実施形態では、分割が均等によ
り近いので、第２の選択肢がより良いと思われる。
【０１４３】どのオプションが半分により近い（すなわ
ち「均等」）かを計算するために、新しいエントロピ・
インデックスと結果の第２の構成のエントロピ・インデ
ックスとの間で、チャネルおよびサブシステムの数の差
を判定する。この例では、第１の選択肢は、７および２
のエントロピ・インデックスがもたらされるので、差は
５である（すなわち、対称インデックス）。第２の選択
肢は、６および３のエントロピ・インデックスをもたら
すので、差は３である。より少ない差を有する選択肢
が、この実施形態では最良の選択肢である。
ち「均等」）かを計算するために、新しいエントロピ・
インデックスと結果の第２の構成のエントロピ・インデ
ックスとの間で、チャネルおよびサブシステムの数の差
を判定する。この例では、第１の選択肢は、７および２
のエントロピ・インデックスがもたらされるので、差は
５である（すなわち、対称インデックス）。第２の選択
肢は、６および３のエントロピ・インデックスをもたら
すので、差は３である。より少ない差を有する選択肢
が、この実施形態では最良の選択肢である。
【０１４４】結論を出すと、一実施形態では、サブシス
テムを目標入出力速度に近づけないオプションが、排除
される。さらに、エントロピ・インデックスが、結果の
構成で相互接続されているチャネルおよびサブシステム
の総数を加算することによって計算される。エントロピ
・インデックスが変化しない場合には、その変更は対称
である。最低のエントロピ・インデックスを有する構成
が、通常は選択される。より高いエントロピ・インデッ
クスを有する構成を選択することを意味する場合であっ
ても、８つを超えるチャネルを有する構成を選択するこ
とは回避されたい。代替案がない場合には、８つを超え
るチャネルを有する構成を選択し、うまくいけば、次の
インターバルにこの構成が分割されることになる。
テムを目標入出力速度に近づけないオプションが、排除
される。さらに、エントロピ・インデックスが、結果の
構成で相互接続されているチャネルおよびサブシステム
の総数を加算することによって計算される。エントロピ
・インデックスが変化しない場合には、その変更は対称
である。最低のエントロピ・インデックスを有する構成
が、通常は選択される。より高いエントロピ・インデッ
クスを有する構成を選択することを意味する場合であっ
ても、８つを超えるチャネルを有する構成を選択するこ
とは回避されたい。代替案がない場合には、８つを超え
るチャネルを有する構成を選択し、うまくいけば、次の
インターバルにこの構成が分割されることになる。
【０１４５】上記の実施形態の変形形態を、入出力構成
に関連して説明してきたが、本発明の機能は、記憶域ネ
ットワークならびに他のネットワークなど、他のネット
ワークに同等に適用可能である。
に関連して説明してきたが、本発明の機能は、記憶域ネ
ットワークならびに他のネットワークなど、他のネット
ワークに同等に適用可能である。
【０１４６】上で説明したのは、コンピュータ環境のリ
ソースを管理するためのさまざまな機構である。本発明
の一態様では、物理共用可能リソースが、コンピュータ
環境の論理区画にまたがって管理される。さらに、一実
施形態では、論理区画をグループ化して、たとえば優先
順位に基づくリソース割振りを介する、リソース共用が
可能になる。このリソース共用には、たとえば、ＬＰＡ
ＲにまたがるＣＰＵリソースの動的管理、ＬＰＡＲにま
たがる動的ＣＨＰＩＤ管理、チャネル・サブシステム内
の入出力優先順位キューイング、およびＬＰＡＲにまた
がるメモリの動的管理が含まれる。
ソースを管理するためのさまざまな機構である。本発明
の一態様では、物理共用可能リソースが、コンピュータ
環境の論理区画にまたがって管理される。さらに、一実
施形態では、論理区画をグループ化して、たとえば優先
順位に基づくリソース割振りを介する、リソース共用が
可能になる。このリソース共用には、たとえば、ＬＰＡ
ＲにまたがるＣＰＵリソースの動的管理、ＬＰＡＲにま
たがる動的ＣＨＰＩＤ管理、チャネル・サブシステム内
の入出力優先順位キューイング、およびＬＰＡＲにまた
がるメモリの動的管理が含まれる。
【０１４７】一例では、システムのワークロード・マネ
ージャが、少なくとも部分的にこの管理の責任を負う。
共用可能リソースは、アプリケーションのサブシステム
にとって透過的なワークロード・マネージャ指示の下
で、ＬＰＡＲにまたがって動的に再分配される。リソー
スは、モニタリング活動および顧客の目標に基づいて、
必要な区画に供給される。さらに、たとえばＷＬＭ、シ
スプレックス、およびＰＲ／ＳＭ統合を介する、ワーク
ロード目標による物理リソースの動的調整は、並列シス
プレックス・データ共用を必要とせずに実行される。
ージャが、少なくとも部分的にこの管理の責任を負う。
共用可能リソースは、アプリケーションのサブシステム
にとって透過的なワークロード・マネージャ指示の下
で、ＬＰＡＲにまたがって動的に再分配される。リソー
スは、モニタリング活動および顧客の目標に基づいて、
必要な区画に供給される。さらに、たとえばＷＬＭ、シ
スプレックス、およびＰＲ／ＳＭ統合を介する、ワーク
ロード目標による物理リソースの動的調整は、並列シス
プレックス・データ共用を必要とせずに実行される。
【０１４８】上で説明した実施形態では、さまざまなコ
ンピュータ環境およびシステムを説明した。これらは、
例にすぎず、本発明のさまざまな態様を制限する目的の
ものではない。さらに、本発明のさまざまな態様を、論
理区画に関連して説明した。論理区画の使用は、一例に
すぎない。本発明の諸態様は、他のタイプの分割ならび
に分割されないシステムに適用される。したがって、こ
れらも、本発明の範囲内と見なされる。
ンピュータ環境およびシステムを説明した。これらは、
例にすぎず、本発明のさまざまな態様を制限する目的の
ものではない。さらに、本発明のさまざまな態様を、論
理区画に関連して説明した。論理区画の使用は、一例に
すぎない。本発明の諸態様は、他のタイプの分割ならび
に分割されないシステムに適用される。したがって、こ
れらも、本発明の範囲内と見なされる。
【０１４９】本発明は、たとえばコンピュータ使用可能
媒体を有する、製造品（たとえば、１つまたは複数のコ
ンピュータ・プログラム製品）に含めることができる。
この媒体は、その中に、たとえば、本発明の機能を提供
し、容易にするためのコンピュータ可読プログラム・コ
ード手段を実施される。製造品は、コンピュータ・シス
テムの一部として含めるか、別々に販売することができ
る。
媒体を有する、製造品（たとえば、１つまたは複数のコ
ンピュータ・プログラム製品）に含めることができる。
この媒体は、その中に、たとえば、本発明の機能を提供
し、容易にするためのコンピュータ可読プログラム・コ
ード手段を実施される。製造品は、コンピュータ・シス
テムの一部として含めるか、別々に販売することができ
る。
【０１５０】さらに、本発明の機能を実行するために計
算機によって実行可能な命令の少なくとも１つのプログ
ラムを具体的に実施する、計算機によって読取可能な少
なくとも１つのプログラム記憶装置を提供することがで
きる。
算機によって実行可能な命令の少なくとも１つのプログ
ラムを具体的に実施する、計算機によって読取可能な少
なくとも１つのプログラム記憶装置を提供することがで
きる。
【０１５１】本明細書で示した流れ図は、例示にすぎな
い。本発明の主旨から逸脱しない、これらの図または本
明細書に記載のステップ（または動作）に対する多数の
変形形態がありえる。たとえば、ステップを異なる順序
で実行することができ、ステップを追加、削除、または
変更することができる。これらの変形形態のすべてが、
請求される発明の一部とみなされる。
い。本発明の主旨から逸脱しない、これらの図または本
明細書に記載のステップ（または動作）に対する多数の
変形形態がありえる。たとえば、ステップを異なる順序
で実行することができ、ステップを追加、削除、または
変更することができる。これらの変形形態のすべてが、
請求される発明の一部とみなされる。
【０１５２】本明細書で好ましい実施形態を図示し、説
明してきたが、さまざまな変更、追加、置換、および類
似行為を、本発明の主旨から逸脱せずに行うことがで
き、したがって、これらが、請求項で定義される本発明
の範囲内であると見なされることを、当業者は諒解する
であろう。
明してきたが、さまざまな変更、追加、置換、および類
似行為を、本発明の主旨から逸脱せずに行うことがで
き、したがって、これらが、請求項で定義される本発明
の範囲内であると見なされることを、当業者は諒解する
であろう。
【０１５３】まとめとして、本発明の構成に関して以下
の事項を開示する。
の事項を開示する。
【０１５４】（１）コンピュータ環境内の中央処理装置
（ＣＰＵ）リソースを管理する方法であって、前記コン
ピュータ環境の区画へのＣＰＵリソースの割振りを調整
しなければならないことを判定するステップと、前記区
画および前記コンピュータ環境の別の区画にまたがって
前記割振りを動的に調整するステップとを含む方法。 （２）前記動的調整が、少なくとも前記区画のワークロ
ード目標に応答する、上記（１）に記載の方法。 （３）前記動的調整が、前記区画に割り当てられた第１
ＣＰＵプロセッサ重みと、前記別の区画に割り当てられ
た第２ＣＰＵプロセッサ重みとを変更するステップを含
む、上記（１）に記載の方法。 （４）前記変更が、前記第１ＣＰＵプロセッサ重みを増
やすステップと、前記第２ＣＰＵプロセッサ重みを減ら
すステップとを含む、上記（３）に記載の方法。 （５）前記第１ＣＰＵプロセッサ重みが、前記第２ＣＰ
Ｕプロセッサ重みの減少と等しい量だけ増やされ、前記
第１ＣＰＵプロセッサ重みと前記第２ＣＰＵプロセッサ
重みの合計が一定のままになる、上記（４）に記載の方
法。 （６）前記変更が、前記第１ＣＰＵプロセッサ重みを減
らすステップと、前記第２ＣＰＵプロセッサ重みを増や
すステップとを含む、上記（３）に記載の方法。 （７）前記動的調整が、前記コンピュータ環境の複数の
区画にまたがる、上記（１）に記載の方法。 （８）前記区画および前記別の区画が、区画のグループ
内にある、上記（１）に記載の方法。 （９）前記区画が、１つまたは複数のサービス・クラス
の作業を含み、前記判定が、前記区画に関連するプロセ
ッサ重みを増やすことの、前記１つまたは複数のサービ
ス・クラスの選択されたサービス・クラスに対する影響
を見積もるステップと、前記別の区画のプロセッサ重み
を減らすことの、前記別の区画の１つまたは複数のサー
ビス・クラスに対する影響を見積もるステップと、前記
選択されたサービス・クラスに対する利益が、前記別の
区画の作業に対する悪影響に優越するかどうかを判定す
るステップとを含み、前記調整が、前記利益が前記悪影
響に優越する時に行われる、上記（１）に記載の方法。 （１０）前記別の区画を選択するステップをさらに含
む、上記（１）に記載の方法。 （１１）前記選択が、前記別の区画内で実行される作業
の重要性に基づく、上記（１０）に記載の方法。 （１２）コンピュータ環境内の中央処理装置（ＣＰＵ）
リソースを管理するシステムであって、前記コンピュー
タ環境の区画へのＣＰＵリソースの割振りを調整しなけ
ればならないことを判定する手段と、前記区画および前
記コンピュータ環境の別の区画にまたがって前記割振り
を動的に調整する手段とを含むシステム。 （１３）前記動的調整手段が、少なくとも前記区画のワ
ークロード目標に応答する、上記（１２）に記載のシス
テム。 （１４）前記動的調整手段が、前記区画に割り当てられ
た第１ＣＰＵプロセッサ重みと、前記別の区画に割り当
てられた第２ＣＰＵプロセッサ重みとを変更する手段を
含む、上記（１２）に記載のシステム。 （１５）前記変更手段が、前記第１ＣＰＵプロセッサ重
みを増やす手段と、前記第２ＣＰＵプロセッサ重みを減
らす手段とを含む、上記（１４）に記載のシステム。 （１６）前記第１ＣＰＵプロセッサ重みが、前記第２Ｃ
ＰＵプロセッサ重みの減少と等しい量だけ増やされ、前
記第１ＣＰＵプロセッサ重みと前記第２ＣＰＵプロセッ
サ重みの合計が一定のままになる、上記（１５）に記載
のシステム。 （１７）前記変更手段が、前記第１ＣＰＵプロセッサ重
みを減らす手段と、前記第２ＣＰＵプロセッサ重みを増
やす手段とを含む、上記（１４）に記載のシステム。 （１８）前記調整が、前記コンピュータ環境の複数の区
画にまたがる、上記（１２）に記載のシステム。 （１９）前記区画および前記別の区画が、区画のグルー
プ内にある、上記（１２）に記載のシステム。 （２０）前記区画が、１つまたは複数のサービス・クラ
スの作業を含み、前記判定手段が、前記区画に関連する
プロセッサ重みを増やすことの、前記１つまたは複数の
サービス・クラスの選択されたサービス・クラスに対す
る影響を見積もる手段と、前記別の区画のプロセッサ重
みを減らすことの、前記別の区画の１つまたは複数のサ
ービス・クラスに対する影響を見積もる手段と、前記選
択されたサービス・クラスに対する利益が、前記別の区
画の作業に対する悪影響に優越するかどうかを判定する
手段とを含み、前記調整が、前記利益が前記悪影響に優
越する時に行われる、上記（１２）に記載のシステム。 （２１）前記別の区画を選択する手段をさらに含む、上
記（１２）に記載のシステム。 （２２）前記選択手段が、前記別の区画内で実行される
作業の重要性に基づく、上記（２１）に記載のシステ
ム。 （２３）コンピュータ環境内の中央処理装置（ＣＰＵ）
リソースを管理するシステムであって、前記コンピュー
タ環境の区画へのＣＰＵリソースの割振りを調整しなけ
ればならないことを判定するように適合されたプロセッ
サと、前記区画および前記コンピュータ環境の別の区画
にまたがって前記割振りを動的に調整するように適合さ
れたプロセッサとを含むシステム。 （２４）上記（１）ないし上記（１１）のいずれかに記
載の方法を実行するためのプログラムを記憶したプログ
ラム記憶装置。
（ＣＰＵ）リソースを管理する方法であって、前記コン
ピュータ環境の区画へのＣＰＵリソースの割振りを調整
しなければならないことを判定するステップと、前記区
画および前記コンピュータ環境の別の区画にまたがって
前記割振りを動的に調整するステップとを含む方法。 （２）前記動的調整が、少なくとも前記区画のワークロ
ード目標に応答する、上記（１）に記載の方法。 （３）前記動的調整が、前記区画に割り当てられた第１
ＣＰＵプロセッサ重みと、前記別の区画に割り当てられ
た第２ＣＰＵプロセッサ重みとを変更するステップを含
む、上記（１）に記載の方法。 （４）前記変更が、前記第１ＣＰＵプロセッサ重みを増
やすステップと、前記第２ＣＰＵプロセッサ重みを減ら
すステップとを含む、上記（３）に記載の方法。 （５）前記第１ＣＰＵプロセッサ重みが、前記第２ＣＰ
Ｕプロセッサ重みの減少と等しい量だけ増やされ、前記
第１ＣＰＵプロセッサ重みと前記第２ＣＰＵプロセッサ
重みの合計が一定のままになる、上記（４）に記載の方
法。 （６）前記変更が、前記第１ＣＰＵプロセッサ重みを減
らすステップと、前記第２ＣＰＵプロセッサ重みを増や
すステップとを含む、上記（３）に記載の方法。 （７）前記動的調整が、前記コンピュータ環境の複数の
区画にまたがる、上記（１）に記載の方法。 （８）前記区画および前記別の区画が、区画のグループ
内にある、上記（１）に記載の方法。 （９）前記区画が、１つまたは複数のサービス・クラス
の作業を含み、前記判定が、前記区画に関連するプロセ
ッサ重みを増やすことの、前記１つまたは複数のサービ
ス・クラスの選択されたサービス・クラスに対する影響
を見積もるステップと、前記別の区画のプロセッサ重み
を減らすことの、前記別の区画の１つまたは複数のサー
ビス・クラスに対する影響を見積もるステップと、前記
選択されたサービス・クラスに対する利益が、前記別の
区画の作業に対する悪影響に優越するかどうかを判定す
るステップとを含み、前記調整が、前記利益が前記悪影
響に優越する時に行われる、上記（１）に記載の方法。 （１０）前記別の区画を選択するステップをさらに含
む、上記（１）に記載の方法。 （１１）前記選択が、前記別の区画内で実行される作業
の重要性に基づく、上記（１０）に記載の方法。 （１２）コンピュータ環境内の中央処理装置（ＣＰＵ）
リソースを管理するシステムであって、前記コンピュー
タ環境の区画へのＣＰＵリソースの割振りを調整しなけ
ればならないことを判定する手段と、前記区画および前
記コンピュータ環境の別の区画にまたがって前記割振り
を動的に調整する手段とを含むシステム。 （１３）前記動的調整手段が、少なくとも前記区画のワ
ークロード目標に応答する、上記（１２）に記載のシス
テム。 （１４）前記動的調整手段が、前記区画に割り当てられ
た第１ＣＰＵプロセッサ重みと、前記別の区画に割り当
てられた第２ＣＰＵプロセッサ重みとを変更する手段を
含む、上記（１２）に記載のシステム。 （１５）前記変更手段が、前記第１ＣＰＵプロセッサ重
みを増やす手段と、前記第２ＣＰＵプロセッサ重みを減
らす手段とを含む、上記（１４）に記載のシステム。 （１６）前記第１ＣＰＵプロセッサ重みが、前記第２Ｃ
ＰＵプロセッサ重みの減少と等しい量だけ増やされ、前
記第１ＣＰＵプロセッサ重みと前記第２ＣＰＵプロセッ
サ重みの合計が一定のままになる、上記（１５）に記載
のシステム。 （１７）前記変更手段が、前記第１ＣＰＵプロセッサ重
みを減らす手段と、前記第２ＣＰＵプロセッサ重みを増
やす手段とを含む、上記（１４）に記載のシステム。 （１８）前記調整が、前記コンピュータ環境の複数の区
画にまたがる、上記（１２）に記載のシステム。 （１９）前記区画および前記別の区画が、区画のグルー
プ内にある、上記（１２）に記載のシステム。 （２０）前記区画が、１つまたは複数のサービス・クラ
スの作業を含み、前記判定手段が、前記区画に関連する
プロセッサ重みを増やすことの、前記１つまたは複数の
サービス・クラスの選択されたサービス・クラスに対す
る影響を見積もる手段と、前記別の区画のプロセッサ重
みを減らすことの、前記別の区画の１つまたは複数のサ
ービス・クラスに対する影響を見積もる手段と、前記選
択されたサービス・クラスに対する利益が、前記別の区
画の作業に対する悪影響に優越するかどうかを判定する
手段とを含み、前記調整が、前記利益が前記悪影響に優
越する時に行われる、上記（１２）に記載のシステム。 （２１）前記別の区画を選択する手段をさらに含む、上
記（１２）に記載のシステム。 （２２）前記選択手段が、前記別の区画内で実行される
作業の重要性に基づく、上記（２１）に記載のシステ
ム。 （２３）コンピュータ環境内の中央処理装置（ＣＰＵ）
リソースを管理するシステムであって、前記コンピュー
タ環境の区画へのＣＰＵリソースの割振りを調整しなけ
ればならないことを判定するように適合されたプロセッ
サと、前記区画および前記コンピュータ環境の別の区画
にまたがって前記割振りを動的に調整するように適合さ
れたプロセッサとを含むシステム。 （２４）上記（１）ないし上記（１１）のいずれかに記
載の方法を実行するためのプログラムを記憶したプログ
ラム記憶装置。
【図１】本発明の機能を組み込まれ、使用するコンピュ
ータ環境の一例を示す図である。
ータ環境の一例を示す図である。
【図２】本発明の機能を組み込まれ、使用するコンピュ
ータ環境のもう１つの実施形態を示す図である。
ータ環境のもう１つの実施形態を示す図である。
【図３】本発明の機能を組み込まれ、使用するコンピュ
ータ環境の追加構成要素を示す図である。
ータ環境の追加構成要素を示す図である。
【図４】本発明の原理に従って使用される論理区画グル
ープの一例を示す図である。
ープの一例を示す図である。
【図５】本発明の原理による、グループに加入する区画
に関連する論理の一例を示す図である。
に関連する論理の一例を示す図である。
【図６】本発明の原理による、グループに加入する区画
に関連する論理の一例を示す図である。
に関連する論理の一例を示す図である。
【図７】本発明の原理による、グループからの区画の除
去に関連する論理の一実施形態を示す図である。
去に関連する論理の一実施形態を示す図である。
【図８】本発明の原理による、区画のレシーバ・サービ
ス・クラスを助けるための、区画の重みを増やすことが
できるかどうかの判定に関連する論理の一実施形態を示
す図である。
ス・クラスを助けるための、区画の重みを増やすことが
できるかどうかの判定に関連する論理の一実施形態を示
す図である。
【図９】本発明の原理による、論理プロセッサの構成の
動的調整に関連する論理の一実施形態を示す図である。
動的調整に関連する論理の一実施形態を示す図である。
【図１０】本発明の１つまたは複数の機能を組み込ま
れ、使用するチャネル・サブシステムの一実施形態を示
す図である。
れ、使用するチャネル・サブシステムの一実施形態を示
す図である。
【図１１】本発明の原理による、処理される入出力動作
の選択に関連する論理の一実施形態を示す図である。
の選択に関連する論理の一実施形態を示す図である。
【図１２】本発明の原理による、入出力構成を調整しな
ければならないかどうかの判定に関連する論理の一実施
形態を示す図である。
ければならないかどうかの判定に関連する論理の一実施
形態を示す図である。
【図１３】本発明の原理による、図１２のデータ収集に
関連する論理の一実施形態を示す図である。
関連する論理の一実施形態を示す図である。
【図１４】本発明の原理による、図１２の平衡検査に関
連する論理の一実施形態を示す図である。
連する論理の一実施形態を示す図である。
【図１５】本発明の原理による、入出力構成の不平衡の
訂正に関連する論理の一実施形態を示す図である。
訂正に関連する論理の一実施形態を示す図である。
【図１６】本発明の原理による、入出力構成の不平衡の
訂正に関連する論理の一実施形態を示す図である。
訂正に関連する論理の一実施形態を示す図である。
【図１７】本発明の原理による、影響を受けるサブシス
テムの判定に関連する論理の一実施形態を示す図であ
る。
テムの判定に関連する論理の一実施形態を示す図であ
る。
【図１８】本発明の原理に従って使用される、明示的入
出力速度目標の設定に関連する論理の一実施形態を示す
図である。
出力速度目標の設定に関連する論理の一実施形態を示す
図である。
【図１９】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２０】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２１】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２２】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２３】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２４】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２５】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２６】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２７】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２８】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図２９】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３０】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３１】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３２】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３３】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３４】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３５】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３６】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３７】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３８】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
【図３９】本発明の原理による、エントロピ判定に使用
される入出力構成の一例を示す図である。
される入出力構成の一例を示す図である。
８００ 中央処理装置 ８０２ チャネル・サブシステム ８０４ 付加された装置 ８０６ 入出力プロセッサ作業キュー ８０８ 入出力プロセッサ ８１０ チャネル・プロセッサ作業キュー ８１２ チャネル・プロセッサ ８１４ 制御装置作業キュー
───────────────────────────────────────────────────── フロントページの続き (72)発明者 キャサリン・ケイ・イーラート アメリカ合衆国12590 ニューヨーク州ワ ッピンジャーズ・フォールズ シャーウッ ド・ハイツ・ドライブ 34 (72)発明者 ジェフリー・ピー・クバラ アメリカ合衆国12570 ニューヨーク州ポ クエグ モーガン・レーン 10 (72)発明者 ジェフリー・エム・ニック アメリカ合衆国12493 ニューヨーク州ウ ェスト・パーク ルート９ダブリュ 1957 (72)発明者 ピーター・ビー・ヨコム アメリカ合衆国12590 ニューヨーク州ワ ッピンジャーズ・フォールズ ワイルドウ ッド・マナー 17ビー
Claims (24)
- 【請求項１】コンピュータ環境内の中央処理装置（ＣＰ
Ｕ）リソースを管理する方法であって、 前記コンピュータ環境の区画へのＣＰＵリソースの割振
りを調整しなければならないことを判定するステップ
と、 前記区画および前記コンピュータ環境の別の区画にまた
がって前記割振りを動的に調整するステップとを含む方
法。 - 【請求項２】前記動的調整が、少なくとも前記区画のワ
ークロード目標に応答する、請求項１に記載の方法。 - 【請求項３】前記動的調整が、前記区画に割り当てられ
た第１ＣＰＵプロセッサ重みと、前記別の区画に割り当
てられた第２ＣＰＵプロセッサ重みとを変更するステッ
プを含む、請求項１に記載の方法。 - 【請求項４】前記変更が、 前記第１ＣＰＵプロセッサ重みを増やすステップと、 前記第２ＣＰＵプロセッサ重みを減らすステップとを含
む、請求項３に記載の方法。 - 【請求項５】前記第１ＣＰＵプロセッサ重みが、前記第
２ＣＰＵプロセッサ重みの減少と等しい量だけ増やさ
れ、前記第１ＣＰＵプロセッサ重みと前記第２ＣＰＵプ
ロセッサ重みの合計が一定のままになる、請求項４に記
載の方法。 - 【請求項６】前記変更が、 前記第１ＣＰＵプロセッサ重みを減らすステップと、 前記第２ＣＰＵプロセッサ重みを増やすステップとを含
む、請求項３に記載の方法。 - 【請求項７】前記動的調整が、前記コンピュータ環境の
複数の区画にまたがる、請求項１に記載の方法。 - 【請求項８】前記区画および前記別の区画が、区画のグ
ループ内にある、請求項１に記載の方法。 - 【請求項９】前記区画が、１つまたは複数のサービス・
クラスの作業を含み、前記判定が、 前記区画に関連するプロセッサ重みを増やすことの、前
記１つまたは複数のサービス・クラスの選択されたサー
ビス・クラスに対する影響を見積もるステップと、 前記別の区画のプロセッサ重みを減らすことの、前記別
の区画の１つまたは複数のサービス・クラスに対する影
響を見積もるステップと、 前記選択されたサービス・クラスに対する利益が、前記
別の区画の作業に対する悪影響に優越するかどうかを判
定するステップとを含み、前記調整が、前記利益が前記
悪影響に優越する時に行われる、請求項１に記載の方
法。 - 【請求項１０】前記別の区画を選択するステップをさら
に含む、請求項１に記載の方法。 - 【請求項１１】前記選択が、前記別の区画内で実行され
る作業の重要性に基づく、請求項１０に記載の方法。 - 【請求項１２】コンピュータ環境内の中央処理装置（Ｃ
ＰＵ）リソースを管理するシステムであって、 前記コンピュータ環境の区画へのＣＰＵリソースの割振
りを調整しなければならないことを判定する手段と、 前記区画および前記コンピュータ環境の別の区画にまた
がって前記割振りを動的に調整する手段とを含むシステ
ム。 - 【請求項１３】前記動的調整手段が、少なくとも前記区
画のワークロード目標に応答する、請求項１２に記載の
システム。 - 【請求項１４】前記動的調整手段が、前記区画に割り当
てられた第１ＣＰＵプロセッサ重みと、前記別の区画に
割り当てられた第２ＣＰＵプロセッサ重みとを変更する
手段を含む、請求項１２に記載のシステム。 - 【請求項１５】前記変更手段が、 前記第１ＣＰＵプロセッサ重みを増やす手段と、 前記第２ＣＰＵプロセッサ重みを減らす手段とを含む、
請求項１４に記載のシステム。 - 【請求項１６】前記第１ＣＰＵプロセッサ重みが、前記
第２ＣＰＵプロセッサ重みの減少と等しい量だけ増やさ
れ、前記第１ＣＰＵプロセッサ重みと前記第２ＣＰＵプ
ロセッサ重みの合計が一定のままになる、請求項１５に
記載のシステム。 - 【請求項１７】前記変更手段が、 前記第１ＣＰＵプロセッサ重みを減らす手段と、 前記第２ＣＰＵプロセッサ重みを増やす手段とを含む、
請求項１４に記載のシステム。 - 【請求項１８】前記調整が、前記コンピュータ環境の複
数の区画にまたがる、請求項１２に記載のシステム。 - 【請求項１９】前記区画および前記別の区画が、区画の
グループ内にある、請求項１２に記載のシステム。 - 【請求項２０】前記区画が、１つまたは複数のサービス
・クラスの作業を含み、前記判定手段が、 前記区画に関連するプロセッサ重みを増やすことの、前
記１つまたは複数のサービス・クラスの選択されたサー
ビス・クラスに対する影響を見積もる手段と、 前記別の区画のプロセッサ重みを減らすことの、前記別
の区画の１つまたは複数のサービス・クラスに対する影
響を見積もる手段と、 前記選択されたサービス・クラスに対する利益が、前記
別の区画の作業に対する悪影響に優越するかどうかを判
定する手段とを含み、前記調整が、前記利益が前記悪影
響に優越する時に行われる、請求項１２に記載のシステ
ム。 - 【請求項２１】前記別の区画を選択する手段をさらに含
む、請求項１２に記載のシステム。 - 【請求項２２】前記選択手段が、前記別の区画内で実行
される作業の重要性に基づく、請求項２１に記載のシス
テム。 - 【請求項２３】コンピュータ環境内の中央処理装置（Ｃ
ＰＵ）リソースを管理するシステムであって、 前記コンピュータ環境の区画へのＣＰＵリソースの割振
りを調整しなければならないことを判定するように適合
されたプロセッサと、 前記区画および前記コンピュータ環境の別の区画にまた
がって前記割振りを動的に調整するように適合されたプ
ロセッサとを含むシステム。 - 【請求項２４】請求項１ないし請求項１１のいずれかに
記載の方法を実行するためのプログラムを記憶したプロ
グラム記憶装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/407212 | 1999-09-28 | ||
| US09/407,212 US6587938B1 (en) | 1999-09-28 | 1999-09-28 | Method, system and program products for managing central processing unit resources of a computing environment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001142858A true JP2001142858A (ja) | 2001-05-25 |
| JP3672236B2 JP3672236B2 (ja) | 2005-07-20 |
Family
ID=23611115
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000290086A Expired - Lifetime JP3672236B2 (ja) | 1999-09-28 | 2000-09-25 | コンピュータ環境の中央処理装置を管理する方法、システム、およびプログラム製品 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6587938B1 (ja) |
| JP (1) | JP3672236B2 (ja) |
| KR (1) | KR100420420B1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2022549628A (ja) * | 2019-09-23 | 2022-11-28 | グーグル エルエルシー | コンピュータシステムリソースの任意のグループ化 |
Families Citing this family (99)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6986137B1 (en) * | 1999-09-28 | 2006-01-10 | International Business Machines Corporation | Method, system and program products for managing logical processors of a computing environment |
| JP2001109638A (ja) * | 1999-10-06 | 2001-04-20 | Nec Corp | 推定伸長率に基づくトランザクション負荷分散方法及び方式並びにコンピュータ可読記録媒体 |
| US6938256B2 (en) | 2000-01-18 | 2005-08-30 | Galactic Computing Corporation | System for balance distribution of requests across multiple servers using dynamic metrics |
| US7140020B2 (en) * | 2000-01-28 | 2006-11-21 | Hewlett-Packard Development Company, L.P. | Dynamic management of virtual partition computer workloads through service level optimization |
| US6928646B1 (en) * | 2000-02-02 | 2005-08-09 | Sony Corporation | System and method for efficiently performing scheduling operations in an electronic device |
| US8538843B2 (en) | 2000-07-17 | 2013-09-17 | Galactic Computing Corporation Bvi/Bc | Method and system for operating an E-commerce service provider |
| US6816905B1 (en) * | 2000-11-10 | 2004-11-09 | Galactic Computing Corporation Bvi/Bc | Method and system for providing dynamic hosted service management across disparate accounts/sites |
| JP2002041304A (ja) * | 2000-07-28 | 2002-02-08 | Hitachi Ltd | 論理区画の予備リソース自動付与方法及び論理区画式計算機システム |
| US6912493B1 (en) * | 2000-09-29 | 2005-06-28 | International Business Machines Corporation | Technique for configuring processors in system with logical partitions |
| JP2002202959A (ja) * | 2000-12-28 | 2002-07-19 | Hitachi Ltd | 動的な資源分配をする仮想計算機システム |
| US6957435B2 (en) * | 2001-04-19 | 2005-10-18 | International Business Machines Corporation | Method and apparatus for allocating processor resources in a logically partitioned computer system |
| US7170862B1 (en) * | 2001-07-31 | 2007-01-30 | Cisco Technology, Inc. | Partitioning a network element into multiple virtual network elements |
| US7428485B2 (en) * | 2001-08-24 | 2008-09-23 | International Business Machines Corporation | System for yielding to a processor |
| US7251814B2 (en) * | 2001-08-24 | 2007-07-31 | International Business Machines Corporation | Yield on multithreaded processors |
| US20030061262A1 (en) * | 2001-09-25 | 2003-03-27 | Hahn Stephen C. | Method and apparatus for partitioning resources within a computer system |
| JP4018900B2 (ja) * | 2001-11-22 | 2007-12-05 | 株式会社日立製作所 | 仮想計算機システム及びプログラム |
| JP4119162B2 (ja) * | 2002-05-15 | 2008-07-16 | 株式会社日立製作所 | 多重化計算機システム、論理計算機の割当方法および論理計算機の割当プログラム |
| US20030220960A1 (en) * | 2002-05-21 | 2003-11-27 | Demoff Jeff S. | System and method for processing data over a distributed network |
| US7412703B2 (en) * | 2002-09-19 | 2008-08-12 | Sedna Patent Services, Llc | Low cost, highly accurate video server bit-rate compensation |
| US7133915B2 (en) * | 2002-10-10 | 2006-11-07 | International Business Machines Corporation | Apparatus and method for offloading and sharing CPU and RAM utilization in a network of machines |
| JP4119239B2 (ja) * | 2002-12-20 | 2008-07-16 | 株式会社日立製作所 | 計算機資源割当方法、それを実行するための資源管理サーバおよび計算機システム |
| US7290260B2 (en) * | 2003-02-20 | 2007-10-30 | International Business Machines Corporation | Dynamic processor redistribution between partitions in a computing system |
| US7191329B2 (en) * | 2003-03-05 | 2007-03-13 | Sun Microsystems, Inc. | Automated resource management using perceptron prediction |
| US7000051B2 (en) * | 2003-03-31 | 2006-02-14 | International Business Machines Corporation | Apparatus and method for virtualizing interrupts in a logically partitioned computer system |
| US7430742B2 (en) * | 2003-04-23 | 2008-09-30 | Micron Technology, Inc. | Method for load balancing a line of parallel processing elements |
| US7437729B2 (en) * | 2003-04-23 | 2008-10-14 | Micron Technology, Inc. | Method for load balancing a loop of parallel processing elements |
| US7448038B2 (en) * | 2003-04-23 | 2008-11-04 | Micron Technology, Inc. | Method for using filtering to load balance a loop of parallel processing elements |
| US7437726B2 (en) * | 2003-04-23 | 2008-10-14 | Micron Technology, Inc. | Method for rounding values for a plurality of parallel processing elements |
| US7472392B2 (en) * | 2003-04-23 | 2008-12-30 | Micron Technology, Inc. | Method for load balancing an n-dimensional array of parallel processing elements |
| US7028157B2 (en) * | 2003-04-24 | 2006-04-11 | International Business Machines Corporation | On-demand allocation of data structures to partitions |
| US7281075B2 (en) * | 2003-04-24 | 2007-10-09 | International Business Machines Corporation | Virtualization of a global interrupt queue |
| US20040226015A1 (en) * | 2003-05-09 | 2004-11-11 | Leonard Ozgur C. | Multi-level computing resource scheduling control for operating system partitions |
| US20050060704A1 (en) * | 2003-09-17 | 2005-03-17 | International Business Machines Corporation | Managing processing within computing environments including initiation of virtual machines |
| US7234032B2 (en) * | 2003-11-20 | 2007-06-19 | International Business Machines Corporation | Computerized system, method and program product for managing an enterprise storage system |
| US7464378B1 (en) * | 2003-12-04 | 2008-12-09 | Symantec Operating Corporation | System and method for allowing multiple sub-clusters to survive a cluster partition |
| US20050155032A1 (en) * | 2004-01-12 | 2005-07-14 | Schantz John L. | Dynamic load balancing |
| US7975270B2 (en) * | 2004-03-10 | 2011-07-05 | International Business Machines Corporation | Facilitating allocation of resources in a heterogeneous computing environment |
| US7890629B2 (en) | 2004-03-13 | 2011-02-15 | Adaptive Computing Enterprises, Inc. | System and method of providing reservation masks within a compute environment |
| WO2005089246A2 (en) * | 2004-03-13 | 2005-09-29 | Cluster Resources, Inc. | System and method for providiing advanced reservations in a compute environment |
| US7971204B2 (en) * | 2004-03-13 | 2011-06-28 | Adaptive Computing Enterprises, Inc. | System and method of co-allocating a reservation spanning different compute resources types |
| US7490325B2 (en) * | 2004-03-13 | 2009-02-10 | Cluster Resources, Inc. | System and method for providing intelligent pre-staging of data in a compute environment |
| US8782654B2 (en) | 2004-03-13 | 2014-07-15 | Adaptive Computing Enterprises, Inc. | Co-allocating a reservation spanning different compute resources types |
| US20050216716A1 (en) * | 2004-03-29 | 2005-09-29 | Hoffman Philip M | System and method for licensing and distribution of I/O in partitioned computer systems |
| US7814491B1 (en) * | 2004-04-14 | 2010-10-12 | Oracle America, Inc. | Method and apparatus for managing system resources using a container model |
| US7530071B2 (en) * | 2004-04-22 | 2009-05-05 | International Business Machines Corporation | Facilitating access to input/output resources via an I/O partition shared by multiple consumer partitions |
| US20070266388A1 (en) | 2004-06-18 | 2007-11-15 | Cluster Resources, Inc. | System and method for providing advanced reservations in a compute environment |
| US7277985B2 (en) | 2004-07-13 | 2007-10-02 | International Business Machines Corporation | Method, system and program product for storing downloadable content on a plurality of enterprise storage system (ESS) cells |
| US8176490B1 (en) | 2004-08-20 | 2012-05-08 | Adaptive Computing Enterprises, Inc. | System and method of interfacing a workload manager and scheduler with an identity manager |
| US7752623B1 (en) * | 2004-09-16 | 2010-07-06 | Hewlett-Packard Development Company, L.P. | System and method for allocating resources by examining a system characteristic |
| US8271980B2 (en) | 2004-11-08 | 2012-09-18 | Adaptive Computing Enterprises, Inc. | System and method of providing system jobs within a compute environment |
| US20060107000A1 (en) * | 2004-11-15 | 2006-05-18 | Lee Jung-Ik | Peer-based partitioning method for system resource sharing |
| US8286157B2 (en) * | 2005-02-28 | 2012-10-09 | International Business Machines Corporation | Method, system and program product for managing applications in a shared computer infrastructure |
| US9075657B2 (en) | 2005-04-07 | 2015-07-07 | Adaptive Computing Enterprises, Inc. | On-demand access to compute resources |
| US7996455B2 (en) | 2005-06-17 | 2011-08-09 | Adaptive Computing Enterprises, Inc. | System and method for providing dynamic roll-back reservations in time |
| US8863143B2 (en) | 2006-03-16 | 2014-10-14 | Adaptive Computing Enterprises, Inc. | System and method for managing a hybrid compute environment |
| US8930536B2 (en) * | 2005-03-16 | 2015-01-06 | Adaptive Computing Enterprises, Inc. | Virtual private cluster |
| US9231886B2 (en) | 2005-03-16 | 2016-01-05 | Adaptive Computing Enterprises, Inc. | Simple integration of an on-demand compute environment |
| US9225663B2 (en) | 2005-03-16 | 2015-12-29 | Adaptive Computing Enterprises, Inc. | System and method providing a virtual private cluster |
| US7734895B1 (en) | 2005-04-28 | 2010-06-08 | Massachusetts Institute Of Technology | Configuring sets of processor cores for processing instructions |
| US7743379B2 (en) * | 2005-07-14 | 2010-06-22 | International Business Machines Corporation | Variable resource sets |
| US7478272B2 (en) * | 2005-09-30 | 2009-01-13 | International Business Machines Corporation | Replacing a failing physical processor |
| US7945913B2 (en) * | 2006-01-19 | 2011-05-17 | International Business Machines Corporation | Method, system and computer program product for optimizing allocation of resources on partitions of a data processing system |
| US7904547B2 (en) | 2006-02-21 | 2011-03-08 | International Business Machines Corporation | Method, system, and program product for optimizing monitoring and discovery services for a grid computing environment |
| US8117611B2 (en) * | 2006-03-01 | 2012-02-14 | International Business Machines Corporation | Method, system, and program product for deploying a platform dependent application in a grid environment |
| JP4519098B2 (ja) * | 2006-03-30 | 2010-08-04 | 株式会社日立製作所 | 計算機の管理方法、計算機システム、及び管理プログラム |
| US7987464B2 (en) * | 2006-07-25 | 2011-07-26 | International Business Machines Corporation | Logical partitioning and virtualization in a heterogeneous architecture |
| US7844709B2 (en) * | 2006-09-20 | 2010-11-30 | International Business Machines Corporation | Method and apparatus for managing central processing unit resources of a logically partitioned computing environment without shared memory access |
| US7657715B2 (en) * | 2006-10-31 | 2010-02-02 | International Business Machines Corporation | Dynamic operation mode transition of a storage subsystem |
| US8532288B2 (en) * | 2006-12-01 | 2013-09-10 | International Business Machines Corporation | Selectively isolating processor elements into subsets of processor elements |
| JP5079342B2 (ja) * | 2007-01-22 | 2012-11-21 | ルネサスエレクトロニクス株式会社 | マルチプロセッサ装置 |
| US8127295B1 (en) * | 2007-08-03 | 2012-02-28 | Oracle America, Inc. | Scalable resource allocation |
| US20090055831A1 (en) | 2007-08-24 | 2009-02-26 | Bauman Ellen M | Allocating Network Adapter Resources Among Logical Partitions |
| US8041773B2 (en) | 2007-09-24 | 2011-10-18 | The Research Foundation Of State University Of New York | Automatic clustering for self-organizing grids |
| US8352950B2 (en) * | 2008-01-11 | 2013-01-08 | International Business Machines Corporation | Algorithm to share physical processors to maximize processor cache usage and topologies |
| US20090313074A1 (en) * | 2008-06-11 | 2009-12-17 | International Business Machines Corporation | Enhanced viewing/updating of calendar entries based upon relationships between a viewer and a calendar owner and a relative importance value of the calendar entries |
| US9189222B1 (en) | 2008-10-28 | 2015-11-17 | Hewlett-Packard Development Company, L.P. | Updating a computer system |
| JP5507136B2 (ja) * | 2009-07-09 | 2014-05-28 | 株式会社日立製作所 | 管理装置及び方法並びに計算機システム |
| US8250198B2 (en) * | 2009-08-12 | 2012-08-21 | Microsoft Corporation | Capacity planning for data center services |
| US11720290B2 (en) | 2009-10-30 | 2023-08-08 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
| US10877695B2 (en) | 2009-10-30 | 2020-12-29 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
| US8826271B2 (en) * | 2010-04-28 | 2014-09-02 | Cavium, Inc. | Method and apparatus for a virtual system on chip |
| JP5439435B2 (ja) * | 2011-06-14 | 2014-03-12 | 株式会社日立製作所 | 計算機システムおよびその計算機システムにおけるディスク共有方法 |
| US8863141B2 (en) | 2011-12-14 | 2014-10-14 | International Business Machines Corporation | Estimating migration costs for migrating logical partitions within a virtualized computing environment based on a migration cost history |
| US8694995B2 (en) | 2011-12-14 | 2014-04-08 | International Business Machines Corporation | Application initiated negotiations for resources meeting a performance parameter in a virtualized computing environment |
| US9032180B2 (en) | 2013-03-15 | 2015-05-12 | International Business Machines Corporation | Managing CPU resources for high availability micro-partitions |
| US9244825B2 (en) | 2013-03-15 | 2016-01-26 | International Business Machines Corporation | Managing CPU resources for high availability micro-partitions |
| US9158470B2 (en) | 2013-03-15 | 2015-10-13 | International Business Machines Corporation | Managing CPU resources for high availability micro-partitions |
| EP3039544B1 (en) | 2013-10-03 | 2018-12-12 | Huawei Technologies Co., Ltd. | Method and system for assigning a computational block of a software program to cores of a multi-processor system |
| KR101465657B1 (ko) * | 2014-03-10 | 2014-12-10 | 성균관대학교산학협력단 | 가상머신을 위한 협력 스케줄링 방법 |
| US10176021B1 (en) * | 2014-11-21 | 2019-01-08 | Ca, Inc. | System and method for managing actual processing capacity usage on a mainframe computer |
| US9342372B1 (en) | 2015-03-23 | 2016-05-17 | Bmc Software, Inc. | Dynamic workload capping |
| WO2016167807A1 (en) * | 2015-04-17 | 2016-10-20 | Hewlett-Packard Development Company, L.P. | Memory mode categorizations |
| US9680657B2 (en) | 2015-08-31 | 2017-06-13 | Bmc Software, Inc. | Cost optimization in dynamic workload capping |
| US9921880B2 (en) * | 2016-01-28 | 2018-03-20 | Oracle International Corporation | Dynamic performance isolation of competing workloads on CPUs with shared hardware components |
| US10563497B2 (en) * | 2016-02-18 | 2020-02-18 | Halliburton Energy Services | Method and system for smart resource allocation |
| US10133504B2 (en) * | 2016-04-06 | 2018-11-20 | Futurewei Technologies, Inc. | Dynamic partitioning of processing hardware |
| US10235211B2 (en) | 2016-04-22 | 2019-03-19 | Cavium, Llc | Method and apparatus for dynamic virtual system on chip |
| US10956226B2 (en) | 2018-07-19 | 2021-03-23 | Futurewei Technologies, Inc. | Basic runtime environment |
| CN111506433A (zh) * | 2020-04-30 | 2020-08-07 | 中科院计算所西部高等技术研究院 | 具有ooda多分区可替换机制的处理器 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06103092A (ja) * | 1992-09-18 | 1994-04-15 | Hitachi Ltd | 仮想計算機システム |
| JPH07182185A (ja) * | 1993-11-04 | 1995-07-21 | Internatl Business Mach Corp <Ibm> | マルチプロセッサ・システムにおけるタスク・スケジューリング方法 |
| JPH0797365B2 (ja) * | 1988-09-29 | 1995-10-18 | インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン | 分散アプリケーション・プログラム実行方法 |
| JPH08249291A (ja) * | 1995-02-03 | 1996-09-27 | Internatl Business Mach Corp <Ibm> | マルチシステム資源キャッピング |
| JPH0991257A (ja) * | 1995-09-25 | 1997-04-04 | Nec Corp | Ｃｐｕ管理方式 |
| JPH10283211A (ja) * | 1997-03-28 | 1998-10-23 | Internatl Business Mach Corp <Ibm> | マルチシステム環境のプロセッサ・リソース管理方法 |
| JPH1165862A (ja) * | 1997-08-14 | 1999-03-09 | Nec Corp | マルチプロセッサ資源分割管理方式 |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4564903A (en) | 1983-10-05 | 1986-01-14 | International Business Machines Corporation | Partitioned multiprocessor programming system |
| US4843541A (en) | 1987-07-29 | 1989-06-27 | International Business Machines Corporation | Logical resource partitioning of a data processing system |
| US5257368A (en) | 1991-03-28 | 1993-10-26 | International Business Machines Corp. | System for dynamically changing a system I/O configuration by determining differences between current and future configurations and describing differences to software and hardware control blocks |
| US5220654A (en) | 1991-03-28 | 1993-06-15 | International Business Machines Corp. | Method and system for managing an operating system definition of a dynamically modifiable i/o configuration |
| US5257379A (en) | 1991-09-04 | 1993-10-26 | International Business Machines Corporation | Establishing synchronization of hardware and software I/O configuration definitions |
| US5317739A (en) | 1992-03-30 | 1994-05-31 | International Business Machines Corp. | Method and apparatus for coupling data processing systems |
| CA2086691C (en) | 1992-03-30 | 1997-04-08 | David A. Elko | Communicating messages between processors and a coupling facility |
| JP2682770B2 (ja) * | 1992-05-15 | 1997-11-26 | 富士通株式会社 | 仮想計算機システムのｃｐｕ制御方式 |
| CA2100540A1 (en) * | 1992-10-19 | 1994-04-20 | Jonel George | System and method for performing resource reconfiguration in a computer system |
| US5301323A (en) | 1992-10-30 | 1994-04-05 | International Business Machines Corp. | Data processing system including dynamic channel path management |
| US5526484A (en) | 1992-12-10 | 1996-06-11 | International Business Machines Corporation | Method and system for pipelining the processing of channel command words |
| US5706432A (en) | 1993-11-04 | 1998-01-06 | International Business Machines Corporation | Mechanism for receiving messages at a coupling facility |
| US5473773A (en) | 1994-04-04 | 1995-12-05 | International Business Machines Corporation | Apparatus and method for managing a data processing system workload according to two or more distinct processing goals |
| US5564040A (en) | 1994-11-08 | 1996-10-08 | International Business Machines Corporation | Method and apparatus for providing a server function in a logically partitioned hardware machine |
| US5675739A (en) | 1995-02-03 | 1997-10-07 | International Business Machines Corporation | Apparatus and method for managing a distributed data processing system workload according to a plurality of distinct processing goal types |
| JP2940450B2 (ja) | 1995-10-26 | 1999-08-25 | 日本電気株式会社 | クラスタ型コンピュータのジョブスケジュール方法及び装置 |
| JPH09190381A (ja) * | 1996-01-11 | 1997-07-22 | Hitachi Ltd | マルチプロセッサ構成の仮想計算機システム |
| JP4634548B2 (ja) * | 1997-11-04 | 2011-02-16 | ヒューレット・パッカード・カンパニー | マルチプロセッサコンピュータシステム及びその動作方法 |
-
1999
- 1999-09-28 US US09/407,212 patent/US6587938B1/en not_active Expired - Lifetime
-
2000
- 2000-09-18 KR KR10-2000-0054697A patent/KR100420420B1/ko active IP Right Grant
- 2000-09-25 JP JP2000290086A patent/JP3672236B2/ja not_active Expired - Lifetime
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0797365B2 (ja) * | 1988-09-29 | 1995-10-18 | インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン | 分散アプリケーション・プログラム実行方法 |
| JPH06103092A (ja) * | 1992-09-18 | 1994-04-15 | Hitachi Ltd | 仮想計算機システム |
| JPH07182185A (ja) * | 1993-11-04 | 1995-07-21 | Internatl Business Mach Corp <Ibm> | マルチプロセッサ・システムにおけるタスク・スケジューリング方法 |
| JPH08249291A (ja) * | 1995-02-03 | 1996-09-27 | Internatl Business Mach Corp <Ibm> | マルチシステム資源キャッピング |
| JPH0991257A (ja) * | 1995-09-25 | 1997-04-04 | Nec Corp | Ｃｐｕ管理方式 |
| JPH10283211A (ja) * | 1997-03-28 | 1998-10-23 | Internatl Business Mach Corp <Ibm> | マルチシステム環境のプロセッサ・リソース管理方法 |
| JPH1165862A (ja) * | 1997-08-14 | 1999-03-09 | Nec Corp | マルチプロセッサ資源分割管理方式 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2022549628A (ja) * | 2019-09-23 | 2022-11-28 | グーグル エルエルシー | コンピュータシステムリソースの任意のグループ化 |
Also Published As
| Publication number | Publication date |
|---|---|
| KR100420420B1 (ko) | 2004-03-03 |
| KR20010050505A (ko) | 2001-06-15 |
| US6587938B1 (en) | 2003-07-01 |
| JP3672236B2 (ja) | 2005-07-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3659324B2 (ja) | コンピュータ環境の論理プロセッサを管理する方法、システム、およびプログラム製品 | |
| JP3813056B2 (ja) | 優先順位に基づくチャネル・サブシステム保留入出力作業キューの処理 | |
| JP3672236B2 (ja) | コンピュータ環境の中央処理装置を管理する方法、システム、およびプログラム製品 | |
| JP3807916B2 (ja) | コンピュータ環境の区画のグループを管理する方法およびシステム | |
| JP3872343B2 (ja) | コンピュータ環境におけるワークロード管理 | |
| US7051188B1 (en) | Dynamically redistributing shareable resources of a computing environment to manage the workload of that environment | |
| US6519660B1 (en) | Method, system and program products for determining I/O configuration entropy | |
| US7945913B2 (en) | Method, system and computer program product for optimizing allocation of resources on partitions of a data processing system | |
| US9338228B1 (en) | I/O scheduling and load balancing across the multiple nodes of a clustered environment utilizing data volume based scheduling priorities | |
| WO2016078178A1 (zh) | 一种虚拟cpu调度方法 | |
| US20050027719A1 (en) | Database control method | |
| US7568052B1 (en) | Method, system and program products for managing I/O configurations of a computing environment | |
| Rooney et al. | Intelligent resource director |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040722 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041020 Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20041020 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20041025 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050405 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050405 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20050405 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050415 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3672236 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080428 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090428 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090428 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100428 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120428 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130428 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130428 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140428 Year of fee payment: 9 |