JP2006302305A - 非一様メモリ・アクセス・マルチプロセッサ・システム用オペレーティング・システム - Google Patents

Abstract

【課題】最も効率的なレベルの親和性を維持し、プロセッサおよびメモリ負荷の均衡化を維持する階層ツリー構造を表わす、非一様メモリアクセス（ＮＵＭＡ）システムのソフトウエア抽象概念を利用する、オペレーティング・システムを提供すること。
【解決手段】階層ツリー構造は、ジョブ・プロセッサを表わすリーフ・ノードと、全てのジョブ・プロセッサによって共有されるルート・ノードと、複数の中間レベル・ノードとを含む。オペレーティング・システムは、アクティブなスレッド群の進展を監視し、衰退スレッド群を補助する中期スケジューラと、関連するジョブ・プロセッサの状態を監視し、関連するジョブ・プロセッサが実行するためのスレッド群を得る複数のディスパッチャとを含む。更に、オペレーティング・システムは、複数のメモリ・プールおよびフレーム・トレジャリを用いて仮想および物理メモリを割り当てるメモリ・マネージャも含む。
【選択図】図１

Description

本発明は、一般的にコンピュータのオペレーティング・システムに関し、更に特定すれば、非一様メモリ・アクセス(NUMA:non-uniform memory access)マルチプロセッサ・システム用オペレーティング・システムに関するものである。

スレッド(thread)は、多数の非同期タスクの効率的な制御を容易にする、プログラミング構造である。スレッドは基礎となるハードウエアに密接に対応するので、対称的なマルチプロセシング・システム上で実行されるアプリケーションに、平易なプログラミング・モデルを与える。

最近のマルチプロセシング・システムは、処理タスクを共有するいくつかの別個のジョブ・プロセッサ(JP)を有することができる。かかるシステムの多くは、キャッシュを内蔵し、このキャッシュをシステムのＪＰの部分集合が共有する。しかしながら、多くの従来技術のマルチプロセッサ・システムに伴う問題の１つに、システム上で実行中のプロセスが、その実行中に、多数の処理スレッドを生成するときのＪＰおよびキャッシュの親和性が不十分(poor)であることがあげられる。従来技術のシステムには、各スレッドに個々の優先度を割り当て、各スレッドをシステム全体で汎用的に別個にスケジュールするものがある。また他のシステムには、個々のスレッドを個々のＪＰに親和化(affine)できるものもある。同一データにアクセスする傾向がある、多数の関係するスレッドを、多数のＪＰ群に分散すると、システムのキャッシュ内外において、望ましくない高いレベルのデータ交換(data swapping)が発生する可能性がある。
Robert A. Alfieriにより、１９９４年１月２６に出願され、本願と共に譲渡された、"APPARATUS AND METHOD FOR IMPROVED CPU AFFINITY IN A MULTI-PROCESSOR SYSTEM"と題する米国特許出願番号第０８／１８７，６６５号

この文献の発明は、同一プロセスからの関係があるスレッド群をＪＰ群に親和化し、二次的なキャッシュの親和性を改善しつつ、同一群内のスレッド間の処理効率を高め、群間の処理のオーバーヘッドを減少させる方法を開示する。この開示内容は、この言及により、本願にも含まれるものとする。先の開示された方法は、更に、親和性を自動的に修正し、局所的な効率を維持しつつ、関係のあるスレッド群を移動させる。マルチプロセッサ・システム全体にわたってプロセッサ負荷の均衡を取るために、開示された方法は、全てのアクティブなスレッド群を、システム・アーキテクチャ内で最高で最もよく見える(visible)レベルに昇進させることによって、周期的に負荷の均衡化を行う。

ＮＵＭＡアーキテクチャを有するスケーラブル・マルチプロセッサ・システムに実施可能な、グローバル・スケジューリング機構を有するオペレーティング・システムに対する必要性が存在する。また、ＮＵＭＡシステムを抽象化し、コスト・トレードオフを管理し、資源アクセス・コストを考慮に入れたポリシおよび機構を実施しつつ、システムの資源全体に作業負荷を分散させる方法に対する必要性も存在する。加えて、アドレスが透過なメモリの移動、およびＮＵＭＡマルチプロセシング・システムの種々のメモリ資源の継ぎ目のない一体化を支援する、メモリ・マネージャを有するオペレーティング・システムに対する必要性も存在する。

したがって、本発明は、上述の問題を克服しようとするものである。本発明のオペレーティング・システムの一態様は、システムのスループットを向上し、プロセスとジョブ・プロセッサとの間に緊密な親和性を保持する、局在性管理機構(locality management mechanism)を提供することである。この利点およびその他の利点を達成するため、そしてここに具現化され広く述べられる本発明の目的によれば、本発明のオペレーティング・システムは、マルチプロセッサ・システムのハードウエア・アーキテクチャの抽象概念を維持する手段を含む。抽象概念は、プロセッサおよび共有される資源の物理的構成を、階層的ツリー構造という形態で表わす。階層的ツリー構造は、プロセッサに対応し、階層的ツリーの最下位レベルに位置付けられる複数のリーフ・ノード(leaf node)と、全てのプロセッサによって共有される共通資源および共有される中間資源に対応し、階層ツリーの最高レベルに位置付けられるルート・ノード(root node)と、共有される中間資源に対応し、階層ツリーの少なくとも１つの中間レベルに位置付けられる複数の中間ノードとを有する。階層ツリーの各ノードに実行キュー(run queue)を確立するための手段が設けられる。各実行キューは、リーフ・ノードと関連付けられ、対応するプロセッサに親和化されたアクティブなプロセスまたはスレッド群を識別する。残りのノードの１つと関連付けられた各実行キューは、当該ノードに関連付けられた資源を共有するプロセッサ群に親和化されたアクティブなプロセッサを識別する。更に、プロセッサの動作を監視し、実行キュー内に並んでいるプロセスを選択し、プロセッサに実行させる手段も設けられる。

本発明のオペレーティング・システムの別の態様は、システムのスループットを向上させつつ、システム全体で均衡の取れたプロセッサ負荷を維持する、グローバル・スケジューリング機構を提供することである。この利点およびその他の利点を達成するために、本発明のオペレーティング・システムは、マルチプロセッサ・システムのハードウエア・アーキテクチャの階層的ツリーの抽象概念を維持する手段と、システム内のアクティブなプロセスの進展を監視し、進展していなかったプロセスをより速く実行させる可能性を高める手段とを含む。本発明のオペレーティング・システムの更に他の態様は、システムにおいてプロセスが衰退しないことを保証するように協動する、グローバルおよびローカル・スケジューリング機構を提供することである。

この利点およびその他の利点を達成するために、本発明のオペレーティング・システムは、プロセッサの各々と関連付けられ、関連するプロセッサの実行キューを監視し、他のプロセッサの実行キューから、関連するプロセッサに実行させるためのプロセスを探し獲得するディスパッチャと、システム内のアクティブなプロセスの進展を監視し、進展していないプロセスにフラグをセットする、中期スケジューラとを含む。前記ディスパッチャが、複数の入手可能なプロセスを有する実行キューを発見したとき、ディスパッチャは、フラグがセットされているプロセスを選択する。

本発明の他の実施例によれば、システム内における各アクティブなプロセスの進展を監視し、所定時間期間の間進展していない各アクティブなプロセスの優先度を高める中期スケジューラと、プロセッサの１つと関連付けられ、関連するプロセッサによって実行されるプロセスを並べた実行キューを監視し、関連するプロセッサに実行させるために、前記実行キュー内で最も優先度の高いアクティブなプロセスを選択する、少なくとも１つのディスパッチャとを含むオペレーティング・システムによって、上述の態様は達成可能である。

本発明の更に他の態様は、あるプロセスの親和性が変化したか否かを判定し、プロセスのホーム親和性(home affinity)を変更すべきか否かを判定する、動的データ構造機構を提供することである。この利点およびその他の利点を達成するために、本発明のオペレーティング・システムは、マルチプロセッサ・システムのハードウエア・アーキテクチャの階層ツリー構造の抽象概念を維持する手段と、階層ツリーの各ノードに対する実行キューを形成する手段とを含む。リーフ・ノードと関連付けれらた各実行キューは、関連するプロセッサに親和化されたアクティブなプロセスを識別し、残りのノードの１つと関連付けれた各実行キューは、当該ノードと関連付けられた資源を共有するプロセッサ群に親和化されたアクティブなプロセスを識別する。抽象概念は、階層ツリーのレベルの１つをスケジューリング・レベルとして定義し、スケジューリング・レベル内のノードをスケジューリング・ロカール(scheduling locale)として識別する。マルチプロセッサ・システム内の各アクティブなプロセスまたはスレッド群は、ホーム・スケジューリング・ロカールと、現スケジューリング・ロカールとを有し、各々スケジューリング・ロカールの１つに対応する。プロセスのホーム・スケジューリング・ロカールは、当該プロセスを実行するために好適なプロセスの祖先であるスケジューリング・ロカールである。スレッド群の現スケジューリング・ロカールは、プロセスを最後に実行した、または現に実行中のプロセッサの祖先であるスケジューリング・ロカールである。

本発明の更に別の態様は、ＮＵＭＡシステムにおいて継ぎ目なく物理メモリを割り当てるためにデータ構造を利用することである。この態様を達成するために、本発明のオペレーティング・システムは、マルチプロセッサのハードウエア・アーキテクチャの階層ツリー抽象概念を維持する手段を含む。オペレーティング・システムは、更に、共有物理メモリ資源を表わす各ノードにおいてフレーム・トレジャリ(frame treasury)を維持しフレーム管理および資源の割り当てを制御し、全ノードに共通なノードを識別する手段も含む。トレジャリと関連付けられるのは、プロセッサの少なくとも１つが使用するために、フレーム・トレジャリから物理メモリのフレームを割り当てる高位ポリシ・ノードである。

本発明の他の態様は、ＮＵＭＡシステムにおいて仮想メモリを割り当てるために多数の独立したメモリ・プールを利用することである。この態様を達成するために、本発明のオペレーティング・システムは、マルチプロセッサ・システムのハードウエア・アーキテクチャの階層ツリー抽象概念を維持する手段と、システムの仮想メモリの割り当てのために、メモリ・ロカールを表わす各ノードにおいてメモリ・プールを維持する手段と、メモリ単位及び該メモリ単位の各々に割り当てられているメモリ・プールの可用性を識別するプール単位テーブルを維持する手段とを含む。前記仮想メモリは、メモリ・プールに割り当て可能なプール単位に分割されている。

本発明の特徴および利点は、書面にした説明および特許請求の範囲、ならびに添付図面において特に指摘した手段および組み合わせによって実現し、獲得することができる。また、添付図面は、本明細書に組み込まれ、その一部を構成し、本発明のいくつかの実施例を例示し、本発明の目的、利点、および原理を説明するのに供するものである。

ハードウエア・システムの概要
図１は、本発明のオペレーティング・システムを実施することができる、ＮＵＭＡマルチプロセッサ・システム２０の一例を示す。提示を明確かつ容易にするために、ＮＵＭＡマルチプロセッサ・システム２０は、８個のジョブ・プロセッサ（ＪＰ）１〜８を含むものとして描いてある。当業者には容易に認められようが、本発明は、他の数のＪＰを有するＮＵＭＡマルチプロセッサ・システムにも適用可能である。また、各ＪＰ群が２つずつ構成要素を有すること、または全てのＪＰ群が同一数のＪＰを有することは必須ではない。本発明は、メモリ・アクセス時間がシステム全体で等しいが、ローカル・バスの帯域の使用を均衡化することを望む、ＵＭＡシステムにも適用可能である。

ここで使用し記載するＮＵＭＡシステムは、分散型メモリを有するシステムであって、メモリの各部分は、あるＪＰには他のものよりも緊密である（アクセスが安価である）が、全てのメモリ資源は全てのＪＰにアクセス可能なシステムである。したがって、ＮＵＭＡオペレーティング・システムは、引用の局在性に対する感度を高め、メモリ配置(memory placement)を明示的に管理することによって、理想的な性能を達成することが好ましい。

各ＪＰ１〜８は、個別の第１キャッシュ（図示せず）を有し、通常、これは少なくとも別個のデータおよび命令キャッシュを含み、各キャッシュは、例えば、８Ｋバイトのランダム・アクセス・メモリである。命令およびデータ・キャッシュ構成物であるこれら第１キャッシュに加えて、例えば、１メガバイトのランダム・アクセス・メモリから成る付加的なキャッシュ・メモリも、典型的なシステムには、第１キャッシュの一部として含まれている場合がある。図１に示した例では、各ＪＰ対、即ち、ＪＰ群は、第２キャッシュ１０〜１３のような１つ以上の共有メモリ資源に接続することができる。例えば、ＪＰ１および２を第２キャッシュ１０に接続し、ＪＰ３および４を第２キャッシュ１１に接続し、ＪＰ５および６を第２キャッシュ１２に接続し、ＪＰ７および８を第２キャッシュ１３に接続することができる。加えて、共有メモリ資源１０および１１を互いに接続したり、あるいはノード１４において、第３キャッシュのような他の１つ以上の共有資源に接続することもでき、更に共有メモリ資源１２および１３も、１つ以上の共有資源１５に接続することができる。あるいは、共有資源１４および１５を、システム・バスまたはインターフェースとしてもよい。共有資源１４および１５は、付加的な共有メモリおよび／または主システム・バス１６のような、１つ以上の共通共有資源に接続することができる。したがって、図１に示すように、共有資源を表わす各ボックスは、１つ以上の共有資源を表わす場合もある。しかしながら、ＮＵＭＡシステムであるためには、ノード１０〜１３または１４〜１５にメモリがなければならない。

