(57)【要約】【課題】  所与のコンフィギュレーションに基づいてパーティション・マネージャ用に必要なメモリを決定するための方法、装置、およびプログラムを提供することにある。【解決手段】  一実施形態では、それぞれが機能関連コード部分の集合である複数のコンポーネントのそれぞれに必要なメモリの量を決定する。次に、複数のコンポーネントに必要なメモリの量に基づいて、パーティション・マネージャに必要なメモリの総量を決定する。【選択図】  図４
2004318841.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータのロジカル・パーティション環境においてパーティション・マネージャ用に必要なメモリを決定するための方法であって、
それぞれが機能関連コード部分の集合である複数のコンポーネントのそれぞれに必要なメモリの量を決定するステップと、
前記複数のコンポーネントに必要な前記メモリの量に基づいて、前記パーティション・マネージャに必要なメモリの総量を決定するステップと、
を有する方法。
【請求項２】
前記複数のコンポーネントのそれぞれに必要な前記メモリの量を決定するステップ、および前記パーティション・マネージャに必要な前記メモリの総量を決定するステップが、前記コンピュータの初期プログラム・ロードにおいて実行される、請求項１に記載の方法。
【請求項３】
前記メモリの総量を決定するステップが、前記複数のコンポーネントに必要なメモリの量を合計するステップを有する、請求項１に記載の方法。
【請求項４】
前記メモリの総量を決定するステップは、
前記複数のコンポーネントに必要な前記メモリの量を、合計に達するように合計するステップと、
前記メモリの総量に達するように前記合計にコンフィギュレーション乗数を掛け合わせるステップであって、前記コンフィギュレーション乗数が前記コンピュータの特定のコンフィギュレーションに固有のものであるステップと、
を有する請求項１に記載の方法。
【請求項５】
前記メモリの総量は、前記コンピュータの特定のコンフィギュレーションに依存する、請求項１に記載の方法。
【請求項６】
前記メモリの総量のメモリが使用不能である場合に、前記コンピュータの前記特定のコンフィギュレーションを他のコンフィギュレーションに変更するステップをさらに有する、請求項５に記載の方法。
【請求項７】
前記メモリの総量を決定するステップが前記コンピュータの特定のコンフィギュレーションに依存し、前記方法が、
コンフィギュレーションの変更リクエストを受信するステップと、
前記コンフィギュレーションの変更リクエストに基づいて、前記パーティション・マネージャに必要な前記メモリの総量の変更を計算するステップと、
をさらに有する請求項１に記載の方法。
【請求項８】
前記メモリの総量の変更がメモリの総量の増加である場合に、当該メモリの総量の増加が可能であるかどうかを判定するステップをさらに有する、請求項７に記載の方法。
【請求項９】
前記メモリの総量の増加が可能である場合に、前記メモリの総量の増加を前記パーティション・マネージャに割り振るステップをさらに有する、請求項８に記載の方法。
【請求項１０】
前記メモリの総量が使用可能であるかどうかを判定するステップをさらに有する、請求項１に記載の方法。
【請求項１１】
前記メモリの総量が使用可能である場合に、前記メモリの総量を前記パーティション・マネージャに割り振るステップをさらに有する、請求項１０に記載の方法。
【請求項１２】
前記メモリの総量を決定するステップが、前記コンピュータの特定のコンフィギュレーションを補償するステップを有する、請求項１１に記載の方法。
【請求項１３】
前記メモリの総量が前記コンピュータの特定のコンフィギュレーションに依存し、
前記メモリの総量が使用不能である場合に、前記コンピュータの前記特定のコンフィギュレーションを他のコンフィギュレーションに変更するステップをさらに有する、請求項１１に記載の方法。
【請求項１４】
コンピュータのロジカル・パーティション環境においてパーティション・マネージャ用に必要なメモリを決定するための方法であって、
それぞれがコンポーネントが機能関連コード部分の集合である複数のコンポーネントのそれぞれについてサイズ・レポートを提供するステップであって、所与のコンポーネントの各サイズ・レポートが前記所与のコンポーネントに必要なメモリの量を指示するステップと、
少なくとも（ｉ）前記サイズ・レポート、および（ｉｉ）前記コンピュータの特定のコンフィギュレーションに基づいて、前記パーティション・マネージャに必要なメモリの総量を決定するステップと、
を有する方法。
【請求項１５】
コンフィギュレーションの変更リクエストを受信するステップと、
前記コンフィギュレーションの変更リクエストに基づいて、前記パーティション・マネージャに必要な前記メモリの総量の変更を計算するステップとをさらに有する、請求項１４に記載の方法。
【請求項１６】
前記メモリの総量の変更が前記メモリの総量の増加である場合に、前記メモリの総量の増加が使用可能であるかどうかを判定するステップをさらに有する、請求項１５に記載の方法。
【請求項１７】
前記メモリの総量の増加が可能である場合に、前記メモリの総量の増加を前記パーティション・マネージャに割り振るステップをさらに有する、請求項１６に記載の方法。
【請求項１８】
各サイズ・レポートは、それぞれがコンフィギュレーション可能オプションに対応し、それぞれが必要メモリ値を有する複数のフィールドを有する請求項１４に記載の方法。
【請求項１９】
前記メモリの総量を決定するステップが、
コンフィギュレーション可能オプション固有の合計に達するように、所与のコンフィギュレーション可能オプションに対応する前記複数のフィールドのそれぞれの前記必要メモリ値を合計するステップと、
各コンフィギュレーション可能オプションの総必要メモリ値に達するように、各コンフィギュレーション可能オプション固有の合計ごとに、前記コンフィギュレーション可能オプション固有の合計にコンフィギュレーション乗数を掛け合わせるステップであって、各コンフィギュレーション乗数は前記特定のコンフィギュレーションに固有のものであるステップと、
各コンフィギュレーション可能オプションの前記総必要メモリ値を合計するステップと、
を有する請求項１８に記載の方法。
【請求項２０】
ハードウェア・リソースを有するコンピュータのロジカル・パーティション環境においてパーティション・マネージャ用に必要なメモリを決定するための方法において、
それぞれが機能関連コード部分の集合である複数のコンポーネントのそれぞれについてサイズ・レポートを有するサイズ・レジストリを提供するステップであって、各サイズ・レポートは複数のフィールドを有し、それぞれがコンフィギュレーション可能オプションに対応し、それぞれが必要メモリ値を有するステップと、
前記ハードウェア・リソースを初期化するステップと、
前記複数のフィールドのそれぞれの各必要メモリ値を初期化するステップと、
少なくとも（ｉ）前記サイズ・レポート、および（ｉｉ）前記コンピュータの特定のコンフィギュレーションに基づいて、前記パーティション・マネージャに必要なメモリの総量を決定するステップと、
を有する方法。
【請求項２１】
前記メモリの総量を決定するステップが、
コンフィギュレーション可能オプション固有の合計に達するように、所与のコンフィギュレーション可能オプションに対応する前記複数のフィールドのそれぞれの前記必要メモリ値を合計するステップと、
各コンフィギュレーション可能オプションの総必要メモリ値に達するように、各コンフィギュレーション可能オプション固有の合計ごとに、前記コンフィギュレーション可能オプション固有の合計にコンフィギュレーション乗数を掛け合わせるステップと、
各コンフィギュレーション可能オプションの前記総必要メモリ値を合計するステップと、
を有する請求項２０に記載の方法。
【請求項２２】
コンフィギュレーションの変更リクエストを受信するステップと、
前記コンフィギュレーションの変更リクエストに基づいて、前記パーティション・マネージャに必要な前記メモリの総量の変更を計算するステップとをさらに有する、請求項２０に記載の方法。
【請求項２３】
前記メモリ総量の変更が前記メモリの総量の増加である場合に、前記メモリの総量の前記増加が使用可能であるかどうかを判定するステップをさらに有する、請求項２２に記載の方法。
【請求項２４】
前記メモリの総量の増加が可能である場合に、前記メモリの総量の増加を前記パーティション・マネージャに割り振るステップをさらに有する、請求項２３に記載の方法。
【請求項２５】
それぞれがコンポーネントが機能関連コード部分の集合である複数のサイズ・レポートにアクセスするステップであって、各サイズ・レポートは複数のコンポーネントのそれぞれについて固有のものであり、所与のコンポーネントの各サイズ・レポートは、複数のフィールドを有し、それぞれのフィールドが前記コンピュータ・システム上のコンフィギュレーション可能オプションに固有のものであり、必要メモリ値を有するステップと、
少なくとも（ｉ）前記サイズ・レポート、および（ｉｉ）前記コンピュータの特定のコンフィギュレーションに基づいて、前記パーティション・マネージャに必要なメモリの総量を計算するステップと、
をロジカル・パーティション・コンピュータ・システムに実行させるプログラム。
【請求項２６】
前記メモリの総量を計算するステップが、
複数のコンフィギュレーション可能オプション固有の値に達するように、各サイズ・レポート内の各対応コンフィギュレーション可能オプションの前記必要メモリ値のそれぞれを合計するステップと、
複数の値に達するように、前記複数のコンフィギュレーション可能オプション固有の値のそれぞれにコンフィギュレーション乗数を掛け合わせるステップであって、各コンフィギュレーション乗数は前記特定のコンフィギュレーションに固有のものであるステップと、
前記メモリの総量に達するように、前記複数の値を合計するステップと、
を含む請求項２５に記載のプログラム。
【請求項２７】
コンフィギュレーションの変更リクエストを受信するステップと、
前記コンフィギュレーションの変更リクエストに基づいて、前記パーティション・マネージャに必要な前記メモリの総量の変更を計算するステップと、をさらにロジカル・パーティション・コンピュータ・システムに実行させる請求項２５に記載のプログラム。
【請求項２８】
前記メモリの総量の変更が前記メモリの総量の増加である場合に、前記メモリの総量の増加が可能であるかどうかを判定するステップをさらに有する、請求項２７に記載のプログラム。
【請求項２９】
前記メモリの総量の増加が可能である場合に、前記メモリの総量の増加を前記パーティション・マネージャに割り振るステップをさらにロジカル・パーティション・コンピュータ・システムに実行させる請求項２８に記載のプログラム。
【請求項３０】
メモリと少なくとも１つのプロセッサを含む複数のリソースと、
少なくともコンピュータ上に存在する１つまたは複数のロジカル・パーティションを管理するように構成されたロジカル・パーティション・マネージャと、
特定のコンフィギュレーションについて、初期プログラム・ロードにおいてユーザのコンフィギュレーション・リクエストを容認する以前に前記ロジカル・パーティション・マネージャが必要とする前記メモリの量を決定するように構成されたサイズ・カルキュレータと、
少なくとも前記ロジカル・パーティション・マネージャが必要とする前記量のメモリが特定のコンフィギュレーションに使用可能であるかどうかを判定し、
そうである場合に前記特定のコンフィギュレーションを許可するように構成されたコンフィギュレーション・マネージャと、
を有するコンピュータ。
【請求項３１】
前記コンフィギュレーション・マネージャが、前記ロジカル・パーティション・マネージャが必要とする前記量のメモリが前記特定のコンフィギュレーションに使用不能である場合に前記特定のコンフィギュレーションを変更するようにさらに構成される、請求項３０に記載のコンピュータ。
【請求項３２】
複数のサイズ・レポートを有するサイズ・レジストリをさらに有し、各サイズ・レポートは複数のコンポーネントのそれぞれについて固有のものであり、各コンポーネントが機能関連コード部分の集合であり、所与のコンポーネントの各サイズ・レポートは複数のフィールドを有し、それぞれのフィールドが前記コンピュータ上のコンフィギュレーション可能オプションに固有のものであり、必要メモリ値を有する、請求項３０に記載のコンピュータ。
【請求項３３】
前記コンフィギュレーション・マネージャは、少なくとも、
前記レジストリにアクセスし、
複数のコンフィギュレーション可能オプション固有の値に達するように各サイズ・レポート内の各対応コンフィギュレーション可能オプションの前記必要メモリ値のそれぞれを合計し、
前記複数のコンフィギュレーション可能オプション固有の値のそれぞれに、前記特定のコンフィギュレーションに固有のものであるコンフィギュレーション乗数を掛け合わせる、
ことで前記ロジカル・パーティション・マネージャが必要とする前記量のメモリが前記特定のコンフィギュレーションに使用可能であるかどうかを判定する、請求項３０に記載のコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にデータ処理に関する。より詳細には、本発明は、ロジカル・パーティション環境におけるメモリ管理に関する。
【背景技術】
【０００２】
ロジカル・パーティショニングとは、１のシステムを２以上の独立のシステムであるかのように動作させる能力をいう。各ロジカル・パーティションは、システムのリソースの１つの区域を表し、独立の論理システムとして動作する。リソースの区域は物理的である場合もあれば仮想である場合もあるので、各パーティションは論理的なものであるといえる。ロジカル・パーティションの一例は、マルチプロセッサ・コンピュータ・システムを複数の独立のサーバにパーティショニングすることであり、それぞれのサーバは専用のプロセッサと主記憶装置と入出力装置を備えることとなる。それぞれのパーティションでは、ＡＩＸ（Ｒ）、ＬＩＮＵＸ（Ｒ）のような様々なオペレーティング・システムを動作させることができる。なお、ＡＩＸ（Ｒ）はインターナショナル・ビジネス・マシーンズの登録商標である。
【０００３】
ロジカル・パーティション・システムは、パーティション・マネージャと呼ばれるソフトウェア・コンポーネントを含んでいる。パーティション・マネージャは、システム上のロジカル・パーティションの管理を担当する。パーティション・マネージャは、その役割を果たすため、使用可能なメモリを十分備えていなければならない。さらに、パーティション・マネージャに割り振られているメモリが不十分であることを検出する前に、起動の過程（ａｃｔｉｖａｔｉｏｎ  ｐａｔｈ）で不明ポイントに達するのを避けるため、何らかの形のプリエンプティブなメモリ管理技法が必要となる。このような状況では、パーティション・マネージャ全体を通じて部分的に受け付けられたコンフィギュレーション変更を「アンドゥ（ｕｎｄｏ）」するための大がかりな機能が必要になるだろう。このような機能を実装するには、部分的にコミットされた、ユーザが要求した変更のアンドゥするためのインターフェースがすべてのコンポーネントに必要となるだけでなく、、どのコンポーネントがすでに初期化され、どのコンポーネントのまだ初期化されていないかということの中心的追跡（ｃｅｎｔｒａｌ  ｔｒａｃｋｉｎｇ）も伴うこととなるだろう。さらに、起動の過程においてメモリ割振りが失敗する可能性が増大し、そのために、そのような失敗を処理しないためのコーディング・バグが生じてしまう可能性がある。
【０００４】
十分なメモリを確保するための可能性の１つは、メモリを「事前割振り（ｐｒｅ−ａｌｌｏｃａｔｅ）」をすることである。しかし、事前割振りは、数多くの問題と望ましくない結果をもたらしてしまう。特に、事前割振りでは、記憶域を割り振るパーティション・マネージャ内のコンフィギュレーション管理コンポーネントと他のすべてのコンポーネントとの間の大がかりなクロスコンポーネント・インターフェースが必要になるだろう。また、事前割振りメッセージをパイプで送るために数多くの他のコンポーネント間に新しいインターフェースも必要になるだろう。割振りコード・パス（ａｌｌｏｃａｔｉｏｎ  ｃｏｄｅ  ｐａｔｈｓ）全体は、”ｐｒｅ−ａｌｌｏｃａｔｅ”と、”ｒｏｌｌｂａｃｋ−ｐｒｅ−ａｌｌｏｃａｔｅｄ”と、”ｃｏｍｍｉｔ−ｐｒｅ−ａｌｌｏｃａｔｅｄ”という三重構成にどうしてもする必要があるだろう。
【０００５】
”ｐｒｅ−ａｌｌｏｃａｔｅ”コード・パスは、所与のコンフィギュレーションの変更のための空間を割り振るが、その変更が受け付けられたようにシステムが動作できるようにするものではない。”ｒｏｌｌｂａｃｋ−ｐｒｅ−ａｌｌｏｃａｔｅｄ”コード・パスは、その変更が廃棄されたので（記憶域が不十分であるために何らかのコンポーネントが割振りに失敗した可能性が最も高い）事前割り振りした空間をシステムに返すものである。”ｃｏｍｍｉｔ−ｐｒｅ−ａｌｌｏｃａｔｅｄ”コード・パスは、”ｐｒｅ−ａｌｌｏｃａｔｅ”を引き起こした変更を受け付けるものである。
【０００６】
メモリを割り振るすべてのコンポーネントは、その割振りの状態（たとえば、非割振り済み、事前割振り済み、割振り済み）を追跡し、上記の３通りのフェーズなど、何らかの形のマルチフェーズ・コミットメント制御に関与しなければならないだろう。このような変更により、追加の空間が必要になるばかりでなく、メモリを割り振るすべてのコンポーネントにとって少なからずコードが複雑になる。その結果、パーティション・マネージャに相当量のコードが追加されることになるだろう。というのは、コンポーネントは、その割振りの事前割振りおよび割振り状態を追跡するために構造を割り振る必要があるからである。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、パーティション環境においてメモリを管理するためのシステムおよび方法が必要である。
【課題を解決するための手段】
【０００８】
本発明は、一般的には、所与のコンフィギュレーションに基づいて、パーティション・マネージャために必要なメモリ（ｍｅｍｏｒｙ  ｒｅｑｕｒｅｍｅｎｔ）を決定することに関する。
【０００９】
あるの態様では、コンピュータのロジカル・パーティション環境においてパーティション・マネージャ用に必要なメモリを決定するための方法が提供される。それぞれが機能関連コード部分の集合（ｃｏｌｌｅｃｔｉｏｎ  ｏｆ  ｆｕｎｃｔｉｏｎ−ｒｅｌａｔｅｄ  ｃｏｄｅ  ｐｏｒｔｉｏｎ）である複数のコンポーネントのそれぞれに必要なメモリの量が決定される。次に、複数のコンポーネントに必要なメモリの量に基づいて、パーティション・マネージャに必要なメモリの総量が決定される。
【００１０】
コンピュータのロジカル・パーティション環境においてパーティション・マネージャ用に必要なメモリを決定するための方法の他の態様は、複数のコンポーネントのそれぞれについてサイズ・レポートを提供するステップであって、各コンポーネントが機能関連コード部分の集合であり、所与のコンポーネントの各サイズ・レポートが所与のコンポーネントに必要なメモリの量を指定するステップと、少なくとも（ｉ）サイズ・レポート、および（ｉｉ）コンピュータの特定のコンフィギュレーションに基づいて、パーティション・マネージャに必要なメモリの総量を決定するステップとを含む。
【００１１】
他の態様は、ハードウェア・リソースを有するコンピュータのロジカル・パーティション環境においてパーティション・マネージャ用に必要なメモリを決定するための方法を提供する。この方法は、複数のコンポーネントのそれぞれについてサイズ・レポートを有するサイズ・レジストリを提供するステップを含み、各コンポーネントは機能関連コード部分の集合であり、各サイズ・レポートは複数のフィールドを有し、それぞれがコンフィギュレーション可能オプションに対応し、それぞれが必要メモリ値を有する。この方法は、ハードウェア・リソースを初期化するステップと、複数のフィールドのそれぞれの各必要メモリ値を初期化するステップと、少なくとも（ｉ）サイズ・レポートと（ｉｉ）コンピュータの特定のコンフィギュレーションに基づいて、パーティション・マネージャに必要なメモリの総量を決定するステップとをさらに含む。
【００１２】
さらに他の態様は、ロジカル・パーティション・コンピュータ・システム上で実行されたときに、複数のサイズ・レポートにアクセスすることを含む操作を実行するプログラムを含むコンピュータ可読媒体を提供し、各サイズ・レポートは複数のコンポーネントのそれぞれについて固有のものであり、各コンポーネントは機能関連コード部分の集合であり、所与のコンポーネントの各サイズ・レポートは複数のフィールドを有し、それぞれのフィールドがコンピュータ・システム上のコンフィギュレーション可能オプションに固有のものであり、必要メモリ値を有する。この操作は、少なくとも（ｉ）サイズ・レポートと（ｉｉ）コンピュータの特定のコンフィギュレーションに基づいて、パーティション・マネージャに必要なメモリの総量を計算することをさらに提供する。
【００１３】
さらに他の態様は、メモリと少なくとも１つのプロセッサを含む複数のリソースと、少なくともコンピュータ上に存在する１つまたは複数のロジカル・パーティションを管理するように構成されたロジカル・パーティション・マネージャと、サイズ・カルキュレータとコンフィギュレーション・マネージャとを有するコンピュータを提供する。サイズ・カルキュレータは、特定のコンフィギュレーションについて初期プログラム・ロード時（すなわち、ブート時）にしかもユーザからのコンフィギュレーション・リクエストを容認する前にロジカル・パーティション・マネージャが必要とするメモリの量を決定するように構成されている。コンフィギュレーション・マネージャは、少なくともロジカル・パーティション・マネージャが必要とする量のメモリが特定のコンフィギュレーションに使用可能であるかどうかを判定し、そうである場合にその特定のコンフィギュレーションを容認するように構成されている。
【００１４】
上記で列挙した本発明の特徴、利点、および目的を達成する方法を詳細に理解できるように、添付図面に例示した本発明の実施形態を参照することにより、上記で簡単に要約した本発明のより詳細な説明が可能になるだろう。
【００１５】
しかし、添付図面は本発明の典型的な実施形態のみを例示し、したがって、その範囲を限定するものと考えるべきではない。本発明は他の同様に効果的な実施形態を認めることが可能であることに留意されたい。
【発明を実施するための最良の形態】
【００１６】
本発明は一般にロジカル・パーティション環境におけるメモリ管理に関する。パーティション・マネージャが必要とするメモリの量を前もって判定するために予測計算が行われる。次に、計算した量のメモリはパーティション・マネージャの排他使用のために予約される。そして、それによって、ロジカル・パーティションが予約されたメモリに構成されるのを防止する。本発明の他の態様は、パーティション・マネージャの現在のメモリ割振りの量を上回る追加のコンフィギュレーション・リクエストを拒否することに備えるものである。
【００１７】
本発明の一実施形態は、コンピュータ・システムで使用するためのプログラム記録媒体として実現される。このプログラム記録媒体のプログラム（複数も可）は、様々な実施形態（本明細書に記載する方法を含む）の様々な機能を定義するものであり、様々な信号運搬媒体上に含めることができる。例示的な信号運搬媒体としては、（ｉ）書込み不能記憶媒体（たとえば、ＣＤ−ＲＯＭドライブによって読取り可能なＣＤ−ＲＯＭディスクなどのコンピュータ内の読取り専用メモリ・デバイス）上に永続的に記憶された情報、（ｉｉ）書込み可能記憶媒体（たとえば、ディスケット・ドライブ内のフレキシブル・ディスクまたはハードディスク・ドライブ）上に記憶された可変情報、（ｉｉｉ）ワイヤレス通信を含むコンピュータ・ネットワークまたは電話網によるなどの通信媒体によってコンピュータに伝達される情報を含むが、これらに限定されない。後者の実施形態は特に、インターネットおよびその他のネットワークからダウンロードされた情報を含む。このような信号運搬媒体は、本発明の諸機能を指示するコンピュータ可読命令を伝えるときに、本発明の実施形態を表す。
【００１８】
一般に、本発明の様々な実施形態を実現するために実行されるルーチンは、オペレーティング・システムの一部または特定のアプリケーション、コンポーネント、プログラム、モジュール、オブジェクト、命令シーケンスにすることができる。本発明のコンピュータ・プログラムは通常、ネイティブ・コンピュータによって機械可読フォーマットに、したがって実行可能命令に変換される多数の命令から構成される。また、プログラムは、プログラムにとってローカルに常駐するか、メモリ内または記憶装置上で検出される変数およびデータ構造から構成される。加えて、以下に記載する様々なプログラムは、本発明の特定の実施形態で実現されるアプリケーションに基づいて識別することができる。しかし、以下に示す特定のプログラム名称は単に便宜的に使用するものであり、したがって、本発明はこのような名称によって識別および／または暗示される特定のアプリケーションのみで使用することに限定するべきではないことを理解されたい。
【００１９】
次に図１を参照すると、分散データ処理システム１００が示されている。分散データ処理システム１００は、本発明を実現可能な複数コンピュータのネットワークである。分散データ処理システム１００はネットワーク１０２を含み、これは、分散データ処理システム１００内に接続された様々な装置およびコンピュータ間の通信リンクを提供するために使用する媒体である。ネットワーク１０２は、ワイヤまたは光ファイバ・ケーブルなどの永続的接続または電話接続によって形成される一時的接続を含むことができる。特定の例では、分散データ処理システム１００はインターネットであり、ネットワーク１０２は、互いに通信するためにＴＣＰ／ＩＰプロトコル・スイートを使用するネットワークおよびゲートウェイの世界的集合を表している。また、分散データ処理システム１００は、たとえば、イントラネットまたはローカル・エリア・ネットワークなどのいくつかの異なるタイプのネットワークとして実現することもできる。
【００２０】
図示の例では、サーバとして構成されたデータ処理システム１０４は、記憶装置１０６とともにネットワーク１０２に接続されている。複数のクライアント１０８、１１０、１１２もネットワーク１０２に接続されている。これらのクライアント１０８、１１０、１１２は、たとえば、パーソナル・コンピュータまたはネットワーク・コンピュータにすることができる。この応用例のために、ネットワーク・コンピュータは、ネットワークに結合された任意のコンピュータであって、ネットワークに結合された他のコンピュータからプログラムまたはその他のアプリケーションを受信するコンピュータである。図示の例では、サーバ１０４は、ロジカル・パーティション・プラットフォームであり、ブート・ファイル、オペレーティング・システム・イメージ、アプリケーションなどのデータをクライアント１０８〜１１２に提供する。
【００２１】
サーバ１０４はハードウェア管理コンソール１５０に接続されている。ハードウェア・システム・コンソール１５０は、ラップトップ・コンピュータにすることができ、サーバ１０４上で動作する各オペレーティング・システム・イメージからオペレータにメッセージを表示するとともにオペレータから受信した入力情報をサーバ１０４に送信するために使用する。
【００２２】
分散データ処理システム１００は、プリンタ１１４、１１６、１１８などの装置も含む。クライアント１１０などのクライアントは、プリンタ１１４に直接印刷することができる。対照的に、クライアント１０８および１１２などのクライアントは、直接付加されたプリンタを備えていない。これらのクライアントは、サーバ１０４に付加されたプリンタ１１６または文書を印刷するためにコンピュータへの接続を必要としないネットワーク・プリンタであるプリンタ１１８に印刷することができる。別法として、クライアント１１０は、プリンタ・タイプおよび文書要件に応じて、プリンタ１１６またはプリンタ１１８に印刷することができる。当然のことながら、分散データ処理システム１００は、図示していない追加のサーバ、クライアント、その他の装置を含むこともできる。
【００２３】
図１に示す分散システム１００は単に代表的なものであり、他の実施形態が企図されることに留意されたい。たとえば、サーバ１０４は分散システムの１つの構成要素として示されているが、本発明はスタンドアロン・システムでも実施することができる。
【００２４】
図１に示すネットワーク１００は単に代表的なものであり、他の実施形態が企図されることに留意されたい。たとえば、データ処理システム１０４は分散システムの１つの構成要素として示されているが、本発明はスタンドアロン・システムでも実施することができる。
【００２５】
次に図２を参照すると、様々なロジカル・パーティション間で割り振ることが可能な様々なリソースを示すデータ処理システム１０４が例示されている。例として、データ処理システム１０４は、システム・バス２０６に接続された複数のプロセッサ２０１Ａ〜２０１Ｄを含む対称マルチプロセッサ（ＳＭＰ）システムである。特定の実施形態では、データ処理システム１０４は、ネットワーク内のサーバとして実現され、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズの製品であるｅＳｅｒｖｅｒ  ｉＳｅｒｉｅｓコンピュータであることができる。ＳＭＰシステムとして示されているが、別法として単一プロセッサ・システムも使用することができる。また、システム・バス２０６にはメモリ・コントローラ／キャッシュ２０８も接続され、これが複数のローカル・メモリ２６０Ａ〜２６０Ｄへのインターフェースを提供する。Ｉ／Ｏバス・ブリッジ２１０は、システム・バス２０６に接続され、Ｉ／Ｏバス２１２へのインターフェースを提供する。メモリ・コントローラ／キャッシュ２０８とＩ／Ｏバス・ブリッジ２１０は図示の通り統合することができる。
【００２６】
データ処理システムは、複数の入出力アダプタをサポートする周辺装置相互接続（ＰＣＩ）バス実現例である。典型的なＰＣＩバス実現例は、４〜８つの入出力アダプタ（すなわち、アドイン・コネクタ用の拡張スロット）をサポートすることになる。例証として、処理システム１０４は７つの入出力アダプタ２２０Ａ〜２２０Ｇを含む。各入出力アダプタ２２０Ａ〜２２０Ｇは、たとえば、データ処理システム１０４にとってクライアントである他のネットワーク・コンピュータなどの入出力装置とデータ処理システム１０４の間のインターフェースを提供する。一例として、Ｉ／Ｏバス２１２に接続されたＰＣＩホスト・ブリッジ２１４は、ＰＣＩローカル・バス２１５へのインターフェースを提供する。いくつかの（２つが示されている）入出力アダプタ２２０Ｂ〜２２０Ｃは、ＥＡＤＳ２１６とそれぞれのＰＣＩバス２１８および２１９を介してＰＣＩバス２１５に接続することができる。他の入出力アダプタは、それぞれのＰＣＩホスト・ブリッジ（たとえば、ブリッジ２２２、２３０、２４０）、ＥＡＤＳ（たとえば、ＥＡＤＳ２２４、２３２、２４２）、ＰＣＩバス（たとえば、２２３、２２６〜２２７、２３１、２３３、２４１、２４４〜２４５）によって同様に接続することができる。
【００２７】
特定タイプのアダプタの一例として、システム１０４はメモリ・マップ・グラフィックス・アダプタ２２０Ｆを含み、これは図示の通り、ＰＣＩバス２４１および２４４を介してＰＣＩホスト・ブリッジ２４０およびＥＡＤＳ２４２を通ってＩ／Ｏバス２１２に接続することができる。また、ハード・ディスク２５０は図示の通り、ＰＣＩバス２４１および２４５とハード・ディスク・アダプタ２２０Ｇを介してＰＣＩホスト・ブリッジ２４０およびＥＡＤＳ２４２を通ってＩ／Ｏバス２１２に接続することができる。
【００２８】
ＰＣＩホスト・ブリッジ２３０は、Ｉ／Ｏバス２１２に接続するためにＰＣＩバス２３１用のインターフェースを提供する。ＰＣＩバス２３１は、サービス・プロセッサ・メールボックス・インターフェースおよびＩＳＡバス・アクセス・パススルー論理回路２９４とＥＡＤＳ２３２にＰＣＩホスト・ブリッジ２３０を接続する。ＩＳＡバス・アクセス・パススルー論理回路２９４は、ＰＣＩ／ＩＳＡブリッジ２９３に向けられたＰＣＩアクセスを転送するものであり、ＰＣＩ／ＩＳＡブリッジ２９３はＩＳＡバス２９６を介してＮＶ−ＲＡＭ記憶域２９２にも接続する。サービス・プロセッサ２３５は、そのローカルＰＣＩバス２９５によってサービス・プロセッサ・メールボックス・インターフェース２９４に結合されている。サービス・プロセッサ２３５は、複数のＪＴＡＧ／Ｉ2Ｃバス２３４を介してプロセッサ２０１Ａ〜２０１Ｄにも接続されている。ＪＴＡＧ／Ｉ2Ｃバス２３４は、ＪＴＡＧ／スキャン・バス（ＩＥＥＥ１１４９．１を参照）とＰｈｉｌｌｉｐｓ  Ｉ2Ｃバスとの組み合わせである。しかし、別法として、ＪＴＡＧ／Ｉ2Ｃバス２３４は、Ｐｈｉｌｌｉｐｓ  Ｉ2ＣバスのみまたはＪＴＡＧ／スキャン・バスのみで置き換えることもできる。ホスト・プロセッサ２０１Ａ〜２０１ＤのすべてのＳＰ−ＡＴＴＮ信号は、サービス・プロセッサ２３５の割込み入力信号にまとめて接続されている。サービス・プロセッサ２３５は、それ専用のローカル・メモリ２９１を有し、ハードウェア操作パネル２９０にアクセスすることができる。
【００２９】
データ処理システム１０４に最初に電源を投入すると、サービス・プロセッサ２３５はＪＴＡＧ／スキャン・バスを使用して、システム（ホスト）プロセッサ２０１Ａ〜２０１Ｄ、メモリ・コントローラ２０８、Ｉ／Ｏブリッジ２１０に問い合わせる。このステップが完了すると、サービス・プロセッサ２３５はデータ処理システム１０４のインベントリおよびトポロジを理解している。また、サービス・プロセッサ２３５は、システム・プロセッサ２０１Ａ〜２０１Ｄ、メモリ・コントローラ２０８、Ｉ／Ｏブリッジ２１０に問い合わせることによって見つけたすべてのエレメントについて組込み型自己診断テスト（Ｂｕｉｌｔ−Ｉｎ−Ｓｅｌｆ−Ｔｅｓｔ、ＢＩＳＴ）、基本検証テスト（Ｂａｓｉｃ  Ａｓｓｕｒｅａｎｃｅ  Ｔｅｓｔｓ、ＢＡＴ）、メモリ・テストを実行する。ＢＩＳＴ、ＢＡＴ、メモリ・テスト中に検出した障害に関するエラー情報は、サービス・プロセッサ２３５が収集し報告することができる。
【００３０】
システム・リソースの意味のある／有効な構成がＢＩＳＴ、ＢＡＴ、メモリ・テスト中に障害があると判明したエレメントを取り出した後も依然として可能である場合、データ処理システム１０４は、ローカル（ホスト）メモリ２６０Ａ〜２６０Ｄへの実行可能コードのロードに取りかかることができる。次にサービス・プロセッサ２３５は、決定した状態にも応じて、ホスト・メモリ２６０Ａ〜２６０Ｄにロードしたコードを実行するためにホスト・プロセッサ２０１Ａ〜２０１Ｄをリリースする。また、サービス・プロセッサ２３５は、データ処理システム１０４内のエラーのチェックおよび報告などのモニター機能を実行することもできる。
【００３１】
図２はデータ処理システムの一構成にすぎないことは言うまでもない。システム１０４が複雑なマルチユーザ装置であるか、単一ユーザ・ワークステーションであるか、それ専用の不揮発性記憶域を備えていないネットワーク家電であるかにかかわらず、本発明の実施形態は、どのような同等の構成にも適用することができる。このため、図示の例は本発明に関連するアーキテクチャ上の制限を示すものではなく、当業者であれば、図２に示すハードウェアが様々になる可能性があることが分かるだろう。たとえば、図示のハードウェアに加えてまたはそのハードウェアの代わりに光ディスク・ドライブなどの他の周辺装置を使用することもできる。さらに、システム１０４は、マルチプロセッサ・システムではなく、単一プロセッサ・システムにすることもできる。
【００３２】
上記の通り、サーバ・コンピュータ１０４はロジカル・パーティション化されており、１つのロジカル・パーティションの複数リソースからなる各個別グループは別々のオペレーティング・システムに制御下されている。したがって、データ処理システム１０４は、同時に動作する複数の異種オペレーティング・システム（または単一オペレーティング・システムの複数インスタンス）を有することができる。これらの複数オペレーティング・システムのそれぞれは、その内部で実行されるソフトウェア・プログラムをいくつでも有することができる。ロジカル・パーティション化されると、プロセッサ２０１Ａ〜２０１Ｄ、メモリ２６０Ａ〜２６０Ｄ、入出力アダプタ２２０Ａ〜２２０Ｅなどの種々のハードウェア・リソースは種々のロジカル・パーティションに割り当てることができる。
【００３３】
たとえば、データ処理システム１０４が３つのロジカル・パーティションＰ１、Ｐ２、Ｐ３に分割され、各パーティションには異なるオペレーティング・システムが割り当てられているものと想定する。したがって、Ａｄｖａｎｃｅｄ  Ｉｎｔｅｒａｃｔｉｖｅ  Ｅｘｅｃｕｔｉｖｅ（ＡＩＸ）オペレーティング・システムの１つのインスタンスがパーティションＰ１内で実行され、ＡＩＸオペレーティング・システムの第２のインスタンス（イメージ）がパーティションＰ２内で実行され、ＬＩＮＵＸオペレーティング・システムがロジカル・パーティションＰ３内で動作している可能性がある。
【００３４】
データ処理システム１０４内で実行される各オペレーティング・システムは、そのロジカル・パーティション内にある入出力装置のみにアクセスすることができる。したがって、入出力アダプタ２２０Ａ〜２２０Ｅのそれぞれと、プロセッサ２０１Ａ〜２０１Ｄのそれぞれと、ローカル・メモリ２６０Ａ〜２６０Ｄのそれぞれが３つのパーティションの１つに割り当てられる。たとえば、プロセッサ２０１Ａ、メモリ２６０Ａ、入出力アダプタ２２０Ｂ、２２０Ｄ、２２０Ｅはロジカル・パーティションＰ１に割り当てることができ、プロセッサ２０２Ｂ〜２０２Ｃ、メモリ２６０Ｂ、入出力アダプタ２２０Ｃおよび２２０ＡはパーティションＰ２に割り当てることができ、プロセッサ２１０Ｄ、メモリ２６２Ｃ〜２６２Ｄ、入出力アダプタ２２０Ｆ〜２２０Ｇはロジカル・パーティションＰ３に割り当てることができる。別法として、ロジカル・パーティションは、プロセッサなどの１つまたは複数の論理／仮想リソースを定義することができる。たとえば、１つの仮想プロセッサは１つまたは複数の物理プロセッサによって提供される処理機能に対応する。仮想プロセッサが実現された場合、ロジカル・パーティションは特定の物理プロセッサに対して排他所有権を持たなくなる。むしろ、物理プロセッサは、様々なロジカル・パーティション間で共用することができ、それぞれのロジカル・パーティションについて定義された仮想プロセッサに応じてロジカル・パーティションにとって使用可能なものになる。
【００３５】
特異なリソースも共用できることに留意されたい。たとえば、システム１０４は、単一プロセッサが複数ロジカル・パーティション間の共用リソースである単一プロセッサ・システムにすることができる。このようなハードウェア環境では、各ロジカル・パーティションがプロセッサの一部分を「所有」する。
【００３６】
次に図３を参照すると、データ処理システム１０４のロジカル・パーティション・インスタンスの一例が示されている。システム１０４は、複数のロジカル・パーティション３０２Ａ、３０２Ｂ、・・・３０２Ｎ（ロジカル・パーティション３０２と総称する）を含む。特定の実施形態では、システム１０４は最高６２個のロジカル・パーティション３０２を有することができるが、ロジカル・パーティションの特定の容量は本発明の制限ではない。ロジカル・パーティションはパーティション・マネージャ３１２によって管理される。各ロジカル・パーティション３０２は、プロセッサ（複数も可）３０４Ａ、３０４Ｂ、・・・３０４Ｎと、メモリ３０６Ａ、３０６Ｂ、・・・３０６Ｎと、入出力装置３０８Ａ、３０８Ｂ、・・・３０８Ｎとを有し、他のロジカル・パーティションがプロセッサ３０２とは無関係にそれ専用のオペレーティング・システム３１０Ａ、３１０Ｂ、・・・３１０Ｎを実行することができる。様々なパーティション３０２に関連するリソースは物理的なものまたは論理／仮想的なものにすることができる。仮想リソースはそのリソースに対するロジカル・パーティションの容量を表し、その容量は排他的にそのパーティションの制御下にない１つまたは複数のリソースによって使用可能なものになる。たとえば、１つの仮想プロセッサは１つまたは複数の物理プロセッサによって提供される処理機能に対応する。仮想プロセッサが実現された場合、ロジカル・パーティションは特定の物理プロセッサに対して排他所有権を持たなくなる。むしろ、物理プロセッサは、様々なロジカル・パーティション間で共用することができ、それぞれのロジカル・パーティションについて定義された仮想プロセッサに応じてロジカル・パーティションにとって使用可能なものになる。
【００３７】
一実施形態では、ロジカル・パーティションは、動作中に動的にシステム１０４に追加するかまたはシステム１０４から除去することができ、したがって、システム１０４は動的にパーティション化されるという。他の実施形態では、ロジカル・パーティションは、ＩＰＬ（初期プログラム・ロード）で確立し、動作中は未変更のままにすることができ、その場合、システム１０４は静的にパーティション化されるという。
【００３８】
いずれの場合も、パーティショニングの処理はパーティション・マネージャ３１２の役割である。特定の実施形態では、パーティション・マネージャ３１２は、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズから入手可能なソフトウェア・コンポーネントである「ハイパーバイザ」として実現される。ある実施形態では、パーティション・マネージャ３１２は、ディスパッチ可能パーティション・マネージャ３１４とディスパッチ不能パーティション・マネージャ３１６とを有するものと見なすことができる。一般に、ディスパッチ不能パーティション・マネージャ３１６は、概してコンピュータ・システム１０４のシステム・ファームウェアとして実現され、トランスポート制御使用可能化、ページテーブル管理など、低レベルのパーティション管理機能を提供し、複数のロジカル・パーティション３０２を構成し、サービスし、実行するために必要なデータおよびアクセス方式を含む。ディスパッチ可能パーティション・マネージャ３１４は、仮想サービス・プロセッサ機能、パーティションの開始／停止など、一般により高レベルのパーティション管理機能を処理するシステム・ファームウェアである。
【００３９】
本発明の一態様によれば、パーティション・マネージャ３１２は、動作に必要なメモリの予測量を計算するように構成されている。加えて、パーティション・マネージャは、使用可能な量のメモリを上回る（たとえば、ユーザからの）追加のコンフィギュレーション・リクエストを拒否するように構成されている。
【００４０】
次に図４を参照すると、本発明の一実施形態を示す図が示されている。一般に、図４は、ディスパッチ不能パーティション・マネージャ３１６と、ディスパッチ可能パーティション・マネージャ３１４の様々な態様とを示している。一実施形態では、ディスパッチ可能パーティション・マネージャ３１４の様々な態様がＪａｖａ（Ｒ）などのオブジェクト指向プログラミング言語でオブジェクトとして実現される。しかし、オブジェクト指向プログラミング（ＯＯＰ）言語に関連して本発明の様々な態様を説明することが可能ではあるが、本発明はＯＯＰまたは他の特定のプログラミング言語のいずれにも限定されないことは言うまでもない。オブジェクト、クラス、サブクラスなどのＯＯＰ用語に対する言及は、単に説明の便宜のためのものに過ぎない。
【００４１】
ディスパッチ可能パーティション・マネージャ３１４は一般に、初期プログラム・ロード（ＩＰＬ）マネージャ４０２と、ハードウェア・マネージャ４０４と、コンフィギュレーション・マネージャ４０６と、サイズ・カルキュレータ４１０と、コンポーネント・サイズ・レジストリ４１２とを含む。初期プログラム・ロードにおいて、ＩＰＬマネージャ４０２は、ハードウェア・マネージャ４０４とコンフィギュレーション・マネージャ４０６の独立した実行を開始する。ハードウェア・マネージャ４０４は、システム１０４上のハードウェアを担当する。このような役割には、デバイスが正常に働いていること（たとえば、様々なＰＣＩデバイスが適切に初期化されたこと）と、様々なロジカル・パーティション３０２に対するハードウェアの割振りが適切であることを保証することが含まれる。コンフィギュレーション・マネージャ４０６は、様々なロジカル・パーティション３０２と、ハードウェアとロジカル・パーティション３０２との論理的な関連付けを追跡する。コンフィギュレーション・マネージャ４０６の重要な機能の１つは、サイズ・カルキュレータ４１０を呼び出して、システム１０４上の所与のロジカル・パーティション・コンフィギュレーションにどの程度のメインメモリが必要であるかを決定することである。この目的のためにコンフィギュレーション・マネージャ４０６によって呼び出されると、サイズ・カルキュレータ４１０は、システム１０４上のすべてのハードウェア・リソースが補償された（すなわち、ハードウェア・マネージャ４０４に報告した）ことを示すハードウェア・マネージャからの呼出しを待つことができる。次にサイズ・カルキュレータ４１０は、コンポーネント・サイズ・レジストリ４１２にアクセスし、パーティション・マネージャ３１２が必要とする総メインメモリの合計を計算する。ある実施形態では、コンポーネント・サイズ・レジストリ４１０は、システム１０４用に構成された様々なコンポーネントによって登録される個々のサイズ・レポート４１４Ａ、４１４Ｂ、・・・４１４Ｎの集合である。一実施形態では、「コンポーネント」とは共通機能に関連するコードを指す。たとえば、あるコンポーネントはロジカル・パーティションのコンフィギュレーションに関連するすべてのコードであり、他のコンポーネントはＰＣＩバスに関連するすべてのコードであり、さらに他のコンポーネントはグローバル割込み待ち行列に関連するすべてのコードであり、以下同様である。このため、図４に示すパーティション・マネージャ３１２のエンティティの一部はそれ自体がコンポーネントであり（ＩＰＬマネージャ４０２およびハードウェア・マネージャ４０４など）、したがって、コンポーネント・サイズ・レジストリ４１２にサイズ・レポート４１４を登録する。
【００４２】
各サイズ・レポート４１４は、様々なコンフィギュレーション・オプションに関するコンポーネント固有のサイズ情報を提供する。一実施形態では、サイズ・レポート４１４は、デフォルト値（すなわち、ゼロ）を備えたいくつかのフィールドと、割振りサイズへの要求サイズの丸めを処理するための別の１組のメソッドとを含む、基本クラスを使用して実現される。例示的な基本クラスを以下の表Ｉに示す。また、例示的な丸めメソッドを表ＩＩに示す。
【表１】
2004318841.tif 000003
【００４３】
【表２】
2004318841.tif 000004
【００４４】
表Ｉの００２〜００４行は、それに関して特定のコンポーネントがメインメモリを必要とするコンフィギュレーション・オプション・タイプのフィールドを示すことに留意されたい。例証として、表に示したオプション・タイプ・フィールドとしては、「Ｂａｓｅ」タイプと、「ＰｅｒＬｐＳｉｚｅ」タイプと、「ＰｅｒｌＯＳｌｏｔＳｉｚｅ」を含む。「Ｂａｓｅ」オプション・タイプは、あるコンポーネントがシステム１０４上で存在するために必要とするメモリに対応する。「ＰｅｒＬｐＳｉｚｅ」オプション・タイプは、ロジカル・パーティション当たり、あるコンポーネントが必要とするメモリに対応する。「ＰｅｒｌＯＳｌｏｔＳｉｚｅ」オプション・タイプは、ＩＯスロットについて、あるコンポーネントが必要とするメモリに対応する。表Ｉに示すオプション・タイプは単に一例に過ぎず、基本クラスは任意の数の追加または他のオプション・タイプに備えることが可能であることは言うまでもない。
【００４５】
次に各コンポーネントは、基本クラスをさらに分類し、必要なコンフィギュレーション・オプション・タイプについてそのコンポーネント固有の情報を提供する。このため、所与のコンポーネントは、基本クラスが提供する使用可能オプション・タイプのうちの任意の数（すなわち、１つまたは複数）について値を提供することができる。特定のコンポーネントに関するサイズ・レポートの一例を表ＩＩＩに示す。
【表３】
2004318841.tif 000005
【００４６】
表ＩＩＩが示す例では、「ｆｏｏ１」クラスについて「Ｂａｓｅ」オプション・タイプの値が用意されている。動作時にコンパイラ３１８（図３に示す）は、「ｆｏｏ１」クラスについてインスタンスを生成されたオブジェクトが必要とするメモリの量（たとえば、バイト数）を計算する。実際には、必要なメモリの量はバイト数として計算することができるが、ランタイム時に「ｆｏｏ１」へのメモリの割振りを担当するメモリ・マネージャ３２０（同じく図３に示す）は、異なるサイズ・スケールでメモリ・ブロックを割り振るように構成することができる。したがって、「ｍｅｔｈｏｄＴｏＲｏｕｎｄＵｐ」というメソッドを使用して、メモリ・マネージャ３２０が使用するスケールと一致したサイズまで要求メモリ（すなわち、コンパイラ３１８が計算したメモリの量）を丸める。所与のコンポーネント（たとえば、「ｆｏｏ２」、「ｆｏｏ３」など）の各コンフィギュレーション・オプション・タイプの残りのクラスそれぞれについて、同じプロセスを実行する。このようにして、所与のコンポーネントの各コンフィギュレーション・オプション・タイプごとに値（すなわち、メモリのバイト数）を計算し、これらの値をサイズ・レポート４１４の形でコンポーネント・サイズ・レジストリ４１２に登録する。
【００４７】
パーティション・マネージャ３１２が必要とするメモリの総量を決定するために、サイズ・カルキュレータ４１０は、コンポーネント・サイズ・レジストリ４１２に登録された各サイズ・レポート４１４の終わりまで繰り返し、各コンフィギュレーション・オプション・タイプの値を合計する。各コンフィギュレーション・タイプの合計値はマスタ・サイズ・レポート４１６に記憶することができる。次にサイズ・カルキュレータ４１０は、存在するコンフィギュレーションおよびハードウェアに応じて、様々な合計を掛け合わせる。たとえば、マスタ・サイズ・レポート４１６内の「ＰｅｒＬｐＳｉｚｅ」オプション・タイプの総合計値が１００バイトであり、システム１０４について５つのパーティションが構成されると想定するが、この場合、「５」はコンフィギュレーション乗数（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｍｕｌｔｉｐｌｉｅｒ）といい、それぞれのコンフィギュレーションに固有のものである。「ＰｅｒＬｐＳｉｚｅ」オプション・タイプに必要な総メモリは１００と５の積（１００×５）すなわち５００バイトである。この計算は、各フィールドごとに適切なコンフィギュレーション乗数を使用して、各コンフィギュレーション・オプション・タイプ・フィールドごとに実行する。次にサイズ・カルキュレータ４１０は、パーティション・マネージャ３１２に必要な総メモリに達するように、個々のｐｅｒオプション・タイプ値を合計する。この合計値はコンフィギュレーション・マネージャ４０６に返される。一実施形態では、コンフィギュレーション乗数は、カウント・レポート４２０という別の登録済みレポートに用意される。
【００４８】
割り振るべきメモリ空間を管理するために必要なオーバヘッドを補償するために、個々のｐｅｒオプション・タイプ値を丸めることができることが企図されている。さらに、入力内の原因不明／予想外の変動を補償するために、追加のメモリ量を「セーフティ・ネット」としてこの丸め値に加えることができる。本発明により実現される丸めメソッドは、メモリ・マネージャ３２０が実現する特定のメモリ管理方式に応じて様々になる可能性があることに留意されたい。環境によっては、種々の割振り（すなわち、種々の細分性の割振りメモリ・ブロック）を処理するために、複数のメモリ・マネージャを実現することができる。この場合、本明細書に記載するレポート・サイズ処理は、各メモリ・マネージャ用の丸めがそれぞれのブロック・サイズと一致することを保証するために、各メモリ・マネージャごとに実行される。
【００４９】
当業者であれば、この数学演算が様々な順序で実行可能であることが分かるだろう。たとえば、個々のオプション・タイプ・フィールドの値を乗算し、合計し、マスタ・サイズ・レポート４１６に提供する。いずれの場合も、マスタ・サイズ・レポート４１６の各種フィールドの値は、特定のコンフィギュレーション・オプション・タイプに必要な総メモリを表している。
【００５０】
次にコンフィギュレーション・マネージャ４０６は、サイズ・カルキュレータ４１０から受け取った合計値に基づいて、システム１０４上のコンフィギュレーションを検証する。すなわち、コンフィギュレーション・マネージャ４０６は、永続コンフィギュレーション（ｐｅｒｓｉｓｔｅｎｔ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）を最後に更新したときにパーティション・マネージャ３１２用に十分なメインメモリが確保されているかどうかを判定する。不十分なメモリしか確保されていない場合、コンフィギュレーション・マネージャ４０６は、可能であれば、パーティション・マネージャ３１２に必要なメモリを使える状態にするために、そのコンフィギュレーションに対し必要な調整を行う。必要なメモリを使用可能な状態にできない場合、エラーが発生し、ユーザはコンフィギュレーション・ユーザ・インターフェース４１８を介してそれに関する通知を受け取る可能性がある。ある実施形態では、コンフィギュレーション・ユーザ・インターフェース４１８は図１のハードウェア管理コンソール１５０である。必要なメモリが使用可能である場合、コンフィギュレーション・マネージャ４０６はコンフィギュレーション・ユーザ・インターフェース４１８を介して通知を発行する。次にコンフィギュレーション・マネージャ４０６は、ディスパッチ不能パーティション・マネージャ３１６にそのパーティション・コンフィギュレーションを知らせる。応答として、ディスパッチ不能パーティション・マネージャ３１６は、システムをパーティショニングし、ロジカル・パーティションのオペレーティング・システムが始動するための準備をするようにハードウェアをセットアップする。
【００５１】
ある実施形態では、動作中（ＩＰＬ後）にコンフィギュレーションの変更が行われる。たとえば、ユーザは、コンフィギュレーション・ユーザ・インターフェース４１８を介してコンフィギュレーションの変更を行うことができる。例示的なコンフィギュレーションの変更としては、パーティションを作成するためのリクエスト、パーティションを削除するためのリクエスト、特定のＩＯスロットを特定のパーティションに割り当てるためのリクエスト、仮想入出力アダプタを作成するためのリクエストを含む。また、コンフィギュレーションの変更はバッチの形にすることもできる。いずれの場合も、コンフィギュレーションの変更のリクエストによってコンフィギュレーション・マネージャ４０６はデルタ値を決定することになり、その場合、デルタ値はコンフィギュレーション・オブジェクト・タイプの数の変化である。一実施形態では、デルタ値はデルタ・レポート４２２というレポートに用意され、そのデルタ値は、カウント・レポート４２０の（フィールド当たりの）カウント値とリクエストに指定された新しい値との間で計算された差である。一例として、もう１つのロジカル・パーティションを追加するコンフィギュレーションの変更では「ＰｅｒＬｐＳｉｚｅ」オプション・タイプが＋１だけ変化するが、１つのロジカル・パーティションを除去すると「ＰｅｒＬｐＳｉｚｅ」オプション・タイプが−１だけ変化する。次にデルタ値をサイズ・カルキュレータ４１０に提供し、そのサイズ・カルキュレータ４１０はマスタ・サイズ・レポート４１６内で前に初期化したフィールドの乗数としてそのデルタ値を使用する。次に、各フィールドの個々の積値を合計する。結果値は、コンフィギュレーションの変更の結果としてパーティション・マネージャ３１２が必要とする追加メモリである。この結果値はコンフィギュレーション・マネージャ４０６に返される。この結果値は正数になる場合もあれば（この場合、パーティション・マネージャ３１２に追加メモリが必要である）、負数になる場合もあり（この場合、追加メモリは一切不要であり、今後のＩＰＬのための必要なメモリを削減することができる）、あるいはゼロになる場合もある（この場合、追加メモリは一切不要である）。結果値が正数である場合、コンフィギュレーション・マネージャ４０６は、メモリ・リクエストに応じることができるかどうかを判定する。場合によっては、パーティション・マネージャ３１２はすでに、最初に必要だった量（すなわち、ＩＰＬ時に決定したもの）以上のメモリがそれに割り振られている可能性があり、その場合、追加割振りは一切不要である。必要なメモリ値が現在割り振られているメモリより多い場合、コンフィギュレーション・マネージャ４０６は、追加メモリを割り振ることができるかどうかを判定しなければならない。すなわち、コンフィギュレーション・マネージャ４０６は、未割振りメモリをパーティション・マネージャ３１２に割り振ることができるかどうかを判定する。割振り可能である場合、メモリはそれに応じて割り振られ、コンフィギュレーション・マネージャ４０６はそのコンフィギュレーションをディスパッチ不能パーティション・マネージャ３１６に知らせ、次にディスパッチ不能パーティション・マネージャ３１６はそのコンフィギュレーションを実現する。割振り不能である場合、コンフィギュレーション・ユーザ・インターフェース４１８を介してユーザにエラー・メッセージが返され、その場合、ユーザは、コンフィギュレーション・ユーザ・インターフェース４１８を介してメモリの再割振りを選択することができる。コンフィギュレーションが容認できる状態に変更された場合、ユーザは再試行することができる。
【００５２】
次に図５に関連して特定の例について説明する。図５は、Ｎ通りのサイズ・レポート４１４を示している。各サイズ・レポートは、複数のコンフィギュレーション・オプション・フィールドＦ１、Ｆ２、・・・ＦＭを有する。パーティション・マネージャに必要な総メモリは代表的な式によって示されている。特に、すべてのサイズ・レポート（Ｎ）が各フィールドの合計値に達するように、複数のコンフィギュレーション・オプション・フィールドのそれぞれの値を合計するが、その値はマスタ・サイズ・レポート４１６で管理する。これらの合計は式の内部合計（すなわち、１〜Ｍの場合にＲ［Ｎ］［Ｍ］の合計であり、Ｎはレポートであり、Ｍは所与のレポートのフィールドである）によって表される。パーティション・マネージャに必要な総メモリを計算するために、（マスタ・サイズ・レポート内の）各合計値と対応するコンフィギュレーション乗数（ＣＭ）との積を計算する。上記の通り、コンフィギュレーション乗数はそれぞれ特定のコンフィギュレーション・オプション・フィールドに固有のものであり、カウント・レポート４２０に用意することができる。積の合計はパーティション・マネージャに必要な総メモリである（式１）。この場合も、特定のメモリ管理方式に応じて、十分なメモリを確保するために、計算中の種々の時点で丸め技法を使用することができる。したがって、サイズ・レポート内の各フィールドの個々のバイト値は丸めることができ、式１の計算結果も丸めることができる。さらに、後者の値はそれ自体も丸めることができる。
【００５３】
一態様では、本発明のレジストリ手法により、それぞれのコンポーネントがそのそれぞれのサイズ・レポートを個別かつ独立して更新することができ、中央エンティティによる手操作による介入や中央に位置するテーブルでの競合は不要である。むしろ、コンポーネントは、登録されたレポートを提供する専用のモジュールを簡単に更新し、そのレポートを含むモジュールを再構築することができる。
【００５４】
上記の説明は本発明の実施形態に向けられたものであるが、本発明の基本範囲を逸脱せずに本発明の他の実施形態を考案することができ、その範囲は特許請求の範囲によって決定される。
【００５５】
まとめとして、本発明の構成に関して以下の事項を開示する。
（１）コンピュータのロジカル・パーティション環境においてパーティション・マネージャ用に必要なメモリを決定するための方法であって、
それぞれが機能関連コード部分の集合である複数のコンポーネントのそれぞれに必要なメモリの量を決定するステップと、
複数のコンポーネントに必要なメモリの量に基づいて、パーティション・マネージャに必要なメモリの総量を決定するステップと、
を有する方法。
（２）複数のコンポーネントのそれぞれに必要なメモリの量を決定するステップ、およびパーティション・マネージャに必要なメモリの総量を決定するステップが、コンピュータの初期プログラム・ロードにおいて実行される、（１）に記載の方法。
（３）メモリの総量を決定するステップが、複数のコンポーネントに必要なメモリの量を合計するステップを有する、（１）に記載の方法。
（４）メモリの総量を決定するステップは、
複数のコンポーネントに必要なメモリの量を、合計に達するように合計するステップと、
メモリの総量に達するように合計にコンフィギュレーション乗数を掛け合わせるステップであって、コンフィギュレーション乗数がコンピュータの特定のコンフィギュレーションに固有のものであるステップと、
を有する（１）に記載の方法。
（５）メモリの総量は、コンピュータの特定のコンフィギュレーションに依存する、（１）に記載の方法。
（６）メモリの総量のメモリが使用不能である場合に、コンピュータの特定のコンフィギュレーションを他のコンフィギュレーションに変更するステップをさらに有する、（５）に記載の方法。
（７）メモリの総量を決定するステップがコンピュータの特定のコンフィギュレーションに依存し、方法が、
コンフィギュレーションの変更リクエストを受信するステップと、
コンフィギュレーションの変更リクエストに基づいて、パーティション・マネージャに必要なメモリの総量の変更を計算するステップと、
をさらに有する（１）に記載の方法。
（８）メモリの総量の変更がメモリの総量の増加である場合に、当該メモリの総量の増加が可能であるかどうかを判定するステップをさらに有する、（７）に記載の方法。
（９）メモリの総量の増加が可能である場合に、メモリの総量の増加をパーティション・マネージャに割り振るステップをさらに有する、（８）に記載の方法。
（１０）メモリの総量が使用可能であるかどうかを判定するステップをさらに有する、（１）に記載の方法。
（１１）メモリの総量が使用可能である場合に、メモリの総量をパーティション・マネージャに割り振るステップをさらに有する、（１０）に記載の方法。
（１２）メモリの総量を決定するステップが、コンピュータの特定のコンフィギュレーションを補償するステップを有する、（１１）に記載の方法。
（１３）メモリの総量がコンピュータの特定のコンフィギュレーションに依存し、
メモリの総量が使用不能である場合に、コンピュータの特定のコンフィギュレーションを他のコンフィギュレーションに変更するステップをさらに有する、（１１）に記載の方法。
（１４）コンピュータのロジカル・パーティション環境においてパーティション・マネージャ用に必要なメモリを決定するための方法であって、
それぞれがコンポーネントが機能関連コード部分の集合である複数のコンポーネントのそれぞれについてサイズ・レポートを提供するステップであって、所与のコンポーネントの各サイズ・レポートが所与のコンポーネントに必要なメモリの量を指示するステップと、
少なくとも（ｉ）サイズ・レポート、および（ｉｉ）コンピュータの特定のコンフィギュレーションに基づいて、パーティション・マネージャに必要なメモリの総量を決定するステップと、
を有する方法。
（１５）コンフィギュレーションの変更リクエストを受信するステップと、
コンフィギュレーションの変更リクエストに基づいて、パーティション・マネージャに必要なメモリの総量の変更を計算するステップとをさらに有する、（１４）に記載の方法。
（１６）メモリの総量の変更がメモリの総量の増加である場合に、メモリの総量の増加が使用可能であるかどうかを判定するステップをさらに有する、（１５）に記載の方法。
（１７）メモリの総量の増加が可能である場合に、メモリの総量の増加をパーティション・マネージャに割り振るステップをさらに有する、（１６）に記載の方法。
（１８）各サイズ・レポートは、それぞれがコンフィギュレーション可能オプションに対応し、それぞれが必要メモリ値を有する複数のフィールドを有する（１４）に記載の方法。
（１９）メモリの総量を決定するステップが、
コンフィギュレーション可能オプション固有の合計に達するように、所与のコンフィギュレーション可能オプションに対応する複数のフィールドのそれぞれの必要メモリ値を合計するステップと、
各コンフィギュレーション可能オプションの総必要メモリ値に達するように、各コンフィギュレーション可能オプション固有の合計ごとに、コンフィギュレーション可能オプション固有の合計にコンフィギュレーション乗数を掛け合わせるステップであって、各コンフィギュレーション乗数は特定のコンフィギュレーションに固有のものであるステップと、
各コンフィギュレーション可能オプションの総必要メモリ値を合計するステップと、
を有する（１８）に記載の方法。
（２０）ハードウェア・リソースを有するコンピュータのロジカル・パーティション環境においてパーティション・マネージャ用に必要なメモリを決定するための方法において、
それぞれが機能関連コード部分の集合である複数のコンポーネントのそれぞれについてサイズ・レポートを有するサイズ・レジストリを提供するステップであって、各サイズ・レポートは複数のフィールドを有し、それぞれがコンフィギュレーション可能オプションに対応し、それぞれが必要メモリ値を有するステップと、
ハードウェア・リソースを初期化するステップと、
複数のフィールドのそれぞれの各必要メモリ値を初期化するステップと、
少なくとも（ｉ）サイズ・レポート、および（ｉｉ）コンピュータの特定のコンフィギュレーションに基づいて、パーティション・マネージャに必要なメモリの総量を決定するステップと、
を有する方法。
（２１）メモリの総量を決定するステップが、
コンフィギュレーション可能オプション固有の合計に達するように、所与のコンフィギュレーション可能オプションに対応する複数のフィールドのそれぞれの必要メモリ値を合計するステップと、
各コンフィギュレーション可能オプションの総必要メモリ値に達するように、各コンフィギュレーション可能オプション固有の合計ごとに、コンフィギュレーション可能オプション固有の合計にコンフィギュレーション乗数を掛け合わせるステップと、
各コンフィギュレーション可能オプションの総必要メモリ値を合計するステップと、
を有する（２０に記載の方法。
（２２）コンフィギュレーションの変更リクエストを受信するステップと、
コンフィギュレーションの変更リクエストに基づいて、パーティション・マネージャに必要なメモリの総量の変更を計算するステップとをさらに有する、（２０に記載の方法。
（２３）メモリ総量の変更がメモリの総量の増加である場合に、メモリの総量の増加が使用可能であるかどうかを判定するステップをさらに有する、（２２に記載の方法。
（２４）メモリの総量の増加が可能である場合に、メモリの総量の増加をパーティション・マネージャに割り振るステップをさらに有する、（２３に記載の方法。
（２５）それぞれがコンポーネントが機能関連コード部分の集合である複数のサイズ・レポートにアクセスするステップであって、各サイズ・レポートは複数のコンポーネントのそれぞれについて固有のものであり、所与のコンポーネントの各サイズ・レポートは、複数のフィールドを有し、それぞれのフィールドがコンピュータ・システム上のコンフィギュレーション可能オプションに固有のものであり、必要メモリ値を有するステップと、
少なくとも（ｉ）サイズ・レポート、および（ｉｉ）コンピュータの特定のコンフィギュレーションに基づいて、パーティション・マネージャに必要なメモリの総量を計算するステップと、
をロジカル・パーティション・コンピュータ・システムに実行させるプログラム。
（２６）メモリの総量を計算するステップが、
複数のコンフィギュレーション可能オプション固有の値に達するように、各サイズ・レポート内の各対応コンフィギュレーション可能オプションの必要メモリ値のそれぞれを合計するステップと、
複数の値に達するように、複数のコンフィギュレーション可能オプション固有の値のそれぞれにコンフィギュレーション乗数を掛け合わせるステップであって、各コンフィギュレーション乗数は特定のコンフィギュレーションに固有のものであるステップと、
メモリの総量に達するように、複数の値を合計するステップと、
を含む（２５に記載のプログラム。
（２７）コンフィギュレーションの変更リクエストを受信するステップと、
コンフィギュレーションの変更リクエストに基づいて、パーティション・マネージャに必要なメモリの総量の変更を計算するステップと、をさらにロジカル・パーティション・コンピュータ・システムに実行させる（２５に記載のプログラム。
（２８）メモリの総量の変更がメモリの総量の増加である場合に、メモリの総量の増加が可能であるかどうかを判定するステップをさらに有する、（２７に記載のプログラム。
（２９）メモリの総量の増加が可能である場合に、メモリの総量の増加をパーティション・マネージャに割り振るステップをさらにロジカル・パーティション・コンピュータ・システムに実行させる（２８に記載のプログラム。
（３０）メモリと少なくとも１つのプロセッサを含む複数のリソースと、
少なくともコンピュータ上に存在する１つまたは複数のロジカル・パーティションを管理するように構成されたロジカル・パーティション・マネージャと、
特定のコンフィギュレーションについて、初期プログラム・ロードにおいてユーザのコンフィギュレーション・リクエストを容認する以前にロジカル・パーティション・マネージャが必要とするメモリの量を決定するように構成されたサイズ・カルキュレータと、
少なくともロジカル・パーティション・マネージャが必要とする量のメモリが特定のコンフィギュレーションに使用可能であるかどうかを判定し、
そうである場合に特定のコンフィギュレーションを許可するように構成されたコンフィギュレーション・マネージャと、
を有するコンピュータ。
（３１）コンフィギュレーション・マネージャが、ロジカル・パーティション・マネージャが必要とする量のメモリが特定のコンフィギュレーションに使用不能である場合に特定のコンフィギュレーションを変更するようにさらに構成される、（３０）に記載のコンピュータ。
（３２）複数のサイズ・レポートを有するサイズ・レジストリをさらに有し、各サイズ・レポートは複数のコンポーネントのそれぞれについて固有のものであり、各コンポーネントが機能関連コード部分の集合であり、所与のコンポーネントの各サイズ・レポートは複数のフィールドを有し、それぞれのフィールドがコンピュータ上のコンフィギュレーション可能オプションに固有のものであり、必要メモリ値を有する、（３０）に記載のコンピュータ。
（３３）コンフィギュレーション・マネージャは、少なくとも、
レジストリにアクセスし、
複数のコンフィギュレーション可能オプション固有の値に達するように各サイズ・レポート内の各対応コンフィギュレーション可能オプションの必要メモリ値のそれぞれを合計し、
複数のコンフィギュレーション可能オプション固有の値のそれぞれに、特定のコンフィギュレーションに固有のものであるコンフィギュレーション乗数を掛け合わせる、
ことでロジカル・パーティション・マネージャが必要とする量のメモリが特定のコンフィギュレーションに使用可能であるかどうかを判定する、（３０）に記載のコンピュータ。
【図面の簡単な説明】
【００５６】
【図１】ロジカル・パーティション・コンピュータを含む複数コンピュータのネットワークを示すブロック図である。
【図２】その一部をパーティショニングすることができる複数ハードウェア・リソースを示すコンピュータのブロック図である。
【図３】ロジカル・パーティション・コンピュータのブロック図である。
【図４】パーティション・マネージャの必要なメモリを決定するように構成されたロジカル・パーティション・システムのソフトウェア・コンポーネントを示す図である。
【図５】パーティション・マネージャ用の必要なメモリを計算するための一実施形態を示す図である。
【符号の説明】
【００５７】
３１２  パーティション・マネージャ
３１４、３１６  ディスパッチ不能パーティション・マネージャ
４０２  ＩＰＬマネージャ
４０４  ハードウェア・マネージャ
４０６  コンフィギュレーション・マネージャ
４０８  コンフィギュレーション・ユーザ・インターフェース
４１０  サイズ・カルキュレータ
４１２  コンポーネント・サイズ・レジストリ
４１４Ａ  コンポーネントＡのサイズ・レポート
４１４Ｂ  コンポーネントＢのサイズ・レポート
４１４Ｃ  コンポーネントＣのサイズ・レポート
４１４Ｎ  コンポーネントＮのサイズ・レポート
４１６  マスタ・サイズ・レポート
４２０  カウント・レポート
４２２  デルタ・レポート
【図１】
2004318841.tif 000006
【図２】
2004318841.tif 000007
【図３】
2004318841.tif 000008
【図４】
2004318841.tif 000009
【図５】
2004318841.tif 000010