図１に示すようなＮＵＭＡマルチプロセッサ・システムは、非対称的アーキテクチャを有し、共有資源１０〜１３の各々が異なるメモリ量を有するようにしてもよい。更に、ＪＰ１〜８は、異なる処理能力を有してもよい。加えて、ハードウエアは、その鍵となる共有資源が階層的システム抽象概念によって適切に表現可能である限り、１つの階層として組織化する必要もない。例えば、ハードウエアは、メッシュに基づくシステム組織(mesh-based system organization)を有することも可能である。システム全体にわたってこれらの種々の構成物を扱い、異なるハードウエア構成物の継ぎ目のない一体化を可能にするために、本発明のオペレーティング・システムは、ＮＵＭＡマルチプロセッサ・システムの抽象概念を利用する。これについては、後に更に詳細に説明する。
オペレーティング・システム
図１に示したようなマルチプロセッサ・システムでは、オペレーティング・システム（またはカーネル）は、通常、ジョブ・プロセッサおよび／または専用システム・プロセッサ上で実行される、種々のプロセスまたは方法を含む。以下に述べるオペレーティング・システムの構成物は、オペレーティング・システムによって実行されるプロセスのいくつかのことを指す。

図２は、非一様メモリ・アクセス（ＮＵＭＡ）マルチプロセッサ・システム２０のオペレーティング・システムによる、ソフトウエア抽象概念１５０の概要を示す。オペレーティング・システムは非一様メモリ・アクセス（ＮＵＭＡ）マルチプロセッサ・システム２０において実施可能である。リーフ・ノード(leaf node)１００〜１０７はそれぞれＪＰ１〜８を表わし、ノード１１０〜１１３は、共有メモリ、バス、および／または第２キャッシュ１０〜１３をそれぞれ表わし、ノード１１４および１１５は、共有バス／相互接続部１４および１５のような、共有資源を表わし、ルート・ノード１２０は、共有資源１４および１５等を接続する主システム・バス１６のような共通共有資源を表わす。

本発明のオペレーティング・システムは、種々のハードウエア・アーキテクチャを有するＮＵＭＡマルチプロセッサ・システムに常駐し、これを制御できるように柔軟に設計されているので、オペレーティング・システムが利用するハードウエア・アーキテクチャの抽象概念は、システムによって異なる。しかしながら、以下に述べるように、オペレーティング・システムは、種々のポリシを利用して、ハードウエア・アーキテクチャの適切な抽象概念を確立し、システムの処理を最も有効に管理する。

各ＪＰ１００〜１０７毎に、オペレーティング・システムは、実行キュー(run queue)およびディスパッチャ(dispatcher)を含む。ディスパッチャは、あるグローバルおよびローカル・スケジューリング・ポリシにしたがって、関連するＪＰ上でのプロセスのスケジューリングおよび実行を担う機構である、カーネル・サブシステム(kernel subsystem)である。スケジューリング・ポリシのセットする役割を担う、オペレーティング・システム内の他のカーネル・サブシステムを、以後、中期スケジューラ(meidum term scheduler)と呼ぶ。これは、ディスパッチャが処理するスケジューリング機構に影響を与える。ディスパッチャおよび中期スケジューラのスケジューリング処理については、「スレッド群」の背景説明に続いて、以下で説明する。尚、スレッド群は、オペレーティング・システムがそのポリシ作成決定のいくつかの基準とするスレッドの群を表わす。しかしながら、オペレーティング・システムは、以下に説明するような、多数のスレッドを有するスレッド群上だけでなく、単一プロセス（即ち、単一スレッドを有するスレッド群）上でも動作可能であることは、理解されよう。
スレッド群
ここで開示する「スレッド群」とは、同一データにアクセスし処理する傾向のある、プロセス内で、緊密な関係にあるスレッドの集合のことである。これら関係の有るスレッドを、単一の全体的にスケジュール可能な群として扱うことにより、当該群内のスレッドと個々のＪＰまたはＪＰ群との間に、より密接な関係を増進し、これによって、キャッシュのヒット率およびシステム全体の性能が向上することになる。

図３を参照すると、システム２０上で実行される典型的なプロセス２００の図を示してある。プロセス２００は、スレッド群２１０、２２０、および２３０を含む。ＴＧ２１０は、リアル・タイム（ＲＴ）スレッド群であり、プロセス２００における最初のスレッド群であった。ＴＧ２１０は、スレッド群構造（ＴＧＳ）２１１を有し、そのスレッド群の中に、３つのタイムシェアリング（ＴＳ）スレッド２１２〜２１４を有する。ＴＧ２２０は、スレッド群構造２２１と、ＲＴスレッド２２２および２２３とを有する。ＴＧ２３０は、スレッド群構造２３１と、ＲＴ２３２と、ＴＳ２３３とを有する。以下でより詳細に論ずるが、図３の各スレッド群構造ボックス２１１、２２１および２３１に示す数は、システムに全体おける各スレッド群のグローバル・スケジューリング優先度を示す。各スレッド・ボックスの中に示す数は、その特定スレッド群の中における、スレッドの優先度を示す。

また、図３のプロセス２００の中に概念的に配置してあるのは、データ集合２４０であり、プロセス２００の実行中に、スレッドがアクセスする潜在的必要性があるものである。図３において、データ２４１は、ＴＧ２１０内のスレッドが実行すべきタスクを支援するデータ２４０の副集合を表わす。同様に、データ２４２および２４３は、ＴＧ２２０および２３０内のスレッドが実行すべきタスクを支援する。

プロセスの中のアクティブなスレッドは、１つ以上の付加的なスレッドを生成することができる。新たなスレッドが生成されるとき、それは、生成元のスレッドのスレッド群内で生成されるか、他の既存のスレッド群内で生成されるか、あるいは、新たなスレッド群の最初のスレッドとなることもできる。例えば、ＴＧ２２０は、プロセス２００内のスレッドによって、またはシステム内の他のプロセス内のスレッドによって生成されたものとすることができる。あるスレッドが新たなスレッド群内の最初のスレッドとして形成される場合、新たなスレッド群のスレッド群構造は、まず、生成したスレッドのスレッド群のスレッド群構造を受け継ぐことによって生成される。次いで、新たに生成されたスレッド群において、新たなスレッドが生成される。生成元のスレッドは、新たに生成されたスレッドに、ローカル・スケジューリングおよび優先度を割り当てる。他に指定がない場合は、新たに生成されたスレッドは、それを生成したスレッドのローカル・スケジューリング・ポリシおよび優先度を受け継ぐことになる。新たに生成されたスレッドは、それを生成したスレッドよりも高い、低い、または同一の優先度を有することができる。同様に、あるスレッド群内の個々のスレッドは、そのスレッド群の優先度よりも高い、低い、あるいは同一の優先度を有することができる。

スレッド群構造は、そのスレッド群内の全スレッドについて、累積タイムスライス(timeslice)およびＪＰ課金(accounting)も維持するので、スレッド群内の個々のスレッドについて、タイムスライス処理およびＪＰ課金の記録は不要である。スレッド群内の個々のスレッドは、各々、それ自体のスレッド優先度およびスケジューリング・ポリシを保持する。

実行すべきスレッド群を選択する際に、ＪＰのディスパッチャが用いる、特定の方法について以下に論じる。一旦ディスパッチャが実行のために特定のスレッド群を選択したなら、ディスパッチャは当該スレッド群から１つのスレッドを選択し、その群内のスレッドの局所的優先度およびスケジューリング・ポリシに基づいて実行する。したがって、スレッドの選択および実行は、２つの独立したレベルで行われる。即ち、スレッド群のグローバル・スケジューリング、これに続く、当該スレッド群のスレッドの１つのローカル・スケジューリングである。あるスレッド群の中の個々のスレッドの優先度は、当該スレッド群自体のスケジューリングには何等関係がない。スレッド群のスケジューリングは、スレッド群構造におけるスレッド群の優先度に基づいている。

プロセスの実行には、各々複数のスレッドを有する複数のスレッド群がしばしば関与する。プロセスの開発においてスレッド群を使用することにより、既存のスレッド群内で新しいスレッドを生成することと、新しいスレッド群を生成することの間で選択を行う柔軟性をユーザに与えることになる。ユーザは、当該プロセス内の種々のタスクを処理するための最も効率的な手法に基づいて、決定を下すことができる。例えば、多数のスレッドを用いて特定の計算に関する作業を行っており、全てのスレッドが同一データ集合へのアクセスを必要とする場合、これらのスレッドを単一のスレッド群に属させるのが正しい。一方、プロセスの進行中に当該プロセス内で新たなタスクを開始するが、このタスクが既存のスレッド群のタスクとは密接に結び付かず、しかも新たなタスクのスレッドが異なるデータ副集合２４０へのアクセスを必要とする場合、新たなスレッド群を指示する。
プロセス・スケジューリング
上述のように、オペレーティング・システムは、ハードウエア・アーキテクチャの抽象概念を利用する。これは、共有資源、メモリ・ロカール(memory locales)、およびＪＰの逆ツリー階層として表わすのが好ましい。かかる抽象概念の一例を図２に示す。このＪＰ／メモリ−ツリー階層では、ＪＰを固有のＩＤ番号で識別し、各メモリ・ロカールまたは他の共有資源を、（レベル、ＪＰ−ＩＤ）命名基準によって識別する。ここで、レベルは、階層ツリーにおける垂直位置を特定し（番号が大きいレベル程ツリーのルート・ノードに近く、ゼロ・レベルはツリーのリーフ・ノード即ちＪＰを表わす）、ＪＰ−ＩＤは、所望のロカールのいずれかの子孫ＪＰ(descendent JP)を用いて、水平位置を指定する。例えば、図２において、指定子（２、ＪＰ２）および（２、ＪＰ０）は双方とも同一メモリ・ロカールを指し、一方（２、ＪＰ２）および（２、ＪＰ４）は異なるロカールを指す。各レベルは、１つ以上の「インスタンス」、即ち、ＪＰ／メモリ・ツリー階層におけるノードを含むと考えることができる。レベル０は、８個のノードを含み、各々ＪＰ１００〜１０７の１つに対応する。レベル１は４つのレベル１ノード１１０〜１１３を含み、各ノードは、共有メモリ資源およびその従属ＪＰの１つに対応する。レベル２は２つのレベル２ノード１１４および１１５を含み、各々２つのレベル１ノードおよび共有資源に対応する。最後に、２つのレベル２ノードと少なくとも１つの共有システム資源とに対応する単一のレベル３ノード１２０がある。この命名基準は、多くの場合、システムの各レベルにいくつのノードがあるかを知る必要性から、ソフトウエアを解放するため、実施を簡素化することができる。

階層ツリー構造を用いてシステムのハードウエアを抽象化することの目的は、１つのノードから他のノードへの移動に伴うアクセス・コストの表現を与えることである。例えば、ＪＰ１０１がノード１１０で表わした第２キャッシュから読み取りを行うためのコストは、同じＪＰがノード１１２で表わした第２キャッシュから読み取りを行うためのコストよりも大幅に少ない。これは、ハードウエアのアクセス・レイテンシ(latencies)およびシステム・バスの帯域が制限されていることによるものである。このように、階層ツリー抽象概念群は、ＪＰおよび群の共有資源間の相互作用と関連付けて、最も低いコストを有する共有資源およびＪＰを類別する。

上述のように、あらゆるシステムを同一の抽象概念で表わす訳ではない。例えば、一様メモリ・アクセス・システムでは、全てのＪＰを直接共通の共有メモリに接続する。したがって、各ＪＰが共通メモリにアクセスする際のコストは、他のＪＰの場合と同一であり、全てのメモリは、階層のルート・ノードで表わされることになろう。しかしながら、非一様メモリ・アクセス（ＮＵＭＡ）システムでは、ＪＰのあるものは１つの共有メモリ資源に直接接続され、一方、他のＪＰには他の共有メモリ資源に接続するものもある。更に、１つのメモリ資源に直接接続されるＪＰの数は、他のメモリ資源に接続される数とは異なる場合もある。かかるシステムの階層的抽象概念を与えることによって、オペレーティング・システムは、ＪＰがより緊密に親和化されているローカル・メモリへのアクセスを促進し、アクセス可能性が限られているシステム資源の利用を必要とする場合がある、遠隔メモリ資源へのＪＰのアクセスを制限するようなポリシを確立することができる。

マルチプロセッサ・システムの抽象概念を構成するためには、２つの競合するシステムの目標を調和させる必要がある。一方では、ＪＰにできるだけ効率的にプロセスを実行させなければならない。他方では、システムのスループットを最大限高めなければならない。図２を参照して、レベル３において「可視」である全スレッドは、８つのＪＰ１００〜１０７のディスパッチャのいずれかが選択し実行することができる。レベル３のスレッドを潜在的に実行可能なＪＰは８つあるので、これは各スレッドを実行する機会を最大に高める。しかしながら、こうすると、結果として、同じスレッド群からのスレッドが異なるＪＰ群（即ち、ＪＰ１００および１０１、ＪＰ１０２および１０３、ＪＰ１０４および１０５、またはＪＰ１０６および１０７）において実行されることになる。多数のスレッド群からのスレッドがＪＰ群全体に分散し、その結果キャッシュの動作が増大するため、システムのスループットが低下する。

一方、全スレッド群が特定のＪＰに割り当てられるとすると、全スレッドが同一ＪＰ上で処理される同一データ集合上で作用するため、キャッシュ・ヒットの可能性が高くなるため、明らかに局所的なキャッシュ親和性が高くなる。しかしながら、複数の時間的制約が厳しいスレッド(time critical thread)を単一のＪＰに割り当てると、ＪＰがビジー状態となり、全ての時間的制約が厳しいスレッドをスケジュール通りに実行できなくなる可能性が高まるため、望ましくない。

上述のように、本オペレーティング・システムの好適実施例では、２つのスケジューリング・レイヤ(layer)がある。全スレッド群は群優先度を有し、中期スケジューラによってスケジュールされることにより、抽象化システム１５０内のどこでも利用可能なＪＰ資源を得るために競うことができる。一旦あるＪＰディスパッチャが実行すべきスレッド群を選択したなら、このディスパッチャは、当該スレッド群内の局所的優先度にしたがって、このスレッド群内から１つのスレッドを選択する。

再び図３を参照し、スレッド群およびスレッドの優先度について調べる。図からわかるように、スレッド群の優先度は、当該スレッド群内の個々のスレッドの優先度より、高い場合も低い場合も有り得る。図３のプロセス２００の例では、ＴＧ２１０には９００という優先度が割り当てられ、ＴＧ２２０は８１０という優先度を有し、ＴＧ２３０は５００という優先度を有する。例えば、スレッド群２１０、２２０および２３０のみが、偶然システム１５０でアクティブなスレッド群であるとすると、ＴＧ２１０は利用可能なスレッド群の中で最も高い優先度を有するので、次に利用可能なＪＰのディスパッチャは、次に実行すべきスレッド源として、ＴＧ２１０を選択する。

一旦ディスパッチャがＴＧ２１０を選択したなら、このディスパッチャは、同じスレッド群の実行キューから、実行すべき特定のスレッドを取り出す。ＴＧ２１０のアクティブなスレッド２１２〜２１４は、それぞれ、４０５、４０５および４００の優先度を有する。スレッドは、その優先度の順に、それらの実行キューに配置される。実行キュー内で等しい優先度のスレッドの順は、ローカル・スケジューリング・ポリシによって決定される。

あるスレッドが必要とするデータが、このスレッドを実行するＪＰ自体のキャッシュ内で見つけられる可能性を最大に高め、そこにない場合、当該ＪＰのＪＰ群と関連付けられている第２キャッシュ内で見つけられる可能性を最大に高めることが非常に望ましいことはよく理解されよう。高位レベルの共有メモリに移動して、キャッシュにないデータを得ようとすると、スレッドの処理に遅れを来し、システム全体のスループットに影響を与える。同様に、近くのメモリではなく遠くのメモリにアクセスすることによっても、遅れを生じる。同時に、キャッシュ局在性を高めるために行われるステップは、時間制約が厳しいスレッドの処理の適時実行に影響を与える可能性はない。

各スレッド群と関連付けられ、システム内の全ＪＰに利用可能なものに、スレッド群の利用可能なＪＰまたはＪＰの集合、およびスレッド群の最低許容処理レベルを指定する属性がある。ＪＰ属性は、システム内でスレッド群の実行が許されているＪＰまたはＪＰの集合を識別する。典型的に、この属性は、システム１５０内の全ＪＰを利用可能として識別するが、システムのＪＰの部分集合はユーザが指定する。最低許容処理レベル属性は、スレッド群を親和化できる最低処理レベル（０、１、２、または３）を指定する。この属性は、リアル・タイム・スケジュール・セマンティクス(real time schedule semantaics)のために、プロセッサ親和性ポリシを無視する際に用いることができる。

タイムシェアリング・スレッド群に対する最低許容処理レベルは、典型的に０である。こうすることによって、スレッド群をレベル２に低下させ、レベル２で第３キャッシュを共有する４つのＪＰから成る特定群に、このスレッド群をレベル１で親和化したり、レベル１に低下させて、第２キャッシュを共有する２つのＪＰから成る特定群にスレッド群を親和化させたり、あるいはレベル０に低下させて、スレッド群を特定のＪＰに親和化させることができる。スレッド群を特定のＪＰまたは単一のＪＰ群に親和化させることにより、当該スレッド群内のスレッドに対するキャッシュ局在性が改善されることになる。

リアル・タイム・スレッド群の最低許容処理レベルは、典型的に、ルート・レベル（本例ではレベル３）であり、スレッド群を最高処理レベルより下に移動させないようにすることにより、スレッド群が常に最大数のＪＰに利用可能であるようにする。したがって、リアル・タイム・スレッド群に対する応答時間は最適化される。ユーザは、最低許容処理属性を通じて、リアル・タイム・スレッド群をレベル２、レベル１、またはレベル０に移動させるように、指定することができる。

本発明の好適実施例では、スレッド群および処理インスタンス間における親和性の維持は、システム実行キューによって行うようにしている。図２に示す抽象化システムには、合計１５の実行キューがある。即ち、８つのレベル０列（各ＪＰに１つずつ）、４つのレベル１列、２つのレベル２列、および１つのレベル３列である。全ての利用可能なスレッド群は、これら１５の列の１つにあり、その１つにしかない。新たに生成されるスレッド群は、生成元のスレッド群の実行キューおよびその親和性属性を受け継ぐ。

例えば、図３を参照して、ＴＧ２３０が最初に生成されると、その生成元の親和性を受け継ぎ、生成元のスレッド群に対応するロカールの実行キューに配置される。ＴＧ２３０はタイムシェアリング・スレッド群であるので、ＪＰ１００〜１０７の１つが、最初に実行すべきものとしてそれを選択した場合、ＴＧ２３０は、それを選択したディスパッチャと関連付けられた特定のＪＰに「引き下げられる」。選択元のディスパッチャは、当該スレッド群をレベル３実行キューから取り出し、それ自体のレベル０実行キューに配置することによって、これを達成する。この時点で、当該ＪＰはＴＧ２３０と親和化されており、ＴＧ２３０が再度親和化されるか、或いは実行キューがリセットされるまで、ＴＧ２３０内のスレッドを実行し続ける。これについては、以下で論じることにする。ディスパッチャは、実行キューを維持する。実行キューは、ＪＰ／メモリ・ツリー階層の各ノードについて、特定ノードに存在するロード可能なスレッド群のリストを含む。ディスパッチャは、それに関連するノードの固有の命名基準によって、実行キューを識別することができる。

ＮＵＭＡアーキテクチャを有するシステムにおいて、グローバル・スケジューリング機構を設けるには、階層ツリーにおけるあるレベルを、「スケジューリング・レベル」として選択する。「スケジューリング・レベル」は、中期スケジューラがそのスケジューリング処理を実行する、階層ツリーにおけるレベルのことである。スケジューリング・レベルにある階層ツリーの各ノードを、「スケジューリング・ロカール」と呼ぶ。スケジューリング・ロカールおよびその子ノード(child node)を、「スケジューリング・サブツリー」と呼ぶ。例示の目的のために、図２に示す階層ツリーにおいて、レベル２をスケジューリング・レベルとすると、ノード１１４および１１５はスケジューリング・ロカールとなり、ノード１１０、１１１、および１１４は、１つのスケジューリング・サブツリーに属し、ノード１０４〜１０７、１１２、１１３、および１１５は別のスケジューリング・サブツリーに属する。一方、レベル１がスケジューリング・レベルとすると、ノード１１０〜１１３がスケジューリング・ロカールとなり、ノード１００、１０１、および１１０が１つのスケジューリング・サブツリーに属し、ノード１０２、１０３、および１１１が別のスケジューリング・サブツリーに属し、ノード１０４、１０５、および１１２が１つのスケジューリング・サブツリーに属し、そしてノード１０６、１０７、および１１３が別のスケジューリング・サブツリーに属する。

階層ツリーにおけるどのレベルでも、スケジューリング・レベルとして選択することができる。しかしながら、どのレベルをスケジューリング・レベルに選択するしても、選択したレベルは、スケジューリングのためのローカル・メモリ・レベルと看做される。したがって、スケジューリング・レベルの選択は、ＪＰ／メモリ親和性に影響を及ぼし、プロセスを１つのノードから別のノードに移動させるためのコストを割り当てる基準を設ける。これについては、以下で更に詳細に説明する。

階層ツリー内のあるレベルをスケジューリング・レベルに指定し、スケジューリング・レベル内のノードをスケジューリング・ロカールに指定することの重要な一面は、スレッド群を、「ホーム・スケジューリング・ロカール(home scheduling locale)」および「現スケジューリング・ロカール(current-scheduling locale)」に割り当てることができるようになることである。スレッド群またはプロセスの「ホーム・スケジューリング・ロカール」は、当該スレッド群またはプロセスを実行するための好適なＪＰの祖先ノード(ancestor node)である、スケジューリング・ロカールである。スレッド群の「現スケジューリング・ロカール」は、当該スレッド群を最後に実行したＪＰの祖先ノードである、スケジューリング・ロカールである。スレッド群は、その現スケジューリング・ロカールとは異なるホーム・スケジューリング・ロカールを有することもできる。かかる状況が発生するのは、スレッド群を１つのスケジューリング・サブツリーから他のスケジューリング・サブツリーに移動し、適格なスレッド群を有さないＪＰをビジーの状態に保持するようなときである。しかしながら、ＪＰ／メモリ親和性を向上させるためには、スレッド群は同一のホームおよび現スケジューリング・ロカールを有することが好ましい。なぜなら、各スケジューリング・ロカールは、異なる物理的メモリを表わし、ＪＰは、局所的資源を使用すれば、より効率的に処理を行うからである。

中期スケジューラは、スレッド群を監視して、衰退スレッド群(languishing thread group)および負荷均衡化のための候補を識別し、それぞれのスケジューリング・ロカールの負荷を監視してあらゆる負荷不均衡を識別し、現スケジューリング・ロカールとホーム・スケジューリング・ロカールが同一でない全スレッド群を識別することによって、ＪＰ／メモリ親和性とシステムのスループットのトレードオフとの均衡を取る。ホーム・スケジューリング・ロカールとは異なる現スケジューリング・ロカールを有するスレッド群を、中期スケジューラが識別したとき、中期スケジューラは、（ａ）当該スレッド群をホーム・スケジューリング・ロカールに戻すことによって、それをホームに送る、（ｂ）そのホーム・スケジューリング・ロカールを変更し、その現スケジューリング・ロカールに一致させることによって、スレッド群を「移行(migrate)」させる、または（ｃ）そのホーム・スケジューリング・ロカールを変更することなく、スレッド群をその現スケジューリング・ロカールに放置する。

中期スケジューラが衰退しているスレッド群を識別したときは、以下の３つの方法の内の１つで当該スレッド群を補助することができる。第１に、このスレッド群の優先度を高めて、このスレッド群を含む実行キューのＪＰディスパッチャがこのスレッド群を選択し実行する可能性を高める。第２に、中期スケジューラは、より高いノードの実行キューにスレッド群を「昇進」させ、他のＪＰに対するその可視性を高める。第３に、中期スケジューラは、当該スレッド群と関連付けられた侵入／補助ヒント・フラグ(poach/help hint flag)をセットし、このスレッド群を、ＪＰが「侵入する」または「補助する」のに適したスレッド群であるとして識別する。「侵入」または「補助」が行われるのは、あるスケジューリング・サブツリー内のアイドル状態のＪＰと関連付けられたディスパッチャが、他のスケジューリング・サブツリーのノードにおいて衰退スレッド群を引き出したときである。「衰退スレッド群」は、実行されることなく、８００ｍｓｅｃのような所定時間期間にわたって実行キューの中で待たされているスレッド群のことである。衰退スレッド群が、遠くのスケジューリング・サブツリー内のＪＰによって実行されているスレッドを有する場合、アイドル状態のＪＰのディスパッチャが、このスレッド群の中で最高の優先度を有するスレッドを選択して実行することにより、このスレッド群を「補助する」。それ以外の場合、ディスパッチャは、このスレッド群全体を占領することによって、このスレッド群に「侵入する」。スレッド群が「侵入」されると、当該スレッド群の現スケジューリング・ロカールは、侵入したディスパッチャのそれに変更させられる。スレッド群が「補助」されるときは、当該スレッド群の現スケジューリング・ロカールは、スレッド群が最初に配置されたスケジューリング・サブツリーのスケジューリング・ロカールに留り、補助されるスレッド群は、そのスレッド群が実行された後、その最初の位置に戻される。

図４〜図７は、ＪＰ１００のディスパッチャが実行すべきスレッド群（ＴＧ）を選択する際に従うシーケンスを示す。同様のシーケンスは、システム内の全ディスパッチャが従う。ＪＰ１００がスレッドを実行可能となると（ステップ５０１）、そのディスパッチャはまず、第１の所定遅延時間が経過するまで、階層ツリー内のその祖先ノードの実行キューを、特定の順番で検索する。したがって、ディスパッチャ５００は、このプロセスを開始するに当たって、タイマをセットする（ステップ５０３）。

最初にディスパッチャは、そのレベル０実行キューおよびレベル１〜３の祖先ノードにおいて、最高優先度の適格なスレッド群を探す。ＪＰ１００の場合、ディスパッチャは、ノード１００、１１０、１１４、および１２０の実行キューを検索し（ステップ５０５）、適格なスレッド群を探す（ステップ５０７）。ディスパッチャが適格なスレッド群を見つけられない場合、予め計算してあるＪＰ１００の関係物(relative)リストにある、次の関係ノード(relative node)を探す。ノードが存在するスケジューリング階層内のレベルは、このレベルの実行キューが検索されるまでに要する遅延量を決定する。このレベルのノードに対するタイマが未だ終了していなければ、ディスパッチャは「アイドル」スレッドを実行し、ＪＰ１００をアイドル状態にする（ステップ５１５）。タイマが終了した場合、ディスパッチャは、ルートが関係物リスト内の次の関係物であった、サブツリー全体を検索し、実行すべきスレッド群を見つける（ステップ５１３）。適格なスレッド群がない場合、ディスパッチャはステップ５０５に戻る。この手順は、ディスパッチャが実行すべき適格なスレッド群を見つけるまで、繰り返される。

アイドル・スレッド群は、それが常に適格であり、常に可能な限り最低のスケジューリング・グローバル優先度を有するという点において、特殊である。ＪＰ１００〜１０７の各々は、その実行キューの中に、アイドル・スレッド群を有する。祖先ノードまたは関係ノードのいずれにも、アイドル群より高い優先度を有する適格スレッド群が含まれていない場合、ディスパッチャはこのスレッド群を抽出し実行する。アイドル・スレッドには遅延が組み込まれており、作業を捜す際に余りに過激になるのを防止するようにしてある。その理由は、キャッシュ・ラインが頻繁に無効化され、その結果システム全体の性能が低下するからである。

ディスパッチャが観測する遅延時間は、階層ツリー内のノードのレベルを基準とする。各レベルは異なる遅延値を有する。これらの値は、機械のアーキテクチャに基づくデフォルト値を用いて構成可能である。通常、ノードのレベルが高い程、遅延も長い。この理論的根拠は、ディスパッチャが検索する関係ノードがツリーの中で高い程、キャッシュ、メモリ位置、およびバス／相互接続境界を交差しているというものである。これは、現在これら遠いノードに関係付けられているスレッド群を実行すると、コスト増になる可能性があることを意味する。

一旦ディスパッチャが、実行すべき適格なスレッド群を有すると思われる実行キューを突き止めたなら、実行キューの適格リスト上にある個々のスレッド群の検索を開始する。まず、ディスパッチャは、実行キューが同一スケジューリング・ツリー内にあるのか、遠いスケジューリング・ツリー内にあるのかを判定する（図５、ステップ５２３）。実行キューがディスパッチャと同一のスケジューリング・ロカールにある場合、ディスパッチャは単に実行キューの適格リストを検索する（ステップ５２５）。このリストは、優先度がアイドル・スレッド群のそれよりも高いスレッド群について、優先度順にソートしてある。受け入れ可能なスレッド群が見つからない場合、ディスパッチャはステップ５０５に戻る。

ディスパッチャが遠いロカールで検索している場合、最初に適格リストを走査して、スレッド群のいずれかに、中期スケジューラが侵入または補助するのに適した候補であるとして印されたものがないかを調べる（ステップ５２７）。もしもなければ、ディスパッチャは優先度に基づいてスレッド群を検索する（ステップ５２５および５２９）。この場合の論理的根拠は、侵入／補助に適した候補として印されているスレッド群は、ある時間にわたって衰退しており、当該スレッド群が遠隔ＪＰ上で実行されると無効になる、ホット・キャッシュ・フットプリント(hot cache footprint)を有する可能性が低いからである。

一旦スレッド群が抽出されると、選択されたスレッド群の中で最高の優先度を有するスレッドを抽出して実行する（図６、ステップ５３３）。次に、ディスパッチャは、選択したスレッド群を新しい実行キューに移動する必要があるか否か判定する（スレッド群がＪＰ１００の実行キューにないとき）（ステップ５３５）。スレッド群がＪＰ１００の実行キュー上で見つかった場合、侵入／補助ヒント・フラグをクリアし（ステップ５３７）、新たなスレッドの実行を開始する（ステップ５３９）。ＪＰ１００の実行キュー上で見つからなかった場合、スレッド群を新たな実行キューに移動する必要がある可能性がある。スレッド群が、他のＪＰが現在実行中の他のスレッドを全く有していない場合（図７、ステップ５４５）、ディスパッチャは、このスレッド群をレベル０の実行キューに移動可能か否かをチェックする（ステップ５５１）。可能であれば、ディスパッチャはこのスレッド群をＪＰ１００の実行キューに移動し（ステップ５５５）、侵入／補助ヒント・フラグをクリアし（図６、ステップ５３７）、実行を開始する（ステップ５３９）。可能でなければ、ディスパッチャは、スレッド群を配置するのを許された最低レベルに一致するレベルを有する祖先ノードの実行キューに、このスレッド群を移動する（図７、ステップ５５３）。

スレッド群が、他に現在実行中のスレッドを有する場合（ステップ５４５）、ディスパッチャは、このスレッド群が現在、祖先ノードの実行キュー上に存在するか否かを判定する（ステップ５４７）。スレッド群が現在祖先ノードの実行キュー上に存在する場合、ディスパッチャは、スレッド群があるところに放置し、侵入／補助ヒント・フラグをクリアし（図６、ステップ５３７）、選択したスレッドの実行を開始する（ステップ５３９）。スレッド群が現在祖先ノードの実行キュー上に存在しない場合、ディスパッチャは、ＪＰ１００の実行キューに対して最下位の共通祖先、および当該スレッド群が現在存在している実行キューを突き止め、スレッド群をその実行キューに移動させる（ステップ５４９）。最下位の共通祖先とは、レベル番号が最も小さい実行キューであり、ＪＰ１００および選択したスレッド群の実行キュー双方の祖先である。例えば、ディスパッチャが、現在ノード１１５に親和化されているスレッド群を実行しようと決定した場合、最下位共通祖先は、ツリーのルート、即ちノード１２０である。最下位共通祖先は、システムの初期化時に予め計算され、ディスパッチャが読み取り可能なデータ構造内に記憶されている。

スレッド群を異なる実行キューに移動する場合で、このスレッド群が他に現在実行中のスレッドを有さないとき、そしてスレッド群が現在存在する実行キューとは異なるロカールに新たな実行キューがある場合、スレッド群の現スケジューリング・ロカールを変更する（ステップ５４３）。これは、ＪＰがスレッド群に「侵入」することに対応する。スレッド群が他に現在実行中のスレッドを有する場合、スレッド群の現スケジューリング・ロカールの修正は行わず、代わりに、ＪＰは単にスレッド群を「補助」する。

これまでの説明から、タイムシェアリング・スレッド群は、システムの３つの処理レベルの間を上下に移動可能であり、様々な時刻に、個々のＪＰ、ＪＰ群、またはシステム内の全ＪＰとの親和化が可能であることが理解されよう。

上述のシステムは、処理負荷の均衡化を行おうとする固有の傾向を有する。システムが比較的アイドル状態の期間にある場合、タイムシェアリング・スレッド群は、ディスパッチャが実行可能なスレッドを検索することによって、より高いレベルの実行キューに引き上げようとする傾向があり、それらのスレッドを多数のＪＰによって共有させる。作業負荷が軽いことを自己認識したＪＰは、それらよりもビジーなＪＰを補助し、いつでもシステム内のよりビジーなＪＰからタイムシェアリング・スレッド群をいくつか引き受けようとする。逆に、システムがビジーになると、タイムシェアリング・スレッド群は、下方向に移動しようとする。このようにタイムシェアリング・スレッド群とＪＰとの間の親和性をより緊密にすると、キャッシュの局在性が改善されるので、望ましい。

殆どの状況では、タイムシェアリング・スレッド群は、ディスパッチャの処理によって、ＪＰ全体にほぼ同様にそれら自体を分散させる。しかしながら、理論的に、ビジーなシステムのスレッド群の分散は不均衡となり、あるＪＰが他のＪＰよりもビジーとなって、あるスレッド群の実行が所望の速度よりも遅くなってしまう可能性がある。

中期スケジューラは、更に、各スケジューリング・ロカールについてスケジューリング・ロカールの負荷データ（ＳＬＤ）を計算し、スレッド群の進展を監視し、衰退スレッド群を助け、あるスレッド群のホームまたは現スケジューリング・ロカールを移動することによって、処理およびメモリ負荷の均衡が失われないことを保証する。中期スケジューラ６００がこれらの機能を行う方法については、図８〜図１５を参照しながら、以下で更に詳しく説明する。

中期スケジューラ６００は、一度に１つずつシステム内のアクティブなスレッド群全てのステータスをチェックし（ステップ６０３）、それらが処理中か衰退中かを判定し（ステップ６０９）、さらにそれらが侵入されたか否かを判定する（ステップ６２５）。中期スケジューラがスレッド群のステータスを見る度に、ＳＬＤが陳腐化していないかチェックする（ステップ６０５）。ＳＬＤが陳腐化している場合、中期スケジューラは、ＪＰ、メモリ、優先度、および複合負荷値を各スケジューリング・ロカールについて計算することにより、新しいＳＬＤを計算する（ステップ６０７）
スケジューリング・ロカールに対するＪＰの負荷は、関連するスケジューリング・サブツリーの実行キューの中の適格エンティティ（スレッド）の数である。スケジューリング・ロカールに対するメモリ負荷は、関連するスケジューリング・サブツリー内の使用メモリの構成済バイト数である。

中期スケジューラは、適格スレッド群をその優先度順に並べたグローバル・リストを維持しアクセスすることによって、優先度負荷を計算する。中期スケジューラは、同一または実質的に同一の優先度を有するスレッド群をリストに類別し、グルーピング(grouping)内の各スレッド群に「優先度点」を割り当てる。例えば、最も高い優先度を有するグルーピング内のスレッド群には、優先度点２０を割り当て、次に高い優先度を有するグルーピング内のスレッド群には優先度点１９を割り当てるようにする。連続的に減少する優先度点の割り当ては、ゼロの値に到達するまで（この場合、それより低い優先度を有するスレッド群にも全て優先度点０が割り当てられる）、またはグルーピングの全てに別の方法で優先度点が割り当てられるまで、続けられる。中期スケジューラは、次に、リストを十分に調べ、各スレッド群の現ロカールを決定し、各スケジューリング・ロカールのスケジューリング・サブツリー内の各スレッド群毎に、割り当てられた優先度点を蓄積する。この各スケジューリング・ロカール毎に蓄積された値は、スケジュール・ロカールの優先度負荷となる。

各スケジューリング・ロカール毎の複合負荷は、重み付けし、正規化したＪＰ、メモリ、および優先度負荷の合計である。ＪＰ、メモリ、および優先度負荷を０ないし１００までの値に正規化し、利用可能なシステム・メモリが比較的小さいか否かのような、性能基準(performance criteria)に基づいて重み付けする。中期スケジューラは、陳腐化係数カウンタを用いて、ＳＬＤが陳腐化していないか判断することができる。このカウンタは、ＳＬＤがリフレッシュされる毎にリセットされ、プロセスの特定ルーチンにしたがって減数される。

衰退スレッド群を補助するために（ステップ６０９）、中期スケジューラは、スレッド群が順番を待っているが実行されない時間を監視し、ステップ６１１、６１５、およびステップ６１９（図９）において判定されるように、関連する時間期間が過ぎたときに、以下の３つの機能の１つを実行する。（１）スレッド群の優先度を上げる（ステップ６１３）。（２）スレッド群を、階層ツリー内のより高い、より可視性の高いレベルに昇進させる（しかし、スケジューリング・レベル未満）（ステップ６１７）。または、（３）スレッド群の侵入／補助ヒント・フラグをセットする（ステップ６２１）。作業を捜しているディスパッチャは最高の優先度を有するスレッド群を選択するので、スレッド群の優先度を高めることによって（ステップ６１３）、作業を捜しているディスパッチャがそのスレッド群を選択する可能性が高くなる。しかしながら、ＪＰが現在長いプロセスを実行中の場合、またはＪＰの実行キューの中に優先度が高いスレッド群が残っている場合、スレッド群の優先度を高くしても、当該スレッド群を少しでも速く実行しようとする可能性があまり高くならない場合もある。

第２の所定時間期間が過ぎた後に、中期スケジューラがスレッド群の進展がないと判断した場合、中期スケジューラは、階層ツリー内で次に高い、より可視性が高いレベルにスレッド群を昇進させる（しかし、スケジューリング・レベル未満）（ステップ６１７）。この昇進は、当該スレッド群を、直ちに全ての従属するＪＰのディスパッチャに見えるようにするので、同一スケジューリング・サブツリー内のディスパッチャが衰退スレッド群を選択する可能性を高めることになる。

第３の所定時間期間が過ぎた後でも、未だスレッド群が進展していない場合、中期スケジューラはこのスレッド群の侵入／補助ヒント・フラグをセットする。他のサブツリーにおいて作業を捜しているディスパッチャは、侵入／補助ヒント・フラグがセットされていないスレッド群を選択する前に、侵入／補助ヒント・フラグがセットされているスレッド群を選択するので、このフラグをセットすることによって、異なるスケジューリング・サブツリー内のディスパッチャがこのスレッド群に侵入する、またはこれを補助する可能性を高める。

第１、第２および第３の所定時間期間の後に中期スケジューラは、それぞれ、スレッド群に対して、優先度を高める、昇進させる、あるいはヒント・フラグをセットするが、これらは互いに独立とし、中期スケジューラが衰退スレッド群を補助する方法を、システムの特性に基づいてシステム毎に変化させ、システムのスループットを向上させるようにする。一例として、第１の所定時間期間を８，０００ｍｓｅｃ、第２の所定時間期間を２，０００ｍｓｅｃ、そして第３の所定時間期間も２，０００ｍｓｅｃとしてもよい。したがって、中期スケジューラは、そのルーチンを１秒毎に実行し、そのルーチン２サイクルの間（２，０００ｍｓｅｃ）列に並んでいるが実行されていないスレッド群については、その侵入フラグをセットし、その後各２，０００ｍｓｅｃ間隔で昇進させる。８サイクル（８，０００ｍｓｅｃ）後にスレッド群が衰退している場合、それ以降８，０００ｍｓｅｃ間隔毎にその優先度を高める。衰退スレッド群を補助することにより、中期スケジューラはスケジューリングの不均衡(inequities)を防止または補正する。

また、中期スケジューラは、各スレッド群がＥｘｅｃ（）コマンドによって最初に生成されたとき、または別のスケジューリング・ロカールに移されたときに、各スレッド群毎に、減退係数(dampening factor)をセットする。減退係数をセットして、中期スケジューラが、最初にディスパッチャに負荷を均衡化させようともせずに、負荷の不均衡に応答して、キャッシュのスラッシング(thrashing)を行うのを防止する。スレッド群のステータスをチェックする毎に、中期スケジューラは、当該スレッド群の減退係数を減数する（図８）。したがって、スレッド群のスケジューリング・ロカールを変更し、その減退係数を、例えば、５の値にセットしたとき、中期スケジューラは、減退係数を０に減数するまで、スレッド群を移行させたり、あるいは移動させたりしようとしない。減退処理は、中期スケジューラが頻繁にスレッド群を移行するのを防止することによって、キャッシュのスラッシングを減少させる。

加えて、中期スケジューラは、現スケジューリング・ロカールがホーム・スケジューリング・ロカールよりもビジーでないとき、侵入されたスレッド群のホーム・スケジューリング・ロカールを、その現スケジューリング・ロカールに移行することによって、または、ホーム・スケジューリング・ロカールが現スケジューリング・ロカールよりもビジーでないとき、侵入されたスレッド群をそのホーム・スケジューリング・ロカールに戻すことによって、均衡の取れたシステムの処理負荷を保証する。中期スケジューラが、侵入されたスレッド群を検出したとき（即ち、その現スケジューリング・ロカールがそのホーム・スケジューリング・ロカールと異なる場合）、そのスレッド群の現スケジューリング・ロカール（ＣＳＬ）の複合負荷が、そのスレッド群のホーム・スケジューリング・ロカル（ＨＳＬ）よりも、所定の「ホーム送り(send home)」スレシホルドよりも大きい量だけ、超過しているか否かを判定する（ステップ６２７）。その量が「ホーム送り」スレシホルドを超過していない場合、中期スケジューラは、このスレッド群のホーム・スケジューリング・ロカールの複合負荷が、このスレッド群の減スケジューリング・ロカールよりも、所定の「移行(migrate)」スレシホルドよりも大きい量だけ、超過しているか否かを判定する（ステップ６２９）。侵入されたスレッド群の現スケジューリング・ロカールまたはホーム・スケジューリング・ロカールのいずれも、「ホーム送り」または「移行」スレシホルド以上他方よりも超過した負荷を有していない場合、中期スケジューラは、そのＪＰ負荷を「ビジー」スレシホルドと比較することによって、現スケジューリング・ロカールがビジーか否かチェックする（ステップ６３１）。現スケジューリング・ロカールがビジーでない場合、中期スケジューラは、現ロカールに対するＳＬＤ陳腐化係数を増加し（ステップ６３３）、スレッド群をその侵入状態のまま放置し、性能データ(performance data)を蓄積して、侵入されたスレッド群をいつ移行すべきか、または移行すべきか否か、あるいは後にそれをホームに戻すべきかを判定する。

ステップ６２７において、スレッド群の現スケジューリング・ロカールの複合負荷が、所定の「ホーム送り」スレシホルドより多い量だけ、スレッド群のホーム・スケジューリング・ロカールの複合負荷を超過していると、中期スケジューラが判定した場合、このスレッド群をそのホーム・スケジューリング・ロカールに戻し、このスレッド群の現スケジューリング・ロカールがこのスレッド群のホーム・スケジューリング・ロカールと同じになるようにする（ステップ６３５）。

ステップ６２９において、スレッド群のホーム・スケジュール・ロカールの複合負荷が、所定の「移動」スレシホルドより大きい量だけ、スレッド群の現スケジューリング・ロカールの複合負荷を超過していると、中期スケジューラが判定した場合、中期スケジューラは、このスレッド群と関連付けられた減退係数が０であるか否かをチェックすることにより、スレッド群が減退しているか否かを判定する（ステップ６３７）。このスレッド群が減退している場合（即ち、その減退係数がゼロでない）、中期スケジューラはこのスレッド群をホームに送る（ステップ６３５）。一方、スレッド群が減退していない場合（即ち、その減退係数がゼロである）、中期スケジューラは、このスレッド群のホーム・スケジューリング・ロカールをこのスレッド群の現スケジューリング・ロカールに変更することによって、このスレッド群を「移行」する（ステップ６３９）。スレッド群を検査した後、中期スケジューラは、まだ検査していないアクティブなスレッド群があるか否か判定し（図８、ステップ６４１）、次のアクティブなスレッド群を見つけ出す（ステップ６０３）。

長い時間期間にわたって不均衡状態にあるシステムの処理に対する更にもう１つのチェックとして、システムは、周期的に全スレッド群をそれらのスケジューリング・レベルの実行キューに再度引き上げることによって、各スケジューリング・ロカール内で「負荷均衡化」機能を実行する（ステップ６４５）。スレッド群は直ちに、スケジューリング・ロカール内の全ＪＰに見えるようになる。この機能は、比較的短い時間期間以上の間負荷の不均衡状態が存在するのを防止する。好適実施例では、このリセット機能は１０秒毎に実行されるが、他の時間期間を設定してもよい（ステップ６４３）。

システムの全体的な不均衡を防止するもう１つの対策は、中期スケジューラが周期的にスケジューリング・ロカール・レベルで負荷の均衡化を行うことである。まず、中期スケジューラは、スケジューリング・ロカールにおいて負荷の均衡化を行う時刻であるか否かをチェックする（ステップ６４７）。その時刻であれば、中期スケジューラは、複合負荷値が最も大きいスケジューリング・ロカールの位置を突き止め（図１１、ステップ６４９）、ステップ６５１で、ＪＰ負荷が複合負荷の支配的な要因であるか否かを判定する。ＪＰ負荷が支配的な要因である場合、中期スケジューラは、図１２に示すプロセスを用いて、負荷均衡化を行う。ＪＰ負荷が支配的な要因ではない場合、中期スケジューラは、メモリ負荷が複合負荷の支配的な要因であるか否かをチェックする（ステップ６５３）。メモリ負荷が支配的な要因である場合、中期スケジューラは、図１３に示すプロセスを用いて、負荷均衡化を行う。ＪＰ負荷もメモリ負荷も支配的な要因でない場合、中期スケジューラは、図１４に示すプロセスを用いて、負荷均衡化を行う。

図１２に示す負荷均衡化プロセスにおいて、中期スケジューラは開始に際して、ＪＰ負荷が最も軽いスケジューリング・ロカールを見つけ出し（ステップ６５５）、複合負荷が最も重いスケジューリング・ロカールと最も軽いスケジューリング・ロカールとの間のＪＰ負荷の差に基づいて、移動すべきスレッド群の数を計算する（ステップ６５７）。次に、中期スケジューラは、複合負荷が最も大きいスケジューリング・ロカール内で、最低の優先度のアクティブなスレッド群を見つけ出す（ステップ６５９）。このスレッド群が減退していない場合（ステップ６６１）、中期スケジューラは、このスレッド群が移行に適したメモリ・「フットプリント」を有するか否かを判定する（ステップ６６３）。

所与のメモリ・ロカールのメモリ内のスレッド群の「フットプリント」とは、当該メモリ・ロカールにおいてスレッド群が使用する物理メモリ量のパーセンテージを表わす。ＪＰ負荷および優先度負荷の均衡化の間にスレッド群を移動するのに適したフットプリントを構成するものは、システム毎に異なる。典型的なスレシホルドは、例えば、それらの現ロカールの物理的メモリにおいて、１０パーセント未満のフットプリントを有するスレッド群とすることができる。移動すべきいずれのスレッド群も全て適切なフットプリントを有することを保証することによって、中期スケジューラは、負荷均衡化の間に大きなスレッド群を移動させる事態を防止することができる。

スレッド群が減退している場合、または目的としたスレッド群が適切なメモリ・フットプリントを有していない場合、中期スケジューラは次に優先度が低いスレッド群を見つけ出し（ステップ６６５）、新たに選択したスレッド群について、ステップ６６１および６６３の検査を繰り返す。選択したスレッド群が減退しておらず、目的としたスレッド群が適切なメモリ・フットプリントを有する場合、中期スケジューラは、このスレッド群を、ＪＰ負荷が最も軽いスケジューリング・ロカールに移行させる（ステップ６６７）。次に、中期スケジューラは、ＳＬＤ陳腐化係数を調節し（ステップ６６９）、計算した数のスレッド群を移動させたか否かを判定する（ステップ６７１）。十分なスレッド群を移動させていない場合、中期スケジューラは次に優先度が低いスレッド群を見つけ出し（ステップ６６５）、十分なスレッド群を移動させるまで、ステップ６６１〜６７１を繰り返す。一旦計算した数のスレッド群を移動させたなら、中期スケジューラは、上述のように、それに割り当てられた機能の実行を繰り返す前に、所定時間期間にわたって処理を中断する（図８、ステップ６７３）。

図１３に示す負荷均衡化プロセスでは、中期スケジューラは開始に際して、複合負荷が最も重いスケジューリング・ロカールと最も軽いスケジューリング・ロカールとの間のメモリ負荷の差に基づいて、移動すべきメモリ負荷量を計算する（ステップ６７５）。次に、中期スケジューラは、複合負荷が最も重いスケジューリング・ロカールの中で、優先度が最も低いアクティブなスレッド群を見つける（ステップ６７７）。目的とするスレッド群が、移動すべきメモリ負荷量に対して、その現ロカール内に適切なメモリ・フットプリントを有する場合（ステップ６７９）、中期スケジューラは、このスレッド群が衰退しているか否かを判定する（ステップ６８０）。

メモリ負荷の負荷均衡化を図る目的に適したフットプリントは、移動させなければならないメモリ量に基づいて変化する。例えば、あるロカールから物理メモリの２０パーセントを他のロカールに移動してメモリ負荷の均衡化を図る場合、フットプリントが２０パーセント以下のスレッド群を移動させればよい。スレッド群が減退している場合、またはそのフットプリントが適切でない場合、中期スケジューラは次に優先度が低いスレッド群を見つけ出し（ステップ６８１）、新たに選択したスレッド群に対して、ステップ６８０および６８１の検査を繰り返す。

選択したスレッド群が減退しておらず、そのフットプリントが適切である場合、中期スケジューラは、メモリ負荷が最も軽いスケジューリング・ロカールに、このスレッド群を移行させる（ステップ６８２）。次に、中期スケジューラはＳＬＤ陳腐化係数を調節し（ステップ６８３）、計算した量のメモリ負荷を移動させたか否かを判定する（ステップ６８４）。十分なメモリ量を移動させていない場合、中期スケジューラは次に優先度が低いスレッド群を見つけ出し（ステップ６８１）、十分なメモリ量を移動させるまで、ステップ６７９〜６８４を繰り返す。一旦計算した量のメモリ負荷を移動させたなら、中期スケジューラは、上述のように、それに割り当てられた機能の実行を繰り返す前に、所定時間期間にわたって処理を中断する（図８、ステップ６７３）。

図１４に示す負荷均衡化プロセスでは、中期スケジューラは開始に際して、優先度負荷が最も軽いスケジューリング・ロカールを見つけ出し（ステップ６８５）、複合負荷が最も重いスケジューリング・ロカールと最も軽いスケジューリング・ロカールとの間の優先度負荷の差を計算する（ステップ６８６）。次に、中期スケジューラは、計算した負荷の差が所定のスレシホルドを超過しているか否かを判定する（ステップ６８７）。超過していなければ、中期スケジューラは負荷の均衡化を行わない。負荷の差がスレシホルド・レベルを超過している場合、中期スケジューラは、スケジューリング・ロカール内で、適切なフットプリントを有し（ステップ６９０）、複合負荷が最も重く（ステップ６８９および６９１）、優先度が最高のスレッド群を見つけ出し、優先度負荷が最も軽いスケジューリング・ロカールにこのスレッド群を移行させる（ステップ６９２）。次に、中期スケジューラはＳＬＤ陳腐化係数を調節し（ステップ６９３）、上述のように、それに割り当てられた機能の実行を繰り返す前に、所定時間期間にわたって処理を中断する（図８、ステップ６７３）。

また、中期スケジューラは、ＵＮＩＸ（登録商標） Ｅｘｅｃ（）コマンドによって生成されるスレッド群の初期ホーム・スケジューリング・ロカールの割り当てを制御することによって、階層ツリー全体にわたって均衡の取れた処理負荷を保証することもできる。寿命が短いプロセス(short-lived process)では、初期ホーム・スケジューリング・ロカールは、そのプロセスにとって唯一のスケジューリング・ロカールとなろう。寿命が長いプロセスでは、初期ホーム・スケジューリング・ロカールは、プロセスのページ・フォールト(page fault)を発生させるホーム・スケジューリング・ロカールであるので、将来の性能を左右することになろう(bias)。

ＵＮＩＸ（登録商標） Ｆｏｒｋ（）コマンドによって新たなプロセスを生成したとき、ホーム・スケジューリング・ロカールはスレッド群に対して望まれるロカールの位置を表わすので、スレッド群はその親のホーム・スケジューリング・ロカールの位置を受け継ぐ。プロセスがＵＮＩＸ（登録商標） Ｅｘｅｃ（）コマンドを実行するとき、その画像を上書きするので、その以前のメモリとは何の関係も有さない（共有メモリを除く）。この場合、ＪＰ資源を最大化しメモリ資源が利用可能なホーム・スケジューリング・ロカールに、このプロセスを割り当てる。図１５は、Ｅｘｅｃ（）プロセスを、ホーム・スケジューリング・ロカールに割り当てるために実行するプロセスを示す。Ｅｘｅｃ（）コマンドを実行するとき、カーネルのプロセス制御サブセクションは、中期スケジューラ・サブセクションを呼び込み、中期スケジューラ・サブセクションは、呼び出し元のタスク群の、複合負荷が最も軽いホーム・スケジューリング・ロカールを移動させる。まず、複合負荷が最も小さいスケジューリング・ロカールを識別する（ステップ６９７）。負荷が最も小さいスケジューリング・ロカールと呼び出し元タスク群のホーム・スケジューリング・ロカールとの間の複合負荷の差がスレシホルド・レベルを超過している場合（ステップ６９７）、スレッド群のホーム・スケジューリング・ロカールを、複合負荷が最も軽いスケジューリング・ロカールに変更する（ステップ６９８）。スレシホルド・レベルを超過していない場合、中期スケジューラ・サブシステムが制御をプロセス制御サブシステムに返す前に、スレッド群は、その親プロセスのホーム・スケジューリング・ロカールを引き継ぐ（中期スケジューラは別個のカーネル・スレッドであるが、Ｅｘｅｃ（）コマンドは、呼び出し元の制御スレッドの下で、中期スケジューラ・サブシステムを通過する）（ステップ６９９）。
メモリ管理
プロセスのＪＰに対する親和性を調節するためにＮＵＭＡシステムにおいて考慮すべき別の点は、システムのメモリ資源の管理である。スレッド群を移行させる場合、そのスレッド群と関連付けられたメモリも移動させることが望ましい場合もある。加えて、ＮＵＭＡシステムのメモリ・マネージャは、好ましくは、フォールティング・プロセス(faulting process)の位置および当該ページに含まれる情報のタイプに基づいて、ページ・フォールト位置を割り当てる。更に、メモリ・マネージャは、均衡の取れたシステム・メモリ資源の使用を維持しなければならない。

上述のタスクを達成するために、本発明のオペレーティング・システムは、システム全体に分散した複数の物理的および仮想資源を表わすデータ構造を制定することにより、図２に示したものに類似したシステム抽象概念を利用する、仮想メモリ・マネージャを含む。このデータ構造は、抽象化したシステムの種々のノードと関連付けられた種々のテーブルという形状を取る。図１６および図１７は、図１に示したようなＮＵＭＡマルチプロセッサ・システムのために考えられるこれらデータ構造の例を示す。

一様メモリ・アクセス・システムでは、メモリは、同一コストでしかも同一アクセス時間で全てのＪＰによって等しくアクセス可能な物理メモリ・ブロックから成る。しかしながら、ＮＵＭＡシステムでは、システムのメモリは、異なるアクセス時間およびコストを有する種々の分散型共有メモリ・ブロックで構成することができる。図１６は、ＮＵＭＡシステムの物理メモリの割り当てを表わす、システムの抽象概念とデータ構造とを示す。仮想メモリ・マネージャが使用する抽象概念は、各共有メモリ群と関連付けられたトレジャリ・ノード(treasury node)７０〜７３、および階層ツリー抽象概念のルート・ロカール・ノード(route locale node)１２０と関連付けられた高位ポリシ・ノード７６を含むポリシ・ツリーを形成する。また、ポリシ・ツリー抽象概念は、階層ツリー抽象概念のノード１１４および１１５と関連付けられた中間ポリシ・ノード７４および７５を含んでもよい。トレジャリ・ノードは、ページ配置アルゴリズムを実施するためにポリシ・ノードによって確定されたポリシにしたがって、物理メモリ空間を割り当てる機構を表わす。ポリシおよびトレジャリ・ノードの、階層ツリー抽象概念のノードとの関連は、ロカール対ノード参照テーブル７７中に保持されている。ロカール対ノード参照テーブル７７は、好ましくは、一方の軸にＪＰ番号、他方の軸にレベル番号を指定した二次元アレイである。各ＪＰおよびレベル番号の指定毎に、ポリシまたはトレジャリ・ノードの一方に対するポインタが存在する。このように、オペレーティング・システムのスケジューリング要素が用いるのと同一ＪＰ−レベル命名基準を用いて、トレジャリまたはポリシ・ノードを素速く識別することができる。

システムの物理メモリは、「フレーム」と呼ばれる個別要素で構成されており、フレームのサイズは、基礎となるプロセッサ・アーキテクチャによって決定されるが、一般的に４ＫＢである。オペレーティング・システムは、利用可能な物理メモリを、例えば、１０２４個の連続フレームから成る群に分割し、次にこれらフレーム群をシステム内のトレジャリに割り当てる。この割り当ては、高位フレーム・テーブル７８の中に保持されている。これらフレームの各々は、固有の識別番号を有する。この番号は、フレームの開始物理アドレスをフレーム・サイズで除算することによって計算することができる。更に、各フレームは、高位フレーム・テーブル７８内の１つのスロットによって管理され、このスロット番号は、フレームの固有識別番号をフレーム群のサイズで除算することによって計算することができる。ＮＵＭＡシステム内の物理メモリの物理アドレスは、連続でなくてもよく、高位フレーム・テーブル７８において識別されるフレームのいくつかは、実際の物理メモリを表わさない場合もある。このような場合、高位フレーム・テーブル７８のかかるフレームへのエントリには、無効と印すこともできる。

以下で更に詳細に説明するが、トレジャリは、関連するメモリ・フレーム・テーブルを用いて、それらのロカールにおいて物理メモリのフレームを管理し、割り当てる。ポリシ・ノードを設けることによって、このポリシ・ノードと関連付けられた所定のポリシの考慮にしたがって、階層ツリー抽象概念におけるより高いレベルのノードに割り当てられる物理メモリのフレームを、実際には、ポリシ・ノードの子トレジャリ・ノードから割り当てるようにする。典型的に、これらのポリシは、子孫メモリ群(descendent memory group)間でかかる高位メモリ要求の負荷均衡化を行うように選択される。したがって、ポリシ・ツリーにおいてレベルが高い程、フレームを割り当てるメモリ群の数が多くなることを意味する。フレームを割り当ててフォールトを満足させるときに、ページ・フォールト処理ルーチンによって起動されるフレーム割り当てルーチンが、ポリシ・ツリーを通過する。フレーム割り当て部は、ページ配置制約を用いて、フレームを割り当てるメモリ・ロカールを決定する。この制約は、ページ配置アルゴリズムの適用を開始する、ポリシ・ノードを識別する。ポリシ・ツリーの通過は、論理アドレスによってマップされたオブジェクト・ページに帰せられる制約によっては、ルート、リーフ、またはある中間レベルにおいて開始することができる。いずれのマッピングのデフォルト制約も、メモリ・オブジェクトと関連付けられている。デフォルト制約は、オブジェクトの属性に応じて、オブジェクトに割り当てられる。

ページ配置アルゴリズムは、指定されたノードからポリシ・ツリーの通過を開始し、フレームを割り当てるべきフレーム・トレジャリを選択するまで、それが遭遇した各ノードに、レベル依存ポリシ(level-dependent policy)を適用する。重み付けを用いて、ツリーの所与のレベルにおいて、同胞ノード(silbing nodes)間で分散された全数のフレームにおける不均衡を補償することができる。ポリシ・ツリー管理のために用いられるデータ構造は、ポリシ・ノード・クラス一覧と、リンク構造とからなり、これは、ポリシ・ツリー内の全タイプのポリシ・ノードの中に埋め込まれる。ポリシ・ツリー内の特定タイプのノードに特定した他の情報も、この構造の中に保持することができる。本発明のオペレーティング・システムのページ配置アルゴリズムおよびその他のメモリ割り当てアルゴリズムがトレジャリおよびポリシ・ノードを利用する具体的な態様については、以下でより詳細に説明する。

図１７は、ＮＵＭＡシステムの仮想（論理）メモリの割り当てを表わす、システムの抽象概念およびデータ構造の例を示す。仮想メモリ・マネージャが使用する抽象概念は、構造ツリー抽象概念の各ノードと関連付けられたメモリ・プール(memory pool)８０〜８６を含む。メモリ・プールの、階層ツリー抽象概念との関連は、ロカール対ノード参照テーブル８７の中に保持されている。ロカール対ノード参照テーブル８７は、好ましくは、一方の軸にＪＰ番号を指定し、他方の軸にレベル番号を指定した二次元アレイである。各ＪＰおよびレベル番号の指定毎に、メモリ・プールの１つへのポインタが存在する。このようにして、オペレーティング・システムのスケジューリング要素が用いるのと同じＪＰ−レベル命名基準を用いて、メモリ・プールを素速く識別することができる。

加えて、システムは、無配線メモリ(unwired memory)を区別することも可能な場合もある。無配線メモリとは、配線メモリから、物理メモリ外に割り振られた仮想メモリ領域のことでる。また、配線メモリとは、物理メモリ内に存在することを強制された、仮想メモリの領域のことである。これら異なるタイプのメモリ領域を収容するために、本発明のオペレーティング・システムは、抽象概念の各ノードに２つのタイプのメモリ・プールを、即ち、配線メモリに１つ、無配線メモリに１つのメモリ・プールを形成することができる。２つの異なるタイプのメモリ・プールは図１７には示されていないが、システムの抽象概念の中に同様な並列メモリ構造を生成することにより、２つ以上の異なるタイプのメモリ・プールを考慮するように、システムを容易に修正することができる。加えて、共有ページ・テーブル割り当てに用いる特殊な無配線メモリ・プールを、ルート・メモリ・ロカールにのみ形成することもできる。更に、抽象概念の中の種々のロカールに他のタイプのメモリ・プールを形成し、システムの処理効率を向上するメモリ資源間のあらゆるタイプの区別にも対処することも可能である。

システムの仮想メモリは、「プール単位」に分割されている。プール単位は、例えば、４ＭＢの所定の一定サイズを有し、１つ仮想メモリ範囲のみに対応する。本例では、フレーム群サイズとプール単位サイズとを同一として開示するが、同一ではない他のフレームおよびプール単位サイズを選択してもよい。プール単位の各々は固有の識別番号を有し、この識別番号は、プール単位の開始論理アドレスをプール単位サイズで除算することによって、素速く計算することができる。プール単位の各々が割り当てられるメモリ・プールは、プール単位テーブル８８の中に保持される。ＮＵＭＡシステム内の仮想メモリの論理アドレスは不連続でもよいので、プール単位テーブル８８において識別されるプール単位のいくつかは、割り当てられた仮想メモリを表わさないものもある。このような場合、プール単位テーブル８８のかかるプール単位へのエントリには、無効と印される。

初期状態では、全てのプール単位は割り当てられていない。続いて、プール単位は、必要に応じて、メモリ・プールに割り当てられる。このように、プール単位は、動的にシステム中に割り当てることができ、プール単位を統計的にシステム初期化時に割り当てる場合のように、多くのメモリ・プールにわたってメモリ資源を断片化することもなく、また人工的なメモリ枯渇(memory exhaustion)問題に発展することもない。仮想メモリ・マネージャが、カーネル・メモリに対する要求を処理する方法を、図１８ないし図２０に示す。メモリ要求がスレッドから発生したとき（図１８、ステップ７０１）、仮想メモリ・マネージャは、システムが現在初期化中か否かを判定する（ステップ７０３）。そうであれば、仮想メモリ・マネージャは、ルート・ロカール１２０からの仮想メモリを割り当てることを選択する（ステップ７０５）。システムが初期化されていた場合、仮想メモリ・マネージャは、メモリ要求量が少ないか否か（≦６４バイト）を判定する（ステップ７０７）。メモリ要求量が少ない場合、仮想メモリ・マネージャは、スレッドを実行するＪＰに最も近いメモリ・ロカールからのメモリを割り当てる（ステップ７０９）。メモリ要求量が少なくなく、特定のロカールが要求されていない場合、仮想メモリ・マネージャは、ホーム・スケジューリング・ロカールを獲得し、選択する（ステップ７１１）。ホーム・スケジューリング・ロカールは、上述のように、スレッドのスレッド群が最も緊密に親和化されているロカールである。

メモリ・ロカールを選択した後、仮想メモリ・マネージャは、選択したメモリ・ロカールに命名基準を用いて、ロカール対ノード参照テーブル８７から、それと関連付けられたメモリ・プールを識別する（ステップ７１３）。一旦メモリ・プールが識別されたなら、仮想メモリ・マネージャは、識別されたメモリ・プールが十分な論理空間を有するか否かを判定する（ステップ７１５）。識別されたメモリ・プールが十分な空間を有する場合、仮想メモリ・マネージャは、先の要求のために論理空間を割り当てる（ステップ７１７）。一方、メモリ・プールが十分な論理空間を有していない場合、仮想メモリ・マネージャは、プール単位テーブル８８の中で、未使用のプール単位を捜し出し（ステップ７１９）、識別されたメモリ・プールにプール単位を追加する（ステップ７２１）。次に、メモリ要求量がプール単位のサイズより少ない場合、仮想メモリ・マネージャはプール単位を分割し、要求された論理空間を割り当てる前に、メモリ要求量を有するメモリ・ブロックを得る（ステップ７１７）。

論理空間を割り当てた後、指定したロカールがトレジャリ・ノードではなく、ポリシ・ノードであった場合、仮想メモリ・マネージャは、割り当てたメモリ・ロカールからのフレームまたはその子孫メモリ・ロカールの１つ以上のフレームで、割り当てた論理空間を支える（ステップ７２５）。このように、上述の手順を用いて、仮想メモリ・マネージャは、プロセスと、当該プロセスが処理するデータとの間に可能な限り最も緊密な親和性を補償することができる。例えば、ノード１１４（図２）に親和化されたスレッド群のスレッド（ＪＰ１００および１０２が双方とも同じスレッド群のスレッドを実行している場合が該当する）が、カーネル・メモリを要求した場合、仮想メモリ・マネージャは、ノード１１４のメモリ・ロカールを選択する。これは、当該スレッドのスレッド群が最も緊密に親和化されているロカールである。そして、仮想メモリ・マネージャは、ロカール対ノード参照テーブル８７の中でノード１１４を表わす（２、０）命名基準に対応するメモリ・プールを参照することによって、ノード１１４を関連付けられたメモリ・プール（８４）を識別する。次に、仮想メモリ・マネージャは、メモリ・プールから論理メモリ空間を割り当て、ノード１１４に物理メモリがない場合（即ち、ノード１１４がポリシ・ノードである）、ロカール１１４のいずれかの物理メモリからのフレームまたはその子メモリ・ロカール１１０および１１１からのフレームで、この論理空間を支える。後者の場合、仮想メモリ・マネージャがメモリ・ロカール１１０または１１１の一方を選択する方法は、特定のポリシ・ノードに制定されたポリシに依存する。ここで注記すべきは、各ポリシ・ノードは、他のポリシ・ノードとは異なる考慮を行うポリシを実施してもよいことである。かかるポリシは、その子ノードのハードウエア制約および性能データに基づいて、設計することができる。フレームを割り当てて論理空間を支えたメモリ・プール（単数または複数）からではなく、ノード１１４と関連付けられたメモリ・プールからの論理空間を割り当てることにより、割り当てられた物理メモリは、ＪＰ１００および１０２上で実行されるスレッド双方にとって、より見やすくなる。更に、その後物理メモリから最も遠いＪＰが、最も近いＪＰよりも頻繁に、そこ記憶されているデータにアクセスする場合、メモリ・ロカール１１０または１１１の一方の中の物理メモリから、他方のメモリ・ロカール１１１または１１０の物理メモリに、後からメモリを移行させることもできる。

他の例として、ＪＰ１００（図２）に親和化されているスレッド群のスレッドがカーネル・メモリを要求した場合、仮想メモリ・マネージャはノード１１０のメモリ・ロカールを選択し、メモリ・ロカール１１０と関連付けられたメモリ・プールからの論理空間を割り当て、メモリ・ロカール１１０と関連付けられた物理メモリからのフレームで、この論理空間を支える。

仮想メモリを使用するために解放するとき、仮想メモリ・マネージャは、解放された仮想メモリ・ブロックの開始論理アドレスを見て、所有するプール単位を識別する（ステップ７２７）。次に、仮想メモリ・マネージャは、プール単位テーブル８８にアクセスすることによって、どのメモリ・プールにプール単位が割り当てられるのかを識別する（ステップ７２９）。次に、仮想メモリ・マネージャは、解放した仮想メモリの論理空間を放出し、識別されたメモリ・プールに合体する（ステップ７３１）。続いて、仮想メモリ・マネージャがステップ７３３において、メモリ・プールが未使用のプール単位を有すると判定した場合、このプール単位をプール単位テーブル８８に戻し（ステップ７３５）、このプール単位を他のメモリ・プールに割り当てられるようにする。

仮想メモリ・マネージャ７００がフレーム要求を処理する方法を、図２１および図２２に示す。ページ・フォールトが発生したとき、物理メモリのフレームに対する要求も行われ、仮想メモリ・マネージャ７００は、ユーザがページ配置のためにロカールを特定したか否かを判定する（ステップ７３７）。ユーザがロカールを特定している場合、仮想メモリ・マネージャ７００はこの要求を引き受け(honor)、ユーザによって特定されたロカールを指定する（ステップ７３９）。ユーザがロカールを特定していない場合、仮想メモリ・マネージャは、ページ・フォールトが大きなファイル、即ち、大きな共有メモリのためのものなのか否かをチェックする（ステップ７４１）。そうであれば、可能メモリ・マネージャはルート・ロカール１２０を指定する（ステップ７４３）。ページ・フォールトが大きなファイル、即ち、大きな共有メモリのためのものではない場合、仮想メモリ・マネージャは、ページ・フォールトがユーザの個人的データのためのものか否かを判定する（ステップ７４５）。ユーザの個人的データのためのページ・フォールトである場合、仮想メモリ・マネージャは、要求元スレッドのスレッド群が最も緊密に親和化されているホーム・スケジューリング・ロカールを指定する（ステップ７４７）。ユーザの個人的データのためのページ・フォールトでない場合、仮想メモリ・マネージャは、ページ・フォールトが共有メモリのためのものか否かを判定する（ステップ７４９）。共有メモリのためのページ・フォールトである場合、仮想メモリ・マネージャは、要求元スレッドのスレッド群が最も緊密に親和化されているホーム・スケジューリング・ロカールを指定する（ステップ７５１）。共有メモリのためのページ・フォールトでない場合、仮想メモリ・マネージャは、ページ・フォールトがユーザ実行可能なテキスト（即ち、プログラム・テキスト）のためのものか否かを判定する（ステップ７５３）。実行可能テキストのためのページ・フォールトである場合、仮想メモリ・マネージャは、要求元スレッドのスレッド群が最も緊密に親和化されているホーム・ロカールを指定する（ステップ７５５）。実行可能テキストのためのページ・フォールトでない場合、仮想メモリ・マネージャは、ページ・フォールトがユーザ・ファイル・データのためのものか否かを判定する（ステップ７５７）。ユーザ・ファイル・データのためのページ・フォールトである場合、また、この特定例では、ユーザ・ファイル・データに対するページ・フォールトでない場合、仮想メモリ・マネージャは、要求元スレッドのスレッド群が最も緊密に親和化されているホーム・ロカールを指定する（ステップ７５９および７６１）。ステップ７４５〜７５７における検査の結果には係わらずホーム・ロカールを指定したが、本発明のオペレーティング・システムを実施するＮＵＭＡシステムの特性に基づいて、各検査に対して指定するロカールを変えてもよい。

ロカールを指定した後、仮想メモリ・マネージャは、当該ロカールを識別する命名基準に基づいて、ロカール対ノード参照テーブル７７を参照することによって、物理メモリ・ノード７０〜７６（図１６）を識別する（図２２、ステップ７６３）。次に、仮想メモリ・マネージャは、識別したノードがトレジャリ・ノードか、あるいはポリシ・ノードかを判定する（ステップ７６５）。このノードがトレジャリ・ノードである場合、ロカールは共有物理メモリ資源を表わすことを意味し、仮想メモリ・マネージャは、この物理メモリ資源からフレームを選択する（ステップ７６７）。このノードがトレジャリ・ノードではない場合、仮想メモリ・マネージャは、ラウンド・ロビン・アルゴリズム(round-robin algorithm)を用いて、このノードの子を１つ選択する。選択したノードがトレジャリである場合、そのトレジャリからフレームを割り当てる。選択したノードがトレジャリでない場合、その子の１つの選択し（ラウンド・ロビン）、このプロセスを繰り返す。

図２２に示す手順において、ステップ７６９〜７７３は、ポリシ・ノードのポリシを表わす。これら３つのステップを、いずれかの所与のポリシ・ノードに対して考慮した所望のポリシを実行するための、他のいずれかのアルゴリズムと置き換えてもよい。

メモリは、システムの抽象概念の種々のノード間で移行させて、最も頻繁にデータをアクセスするＪＰからメモリに記憶されているデータをアクセスするコストを制限することができる。好ましくは、かかるメモリ移行は全て、アドレス透過(address transparent)であるべきである。アドレス透過メモリ移行とは、論理アドレスは一定のままであるが、物理アドレスが変化するものである。透過性は、ページ・テーブルとハードウエア・アドレスとの変換を用いることによって達成される。プール単位テーブル８８を使用すれば、容易に論理アドレスからメモリ・プールへの変換を行うことができる。

メモリは、目的ロカール（即ち、論理アドレスが割り当てられるロカール）の子孫ロカールであるメモリ・ロカール間でのみ、透過的に移行可能である。したがって、目的ロカールが移行の自由度を制御する。最初の物理的配置は、目的ロカールの子孫から行われる。最初の物理的配置に選ばれたロカールを、初期ロカールと呼ぶ。したがって、図２を参照すると、ロカール（２、０）の目的とされたメモリは、初期ロカール（１、０）を有し、ロカール（１、０）、（１、１）、（１、２）および（１、３）間でのみ移行を許される。ルート・メモリ・ロカールを目的にすると、最大の自由度が許されるという利点があるが、メモリの、メモリ内に記憶されているデータにアクセスするＪＰとの親和性を低下させることになる。

本発明のオペレーティング・システムは、更に、抽象化システムの各トラジェリに、パージャ・スレッド(purger thread)と、クリーナ・スレッド(cleaner thread)とを含むことが好ましい。パージャ・スレッドは、物理メモリが単に満ち過ぎているときに、フレームまたはページ交換ポリシを実施する。クリーナ・スレッドは、修正ファイル・データを取り込み、自動的にこのデータを所定間隔でディスクに書き戻し、システムのクラッシュからデータを保護する。各ノードに別個のパージャおよびクリーナを設けることにより、単一のパージャまたはクリーナ・カーネル・スレッドのみに頼って、システム全体でそのタスクを実行する必要がなくなる。更に、システムはより容易に基準化が可能(scalable)であり、パージャやクリーナはより良い親和性を示す。

プロセッサとそれらが利用するデータとの間の親和性を高める他の方法は、システムの多数のトレジャリにおいて、あるタイプのファイル・ページの複製を許すことである。マップされた共有リード・ライトのような、あるタイプのファイル・ページは複製できないので、オペレーティング・システムは、各ページ・ファイルをどのようにマップするかを判定することができなければならず、各ファイル・ページのためのマッピングのタイプを考慮に入れた複製アルゴリズムを実施しなければならない。例えば、あるファイルの個人的なリード実行マッピング(read-execute mapping)は、プログラム・テキストを実行可能ファイル(executable)にマップするために、最も一般的に用いられている。実行可能なマッピングは、多数のプロセス間で共通して共有されているので、仮想メモリ・マネージャは、フォールティング・スレッド群が親和化されているメモリ・ロカールにおいて、かかるページの複製を積極的に試すことができる。かかる複製は、プログラム・ファイルのリード実行マッピング上でページ・フォールトが発生したときには、いつでも得ることができる。但し、そのファイルがどうあっても修正できない場合に限る。

ファイルの常駐サイズがある限度を超えて成長した場合、ファイル・ページは、フォールティング・スレッド群に親和化されているメモリ・ロカールにしたがって配置されるのではなく、メモリに送られながら負荷の均衡化を図ることができる。このように、システムは、ある特定ファイルからのページで、１つのメモリ・ロカールを飽和させてしまう事態を回避することができる。

本発明は、その精神または本質的な特性から逸脱することなく、他の特定形態において実施することも可能である。例えば、３レベルの実行キューを有するシステムについてこれまで論じてきたが、同一の概念は、３処理レベル以上のレベルで組織されたシステムにも容易に拡張可能であることは理解されよう。更に、本発明の説明にはスレッド群上で動作する例を用いたが、本オペレーティング・システムは単一プロセス（スレッド）上でも同様に動作する。本発明の範囲は、上述の説明ではなく、特許請求の範囲によって指示されており、特許請求の範囲の意味および均等の範囲に該当する変更は全て、特許請求の範囲に包含されることを意図するものである。

図１は、非一様メモリ・アクセス（ＮＵＭＡ）マルチプロセッサ・システムの一例の概要を示すブロック図。 図２は、図１に示す非一様メモリ・アクセス（ＮＵＭＡ）マルチプロセッサ・システムの抽象概念を示すブロック図。 図１に示すシステム上で実行されるプロセスの内部組織を示すブロック図。 本発明のディスパッチャが、スレッド群を選択し実行する処理を示すフローチャート。 本発明のディスパッチャが、スレッド群を選択し実行する処理を示すフローチャート。 本発明のディスパッチャが、スレッド群を選択し実行する処理を示すフローチャート。 本発明のディスパッチャが、スレッド群を選択し実行する処理を示すフローチャート。 本発明のオペレーティング・システムの一部を構成する中期スケジューラが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する中期スケジューラが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する中期スケジューラが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する中期スケジューラが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する中期スケジューラが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する中期スケジューラが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する中期スケジューラが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する中期スケジューラが実行する処理のフローチャート。 図１６は、図１に示した非一様メモリ・アクセス（ＮＵＭＡ）マルチプロセッサ・システムおよび関連する連携データ構造のポリシ・ツリー抽象概念を示すブロック図。 図１７は、図１に示した非一様メモリ・アクセス（ＮＵＭＡ）マルチプロセッサ・システムおよび関連する連携データ構造の仮想メモリ抽象概念を示すブロック図。 本発明のオペレーティング・システムの一部を構成する仮想メモリ・マネージャが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する仮想メモリ・マネージャが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する仮想メモリ・マネージャが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する仮想メモリ・マネージャが実行する処理のフローチャート。 本発明のオペレーティング・システムの一部を構成する仮想メモリ・マネージャが実行する処理のフローチャート。

符号の説明

１〜８ ジョブ・プロセッサ
１０〜１５ 共有資源
１６ 共有メモリ／主システム・バス
２０ ＮＵＭＡマルチプロセッサ・システム
７０〜７３ トレジャリ・ノード
７４、７５ 中間ポリシ・ノード
７６ 高位ポリシ・ノード
７７ ロカール対ノード参照テーブル
７８ 高位フレーム・テーブル
８０〜８６ メモリ・プール
８７ ロカール対ノード参照テーブル
８８ プール単位テーブル
１００〜１０７ リーフ・ノード
１１０〜１１５ ノード
１２０ ルート・ノード
１５０ ソフトウエア抽象概念
２００ プロセス
２１０、２２０、２３０ スレッド群
２１１、２２１、２３１ スレッド群構造
２１２〜２１４、２２２、２２３、２３２、２３３ タイムシェアリング・スレッド
２４０ データ集合
２４１ データ
６００ 中期スケジューラ
７００ 仮想メモリ・マネージャ

Claims (13)

1. 各々実行キューと関連付けられた複数のプロセッサを有するマルチプロセッサ・システムのためのオペレーティング・システムであって、
   前記プロセッサの１つと関連付けられ、前記関連するプロセッサの実行キューを監視し、前記関連するプロセッサが実行するために、他のプロセッサの実行キューからプロセスを捜して獲得するディスパッチャと、
   前記システムにおけるアクティブなプロセスの進展を監視し、処理されていないプロセスにフラグをセットする中期スケジューラと、
   から成り、
   前記ディスパッチャは、複数の入手可能なプロセスを有する実行キューを見つけ出し、前記ディスパッチャはフラグがセットされているプロセスを選択する、
   ことを特徴とする前記オペレーティング・システム。
2. 請求項１記載のオペレーティング・システムにおいて、前記プロセスはスレッド群を含み、前記ディスパッチャは、前記複数の入手可能なスレッド群にフラグがセットされたものがないとき、最高の優先度を有するスレッド群を選択することを特徴とする前記オペレーティング・システム。
3. 各々実行キューと関連付けられた複数のプロセッサを有するマルチプロセッサ・システムにおいて実行すべきスレッド群を選択する方法であって、
   各プロセッサの前記実行キューを監視するステップと、
   あるプロセッサが実行するために、他のプロセッサの実行キューからスレッド群を捜して獲得するステップであって、各スレッド群がそれらに割り当てられた優先度を有し、
   前記システム内のアクティブなスレッド群の進展を監視し、進展していないスレッド群にフラグをセットするステップと、
   前記スレッド群が位置付けられている実行キューが複数の入手可能なスレッド群を有するときは、フラグがセットされているスレッド群を選択し、前記スレッド群のいずれにもフラグがセットされていない場合は、最高の優先度を有するスレッド群を選択するステップと、
   から成ることを特徴とする前記方法。
4. 各々実行キューが関連付けられた複数のプロセッサを有するマルチプロセッサ・システムのためのオペレーティング・システムであって、
   前記システム内の各アクティブなプロセスの進展を監視し、所定時間期間の間に進展しない各アクティブなプロセスの優先度を昇進させる中期スケジューラと、
   前記プロセッサの１つと関連付けられ、該関連するプロセッサによって実行されるプロセスが待ち行列をなす実行キューを監視し、前記関連するプロセッサが実行するために、前記実行キューの中で最高の優先度を有するアクティブなプロセスを選択する、少なくとも１つのディスパッチャと、
   から成ることを特徴とする前記オペレーティング・システム。
5. 複数のプロセッサと、各々前記プロセッサの異なる組み合わせによって共有される複数の共有メモリー資源とを含むハードウエア・アーキテクチャを有するマルチプロセッサ・システムのためのオペレーティング・システムであって、
   前記マルチプロセッサ・システムのハードウエア・アーキテクチャの抽象概念を維持する手段であって、前記プロセッサに対応し階層ツリーの最低レベルに位置付けられる複数のリーフ・ノードと、前記プロセッサおよび共有メモリー資源の全てによって共有される共通資源に対応し前記階層ツリーの最高レベルに位置付けられるルート・ノードと、前記共有メモリー資源に対応し前記階層ツリーの少なくとも１つの中間レベルに位置付けられる複数の中間ノードとを有する階層ツリー構造の形状で、前記プロセッサと共有メモリー資源との物理的構成を表現する前記抽象概念を維持する前記手段と、
   共有物理メモリ資源を表わす各ノードにおいてフレーム・トラジェリを維持し、前記メモリ資源の物理メモリのフレーム管理および割り当てを制御し、関連するトラジェリを有する全てのノードに共通なノードを高位ポリシ・ノードとして識別し、前記プロセッサの少なくとも１つが用いるために、前記フレーム・トラジェリから物理メモリのフレームを割り当てる手段と、
   から成ることを特徴とする前記システム。
6. 請求項５記載のオペレーティング・システムであって、更に、物理メモリ空間に対するプロセス要求を受け、どのノードから前記要求された物理メモリ空間を割り当てるかを識別し、前記識別されたノードと関連付けられたフレーム・トラジェリから、前記要求された物理メモリ空間を割り当てる、メモリ・マネージャを含むことを特徴とする前記オペレーティング・システム。
7. 請求項６記載のオペレーティング・システムにおいて、前記識別されたノードはポリシ・ノードであり、前記メモリ・マネージャは、該ポリシ・ノードのポリシ制約に基づいて、前記ポリシ・ノードと関連付けられた１つ以上の関連するフレーム・トラジェリから、前記要求された物理メモリを割り当てることを特徴とする前記オペレーティング・システム。
8. 複数のプロセッサと、各々前記プロセッサの異なる組み合わせによって共有される複数の共有メモリー資源とを含むハードウエア・アーキテクチャを有するマルチプロセッサ・システムのためのオペレーティング・システムであって、
   前記マルチプロセッサ・システムのハードウエア・アーキテクチャの抽象概念を維持する手段であって、前記プロセッサに対応し階層ツリーの最低レベルに位置付けられる複数のリーフ・ノードと、前記プロセッサおよび共有メモリー資源の全てによって共有される共通資源に対応し前記階層ツリーの最高レベルに位置付けられるルート・ノードと、前記共有メモリー資源に対応し前記階層ツリーの少なくとも１つの中間レベルに位置付けられる複数の中間ノードとを有する階層ツリー構造の形状で、前記プロセッサと共有メモリー資源との物理的構成を表現する前記抽象概念を維持する前記手段と、
   前記ルート・ノードと関連付けられ、割り当てられ得る物理メモリの各フレームのリストと、リストされている各フレームと関連付けられ、当該フレームが位置する前記メモリ資源を表わすノードを識別するポインタとを含む、高位フレーム・テーブルを維持する手段と、
   から成ることを特徴とする前記オペレーティング・システム。
9. 複数のプロセッサと、各々前記プロセッサの異なる組み合わせによって共有される複数の共有メモリー資源とを含むハードウエア・アーキテクチャを有するマルチプロセッサ・システムのためのオペレーティング・システムであって、
   前記マルチプロセッサ・システムのハードウエア・アーキテクチャの抽象概念を維持する手段であって、前記プロセッサに対応し階層ツリーの最低レベルに位置付けられる複数のリーフ・ノードと、前記プロセッサおよび共有メモリー資源の全てによって共有される共通資源に対応し前記階層ツリーの最高レベルに位置付けられるルート・ノードと、前記共有メモリー資源に対応し前記階層ツリーの少なくとも１つの中間レベルに位置付けられる複数の中間ノードとを有する階層ツリー構造の形状で、前記プロセッサと共有メモリー資源との物理的構成を表現する前記抽象概念を維持する前記手段と、
   前記システムの仮想メモリの割り当てのために、メモリ・ロカールを表わす各ノードにおいてメモリ・プールを維持し、前記仮想メモリをプール単位に分割して前記メモリ・プールに割り当てる手段と、
   プール単位および該プール単位の各々が割り当てられている前記メモリ・プールの可用性を識別する、プール単位テーブルを維持する手段と、
   から成ることを特徴とする前記オペレーティング・システム。
10. 請求項９記載のオペレーティング・システムであって、更に、仮想メモリ空間に対するプロセス要求を受け、該要求された仮想メモリ空間をどのメモリ・プールから割り当てるかを識別し、前記識別されたメモリ・プールが十分な仮想メモリ空間を有していない場合、前記識別されたメモリ・プールに対する前記プール単位テーブルから、追加のプール単位を得て、前記識別されたメモリ・プールから前記要求されたメモリ空間を割り当てる、メモリ・マネージャを含むことを特徴とする前記オペレーティング・システム。
11. 請求項１０記載のオペレーティング・システムにおいて、前記メモリ・マネージャは、前記識別されたメモリ・プールと関連付けられた物理メモリ空間で、前記要求された仮想メモリ空間を支えることを特徴とする前記オペレーティング・システム。
12. 請求項９記載のオペレーティング・システムであって、仮想メモリ空間を放出し、解放された仮想メモリ空間が属するプール単位を識別し、前記プール単位テーブルにアクセスし、前記識別されたプール単位が属するメモリ・プールを識別し、前記解放された仮想メモリ空間を前記識別されたメモリ・プールに放出する、メモリ・マネージャを含むことを特徴とする前記オペレーティング・システム。
13. 請求項１２記載のオペレーティング・システムにおいて、前記メモリ・マネージャは、各メモリ・プールにおいて、プール単位にサイズが等しい連続する解放仮想メモリ空間を捜し、前記プール単位テーブルにエントリを配置し、前記解放仮想メモリと関連付けられた前記プール単位がメモリ・プールへの割り当てに利用可能であることを指示することによって、前記解放仮想メモリを放出することを特徴とする前記オペレーティング・システム。

Images