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

Abstract

(57)【要約】 （修正有） 【課題】 ハードウェアアーキテクチャの抽象概念を階
層ツリー構造で与え、アドレス透過のメモリ移動などメ
モリ資源の継ぎ目のない扱いを支援する。 【解決手段】 階層ツリー構造は、ジョブ・プロセッサ
１〜８を表わすリーフ・ノードと、全てのジョブ・プロ
セッサによって共有される少なくとも１つのシステム資
源１６を表わすルート・ノードと、ジョブ・プロセッサ
の異なる組み合わせによって共有される資源１０〜１３
を表わす複数の中間レベル・ノードとを含む。オペレー
ティング・システムは、システム全体に分散されている
アクティブなスレッド群の進展を監視し、衰退スレッド
群を補助する中期スケジューラと、各々ジョブ・プロセ
ッサの１つと関連付けられ、その状態を監視し、その実
行スレッド群を得る複数のディスパッチャとを含み、更
に複数のメモリ・プールおよびフレーム・トレジャリを
用いて仮想および物理メモリを割り当てる。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

【０００３】最近のマルチプロセシング・システムは、
処理タスクを共有するいくつかの別個のジョブ・プロセ
ッサ(JP)を有することができる。かかるシステムの多く
は、キャッシュを内蔵し、このキャッシュをシステムの
ＪＰの部分集合が共有する。しかしながら、多くの従来
技術のマルチプロセッサ・システムに伴う問題の１つ
に、システム上で実行中のプロセスが、その実行中に、
多数の処理スレッドを生成するときのＪＰおよびキャッ
シュの親和性が不十分(poor)であることがあげられる。
従来技術のシステムには、各スレッドに個々の優先度を
割り当て、各スレッドをシステム全体で汎用的に別個に
スケジュールするものがある。また他のシステムには、
個々のスレッドを個々のＪＰに親和化(affine)できるも
のもある。同一データにアクセスする傾向がある、多数
の関係するスレッドを、多数のＪＰ群に分散すると、シ
ステムのキャッシュ内外において、望ましくない高いレ
ベルのデータ交換(data swapping)が発生する可能性が
ある。

【０００４】Robert A. Alfieriにより、１９９４年１
月２６に出願され、本願と共に譲渡された、"APPARATUS
AND METHOD FOR IMPROVED CPU AFFINITY IN A MULTI-P
ROCESSOR SYSTEM"と題する米国特許出願番号第０８／１
８７，６６５号は、同一プロセスからの関係があるスレ
ッド群をＪＰ群に親和化し、二次的なキャッシュの親和
性を改善しつつ、同一群内のスレッド間の処理効率を高
め、群間の処理のオーバーヘッドを減少させる方法を開
示する。この開示内容は、この言及により、本願にも含
まれるものとする。先の開示された方法は、更に、親和
性を自動的に修正し、局所的な効率を維持しつつ、関係
のあるスレッド群を移動させる。マルチプロセッサ・シ
ステム全体にわたってプロセッサ負荷の均衡を取るため
に、開示された方法は、全てのアクティブなスレッド群
を、システム・アーキテクチャ内で最高で最もよく見え
る(visible)レベルに昇進させることによって、周期的
に負荷の均衡化を行う。

【０００５】

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

【０００６】

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

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

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

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

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

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

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

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

【００１４】

【発明の実施の形態】

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

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

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

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

【００１８】オペレーティング・システム 図１に示したようなマルチプロセッサ・システムでは、
オペレーティング・システム（またはカーネル）は、通
常、ジョブ・プロセッサおよび／または専用システム・
プロセッサ上で実行される、種々のプロセスまたは方法
を含む。以下に述べるオペレーティング・システムの構
成物は、オペレーティング・システムによって実行され
るプロセスのいくつかのことを指す。

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

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

【００２１】各ＪＰ１００〜１０７毎に、オペレーティ
ング・システムは、実行キュー(runqueue)およびディス
パッチャ(dispatcher)を含む。ディスパッチャは、ある
グローバルおよびローカル・スケジューリング・ポリシ
にしたがって、関連するＪＰ上でのプロセスのスケジュ
ーリングおよび実行を担う機構である、カーネル・サブ
システム(kernel subsystem)である。スケジューリング
・ポリシのセットする役割を担う、オペレーティング・
システム内の他のカーネル・サブシステムを、以後、中
期スケジューラ(meidum term scheduler)と呼ぶ。これ
は、ディスパッチャが処理するスケジューリング機構に
影響を与える。ディスパッチャおよび中期スケジューラ
のスケジューリング処理については、「スレッド群」の
背景説明に続いて、以下で説明する。尚、スレッド群
は、オペレーティング・システムがそのポリシ作成決定
のいくつかの基準とするスレッドの群を表わす。しかし
ながら、オペレーティング・システムは、以下に説明す
るような、多数のスレッドを有するスレッド群上だけで
なく、単一プロセス（即ち、単一スレッドを有するスレ
ッド群）上でも動作可能であることは、理解されよう。

【００２２】スレッド群 ここで開示する「スレッド群」とは、同一データにアク
セスし処理する傾向のある、プロセス内で、緊密な関係
にあるスレッドの集合のことである。これら関係の有る
スレッドを、単一の全体的にスケジュール可能な群とし
て扱うことにより、当該群内のスレッドと個々のＪＰま
たはＪＰ群との間に、より密接な関係を増進し、これに
よって、キャッシュのヒット率およびシステム全体の性
能が向上することになる。

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

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

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

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

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

【００２８】プロセスの実行には、各々複数のスレッド
を有する複数のスレッド群がしばしば関与する。プロセ
スの開発においてスレッド群を使用することにより、既
存のスレッド群内で新しいスレッドを生成することと、
新しいスレッド群を生成することの間で選択を行う柔軟
性をユーザに与えることになる。ユーザは、当該プロセ
ス内の種々のタスクを処理するための最も効率的な手法
に基づいて、決定を下すことができる。例えば、多数の
スレッドを用いて特定の計算に関する作業を行ってお
り、全てのスレッドが同一データ集合へのアクセスを必
要とする場合、これらのスレッドを単一のスレッド群に
属させるのが正しい。一方、プロセスの進行中に当該プ
ロセス内で新たなタスクを開始するが、このタスクが既
存のスレッド群のタスクとは密接に結び付かず、しかも
新たなタスクのスレッドが異なるデータ副集合２４０へ
のアクセスを必要とする場合、新たなスレッド群を指示
する。

【００２９】プロセス・スケジューリング 上述のように、オペレーティング・システムは、ハード
ウエア・アーキテクチャの抽象概念を利用する。これ
は、共有資源、メモリ・ロカール(memory locales)、お
よびＪＰの逆ツリー階層として表わすのが好ましい。か
かる抽象概念の一例を図２に示す。このＪＰ／メモリ−
ツリー階層では、ＪＰを固有のＩＤ番号で識別し、各メ
モリ・ロカールまたは他の共有資源を、（レベル、ＪＰ
−ＩＤ）命名基準によって識別する。ここで、レベル
は、階層ツリーにおける垂直位置を特定し（番号が大き
いレベル程ツリーのルート・ノードに近く、ゼロ・レベ
ルはツリーのリーフ・ノード即ちＪＰを表わす）、ＪＰ
−ＩＤは、所望のロカールのいずれかの子孫ＪＰ(desce
ndent JP)を用いて、水平位置を指定する。例えば、図
２において、指定子（２、ＪＰ２）および（２、ＪＰ
０）は双方とも同一メモリ・ロカールを指し、一方
（２、ＪＰ２）および（２、ＪＰ４）は異なるロカール
を指す。各レベルは、１つ以上の「インスタンス」、即
ち、ＪＰ／メモリ・ツリー階層におけるノードを含むと
考えることができる。レベル０は、８個のノードを含
み、各々ＪＰ１００〜１０７の１つに対応する。レベル
１は４つのレベル１ノード１１０〜１１３を含み、各ノ
ードは、共有メモリ資源およびその従属ＪＰの１つに対
応する。レベル２は２つのレベル２ノード１１４および
１１５を含み、各々２つのレベル１ノードおよび共有資
源に対応する。最後に、２つのレベル２ノードと少なく
とも１つの共有システム資源とに対応する単一のレベル
３ノード１２０がある。この命名基準は、多くの場合、
システムの各レベルにいくつのノードがあるかを知る必
要性から、ソフトウエアを解放するため、実施を簡素化
することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００８２】ＵＮＩＸ Ｆｏｒｋ（）コマンドによって
新たなプロセスを生成したとき、ホーム・スケジューリ
ング・ロカールはスレッド群に対して望まれるロカール
の位置を表わすので、スレッド群はその親のホーム・ス
ケジューリング・ロカールの位置を受け継ぐ。プロセス
がＵＮＩＸ Ｅｘｅｃ（）コマンドを実行するとき、そ
の画像を上書きするので、その以前のメモリとは何の関
係も有さない（共有メモリを除く）。この場合、ＪＰ資
源を最大化しメモリ資源が利用可能なホーム・スケジュ
ーリング・ロカールに、このプロセスを割り当てる。図
１５は、Ｅｘｅｃ（）プロセスを、ホーム・スケジュー
リング・ロカールに割り当てるために実行するプロセス
を示す。Ｅｘｅｃ（）コマンドを実行するとき、カーネ
ルのプロセス制御サブセクションは、中期スケジューラ
・サブセクションを呼び込み、中期スケジューラ・サブ
セクションは、呼び出し元のタスク群の、複合負荷が最
も軽いホーム・スケジューリング・ロカールを移動させ
る。まず、複合負荷が最も小さいスケジューリング・ロ
カールを識別する（ステップ６９７）。負荷が最も小さ
いスケジューリング・ロカールと呼び出し元タスク群の
ホーム・スケジューリング・ロカールとの間の複合負荷
の差がスレシホルド・レベルを超過している場合（ステ
ップ６９７）、スレッド群のホーム・スケジューリング
・ロカールを、複合負荷が最も軽いスケジューリング・
ロカールに変更する（ステップ６９８）。スレシホルド
・レベルを超過していない場合、中期スケジューラ・サ
ブシステムが制御をプロセス制御サブシステムに返す前
に、スレッド群は、その親プロセスのホーム・スケジュ
ーリング・ロカールを引き継ぐ（中期スケジューラは別
個のカーネル・スレッドであるが、Ｅｘｅｃ（）コマン
ドは、呼び出し元の制御スレッドの下で、中期スケジュ
ーラ・サブシステムを通過する）（ステップ６９９）。

【００８３】メモリ管理 プロセスのＪＰに対する親和性を調節するためにＮＵＭ
Ａシステムにおいて考慮すべき別の点は、システムのメ
モリ資源の管理である。スレッド群を移行させる場合、
そのスレッド群と関連付けられたメモリも移動させるこ
とが望ましい場合もある。加えて、ＮＵＭＡシステムの
メモリ・マネージャは、好ましくは、フォールティング
・プロセス(faulting process)の位置および当該ページ
に含まれる情報のタイプに基づいて、ページ・フォール
ト位置を割り当てる。更に、メモリ・マネージャは、均
衡の取れたシステム・メモリ資源の使用を維持しなけれ
ばならない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図面の簡単な説明】

【図１】図１は、非一様メモリ・アクセス（ＮＵＭＡ）
マルチプロセッサ・システムの一例の概要を示すブロッ
ク図。

【図２】図２は、図１に示す非一様メモリ・アクセス
（ＮＵＭＡ）マルチプロセッサ・システムの抽象概念を
示すブロック図。

【図３】図１に示すシステム上で実行されるプロセスの
内部組織を示すブロック図。

【図４】本発明のディスパッチャが、スレッド群を選択
し実行する処理を示すフローチャート。

【図５】本発明のディスパッチャが、スレッド群を選択
し実行する処理を示すフローチャート。

【図６】本発明のディスパッチャが、スレッド群を選択
し実行する処理を示すフローチャート。

【図７】本発明のディスパッチャが、スレッド群を選択
し実行する処理を示すフローチャート。

【図８】本発明のオペレーティング・システムの一部を
構成する中期スケジューラが実行する処理のフローチャ
ート。

【図９】本発明のオペレーティング・システムの一部を
構成する中期スケジューラが実行する処理のフローチャ
ート。

【図１０】本発明のオペレーティング・システムの一部
を構成する中期スケジューラが実行する処理のフローチ
ャート。

【図１１】本発明のオペレーティング・システムの一部
を構成する中期スケジューラが実行する処理のフローチ
ャート。

【図１２】本発明のオペレーティング・システムの一部
を構成する中期スケジューラが実行する処理のフローチ
ャート。

【図１３】本発明のオペレーティング・システムの一部
を構成する中期スケジューラが実行する処理のフローチ
ャート。

【図１４】本発明のオペレーティング・システムの一部
を構成する中期スケジューラが実行する処理のフローチ
ャート。

【図１５】本発明のオペレーティング・システムの一部
を構成する中期スケジューラが実行する処理のフローチ
ャート。

【図１６】図１６は、図１に示した非一様メモリ・アク
セス（ＮＵＭＡ）マルチプロセッサ・システムおよび関
連する連携データ構造のポリシ・ツリー抽象概念を示す
ブロック図。

【図１７】図１７は、図１に示した非一様メモリ・アク
セス（ＮＵＭＡ）マルチプロセッサ・システムおよび関
連する連携データ構造の仮想メモリ抽象概念を示すブロ
ック図。

【図１８】本発明のオペレーティング・システムの一部
を構成する仮想メモリ・マネージャが実行する処理のフ
ローチャート。

【図１９】本発明のオペレーティング・システムの一部
を構成する仮想メモリ・マネージャが実行する処理のフ
ローチャート。

【図２０】本発明のオペレーティング・システムの一部
を構成する仮想メモリ・マネージャが実行する処理のフ
ローチャート。

【図２１】本発明のオペレーティング・システムの一部
を構成する仮想メモリ・マネージャが実行する処理のフ
ローチャート。

【図２２】本発明のオペレーティング・システムの一部
を構成する仮想メモリ・マネージャが実行する処理のフ
ローチャート。

【符号の説明】

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

フロントページの続き (72)発明者 ロバート・エイ・アルフィエリ アメリカ合衆国ノース・カロライナ州 27502−6669，アペックス，バーゲロン・ ウェイ 104 (72)発明者 マイルズ・エイ・デフォーレスト アメリカ合衆国ノース・カロライナ州 27704，ダーラム，チョーク・レベル・ロ ード 1117 (72)発明者 ウィリアム・ケイ・マクグラス アメリカ合衆国ノース・カロライナ州 27615，ローリー，ラナム・プレイス 721 (72)発明者 マイケル・ジェイ・マクレウド アメリカ合衆国ノース・カロライナ州 27529，ガーナー，アーテジアン・ドライ ブ 208 (72)発明者 マーク・エイ・オコンネル アメリカ合衆国ノース・カロライナ州 27516，チャペル・ヒル，ヒルズボロー・ ロード 1214 (72)発明者 ガイ・エイ・シンプソン アメリカ合衆国ノース・カロライナ州 27513，キャリー，オッターモント・コー ト 105

Claims (30)

【特許請求の範囲】
1. 【請求項１】種々のプロセスを実行する複数のプロセッ
   サと、各々前記プロセッサの異なる組み合わせによって
   共有される複数の共有資源とを含むハードウエア・アー
   キテクチャを有するマルチプロセッサ・システムのため
   のオペレーティング・システムを具現化するプログラム
   ・コードを収容したコンピュータ読み取り可能媒体であ
   って、前記オペレーティング・システムは、 前記マルチプロセッサ・システムのハードウエア・アー
   キテクチャの抽象概念を維持するステップであって、前
   記プロセッサに対応し階層ツリーの最低レベルに位置付
   けられる複数のリーフ・ノードと、前記プロセッサおよ
   び共有資源の全てによって共有される共通資源に対応し
   前記階層ツリーの最高レベルに位置付けられるルート・
   ノードと、前記共有資源に対応し前記階層ツリーの少な
   くとも１つの中間レベルに位置付けられる複数の中間ノ
   ードとを有する階層ツリー構造の形状で、前記プロセッ
   サと共有資源との物理的構成を表現する、前記抽象概念
   を維持するステップと、 前記階層ツリーの各ノードについて実行キューを形成す
   るステップであって、リーフ・ノードと関連付けられた
   各実行キューは前記関連するプロセッサに親和化された
   アクティブなプロセスを識別し、残りのノードの１つと
   関連付けられた各実行キューは、前記ノードと関連付け
   られたリソースを共有する前記プロセッサの群に親和化
   されたアクティブなプロセスを識別するように、前記実
   行キューを形成するステップと、および前記プロセッサ
   の動作を監視し、前記プロセッサが実行するために、前
   記実行キュー内で待ち行列をなすプロセスを選択するス
   テップと、から成る方法を実行する、前記オペレーティ
   ング・システムを収容することを特徴とする前記コンピ
   ュータ読み取り可能媒体。
2. 【請求項２】種々のアクティブなスレッド群のスレッド
   を実行するための複数のプロセッサと、各々前記プロセ
   ッサの異なる組み合わせによって共有される複数の共有
   資源とを含むハードウエア・アーキテクチャを有するマ
   ルチプロセッサ・システムのためのオペレーティング・
   システムであって、 前記マルチプロセッサ・システムのハードウエア・アー
   キテクチャの抽象概念を維持する手段であって、前記プ
   ロセッサに対応し階層ツリーの最低レベルに位置付けら
   れる複数のリーフ・ノードと、前記プロセッサおよび共
   有資源の全てによって共有される共通資源に対応し前記
   階層ツリーの最高レベルに位置付けられるルート・ノー
   ドと、前記共有資源に対応し前記階層ツリーの少なくと
   も１つの中間レベルに位置付けられる複数の中間ノード
   とを有する階層ツリー構造の形状で、前記プロセッサと
   共有資源との物理的構成を表現する前記抽象概念を維持
   する前記手段と、 前記階層ツリーの各ノードについて実行キューを形成す
   るステップであって、リーフ・ノードと関連付けられた
   各実行キューは前記関連するプロセッサに親和化された
   アクティブなスレッド群を識別し、残りのノードの１つ
   と関連付けられた各実行キューは、前記ノードと関連付
   けられたリソースを共有する前記プロセッサの群に親和
   化されたアクティブなスレッド群を識別するように、前
   記階層ツリーの各ノードについて実行キューを形成する
   手段と、および前記プロセッサの動作を監視し、前記プ
   ロセッサが実行するために、前記実行キュー内で待ち行
   列をなすプロセスを選択する手段と、から成ることを特
   徴とする前記オペレーティング・システム。
3. 【請求項３】請求項２記載のオペレーティング・システ
   ムにおいて、前記監視手段は、各々前記プロセッサの１
   つと関連付けられた、複数のディスパッチャを含むこと
   を特徴とする前記オペレーティング・システム。
4. 【請求項４】請求項３記載のオペレーティング・システ
   ムにおいて、あるプロセッサが実行のためにスレッドを
   使い果たしたとき、それと関連付けられた前記ディスパ
   ッチャは、まず、前記実行のためにスレッドを使い果た
   したプロセッサに対応するノードの祖先ノードの実行キ
   ュー内で利用可能なスレッド群があるか否かをチェック
   することを特徴とする前記オペレーティング・システ
   ム。
5. 【請求項５】請求項４記載のオペレーティング・システ
   ムにおいて、前記関連するディスパッチャが、第１所定
   時間期間以内に、前記祖先ノードの実行キューにおいて
   利用可能なスレッド群を突き止めることができなかった
   場合、前記関連するディスパッチャは、更に、前記実行
   のためにスレッドを使い果たしたプロセッサに対応する
   ノードの関係ノードの実行キューにおいて、利用可能な
   スレッド群があるか否かをチェックすることを特徴とす
   る前記オペレーティング・システム。
6. 【請求項６】請求項５記載のオペレーティング・システ
   ムにおいて、前記関連するディスパッチャが、第２所定
   時間期間内に、前記関係ノードの実行キューにおいて利
   用可能なスレッド群を突き止めることができなかった場
   合、前記関連するディスパッチャは、更に、前記階層ツ
   リー構造のノード全ての実行キューにおいて、利用可能
   なスレッド群があるか否かをチェックすることを特徴と
   する前記オペレーティング・システム。
7. 【請求項７】種々のプロセスを実行するための複数のプ
   ロセッサと、各々前記プロセッサの異なる組み合わせに
   よって共有される複数の共有資源とを含むハードウエア
   ・アーキテクチャを有するマルチプロセッサ・システム
   のためのオペレーティング・システムであって、 前記マルチプロセッサ・システムのハードウエア・アー
   キテクチャの抽象概念を維持する手段であって、前記プ
   ロセッサに対応し階層ツリーの最低レベルに位置付けら
   れる複数のリーフ・ノードと、前記プロセッサおよび共
   有資源の全てによって共有される共通資源に対応し前記
   階層ツリーの最高レベルに位置付けられるルート・ノー
   ドと、前記共有資源に対応し前記階層ツリーの少なくと
   も１つの中間レベルに位置付けられる複数の中間ノード
   とを有する階層ツリー構造の形状で、前記プロセッサと
   共有資源との物理的構成を表現する前記抽象概念を維持
   する前記手段と、 前記システム内の各ノードにおいて、前記アクティブな
   プロセスの進展を監視し、進展していなかったプロセス
   が直ちに実行される可能性を高める手段と、から成るこ
   とを特徴とする前記オペレーティング・システム。
8. 【請求項８】請求項７記載のオペレーティング・システ
   ムであって、更に、 前記階層ツリーの各ノードについて実行キューを形成す
   るステップであって、リーフ・ノードと関連付けられた
   各実行キューは前記関連するプロセッサに親和化された
   アクティブなプロセスを識別し、残りのノードの１つと
   関連付けられた各実行キューは、前記ノードと関連付け
   られたリソースを共有する前記プロセッサの群に親和化
   されたアクティブなプロセスを識別するように、前記階
   層ツリーの各ノードについて実行キューを形成する手段
   と、 前記プロセッサの動作を監視し、前記プロセッサが実行
   するために、前記実行キュー内で待ち行列をなすプロセ
   スを選択する手段と、を含むことを特徴とする前記オペ
   レーティング・システム。
9. 【請求項９】各々実行キューと関連付けられた複数のプ
   ロセッサを有するマルチプロセッサ・システムのための
   オペレーティング・システムであって、 前記プロセッサの１つと関連付けられ、前記関連するプ
   ロセッサの実行キューを監視し、前記関連するプロセッ
   サが実行するために、他のプロセッサの実行キューから
   プロセスを捜して獲得するディスパッチャと、 前記システムにおけるアクティブなプロセスの進展を監
   視し、処理されていないプロセスにフラグをセットする
   中期スケジューラと、から成り、 前記ディスパッチャは、複数の入手可能なプロセスを有
   する実行キューを見つけ出し、前記ディスパッチャはフ
   ラグがセットされているプロセスを選択する、ことを特
   徴とする前記オペレーティング・システム。
10. 【請求項１０】請求項９記載のオペレーティング・シス
    テムにおいて、前記プロセスはスレッド群を含み、前記
    ディスパッチャは、前記複数の入手可能なスレッド群に
    フラグがセットされたものがないとき、最高の優先度を
    有するスレッド群を選択することを特徴とする前記オペ
    レーティング・システム。
11. 【請求項１１】各々実行キューと関連付けられた複数の
    プロセッサを有するマルチプロセッサ・システムにおい
    て実行すべきプロセスを選択する方法であって、 各プロセッサの前記実行キューを監視するステップと、 あるプロセッサが実行するために、他のプロセッサの実
    行キューからプロセスを捜して獲得するステップと、 前記システム内のアクティブなスレッド群の進展を監視
    し、進展していないプロセスにフラグをセットするステ
    ップと、 前記プロセスが位置付けられている実行キューが複数の
    入手可能なプロセスを有するときは、フラグがセットさ
    れているプロセスを選択し、前記プロセスのいずれにも
    フラグがセットされていない場合は、最高の優先度を有
    するプロセスを選択するステップと、から成ることを特
    徴とする前記方法。
12. 【請求項１２】プロセスを実行するための複数のプロセ
    ッサと、各々前記プロセッサの異なる組み合わせによっ
    て共有される複数の共有資源とを含むハードウエア・ア
    ーキテクチャを有するマルチプロセッサ・システムのた
    めのオペレーティング・システムであって、 前記マルチプロセッサ・システムのハードウエア・アー
    キテクチャの抽象概念を維持する手段であって、前記プ
    ロセッサに対応し階層ツリーの最低レベルに位置付けら
    れる複数のリーフ・ノードと、前記プロセッサおよび共
    有資源の全てによって共有される共通資源に対応し前記
    階層ツリーの最高レベルに位置付けられるルート・ノー
    ドと、前記共有資源に対応し前記階層ツリーの少なくと
    も１つの中間レベルに位置付けられる複数の中間ノード
    とを有する階層ツリー構造の形状で、前記プロセッサと
    共有資源との物理的構成を表現する前記抽象概念を維持
    する前記手段と、 前記階層ツリーの各ノードについて実行キューを形成す
    るステップであって、リーフ・ノードと関連付けられた
    各実行キューは前記関連するプロセッサに親和化された
    アクティブなプロセスを識別し、残りのノードの１つと
    関連付けられた各実行キューは、前記ノードと関連付け
    られたリソースを共有する前記プロセッサの群に親和化
    されたアクティブなプロセスを識別するように、前記階
    層ツリーの各ノードについて実行キューを形成する手段
    と、から成り、 前記抽象概念は、前記階層ツリーのレベルの１つをスケ
    ジューリング・レベルとして定義し、前記スケジューリ
    ング・レベル内のノードをスケジューリング・ロカール
    として識別し、前記マルチプロセッサ・システム内の各
    アクティブなプロセスは、各々、スケジューリング・ロ
    カールの１つに対応する、ホーム・スケジューリング・
    ロカールと現スケジューリング・ロカールとを有し、プ
    ロセスのホーム・スケジューリング・ロカールは、前記
    プロセスを実行するための好適なプロセッサの祖先であ
    るスケジューリング・ロカールであり、プロセスの現ス
    ケジューリング・ロカールは、前記プロセスを最後に実
    行したプロセッサの祖先であるスケジューリング・ロカ
    ールである、ことを特徴とする前記オペレーティング・
    システム。
13. 【請求項１３】請求項１２記載のオペレーティング・シ
    ステムであって、更に、 前記スケジューリング・ロカールの各々について処理負
    荷を監視し、前記システム内の各アクティブなプロセス
    について、当該プロセスのホーム・スケジューリング・
    ロカールおよび現スケジューリング・ロカールが異なる
    スケジューリング・ロカールに対応するか否かを判定
    し、更に、前記スケジューリング・ロカールの処理負荷
    に基づいて、前記スレッド・プロセスのホーム・スケジ
    ューリング・ロカールを前記プロセスの現スケジューリ
    ング・ロカールに移動するか、または前記プロセスの現
    スケジューリング・ロカールを前記プロセスのホーム・
    スケジューリング・ロカールに移動するかを判定する、
    中期スケジューラを含むことを特徴とする前記オペレー
    ティング・システム。
14. 【請求項１４】アクティブなプロセスを実行するための
    複数のプロセッサと、各々前記プロセッサの異なる組み
    合わせによって共有される複数の共有資源とを含むハー
    ドウエア・アーキテクチャを有するマルチプロセッサ・
    システムにおいて、均衡化したプロセッサ負荷を維持す
    る方法であって、 前記マルチプロセッサ・システムのハードウエア・アー
    キテクチャの抽象概念を維持するステップであって、前
    記プロセッサに対応し階層ツリーの最低レベルに位置付
    けられる複数のリーフ・ノードと、前記プロセッサおよ
    び共有資源の全てによって共有される共通資源に対応し
    前記階層ツリーの最高レベルに位置付けられるルート・
    ノードと、前記共有資源に対応し前記階層ツリーの少な
    くとも１つの中間レベルに位置付けられる複数の中間ノ
    ードとを有する階層ツリー構造の形状で、前記プロセッ
    サと共有資源との物理的構成を表現する前記抽象概念を
    維持するステップと、 前記階層ツリーの各ノードについて実行キューを形成す
    るステップであって、リーフ・ノードと関連付けられた
    各実行キューは前記関連するプロセッサに親和化された
    アクティブなプロセス群を識別し、残りのノードの１つ
    と関連付けられた各実行キューは、前記ノードと関連付
    けられたリソースを共有する前記プロセッサの群に親和
    化されたアクティブなプロセス群を識別するように、前
    記階層ツリーの各ノードについて実行キューを形成する
    ステップと、 前記抽象概念は、前記階層ツリーのレベルの１つをスケ
    ジューリング・レベルとして定義し、前記スケジューリ
    ング・レベル内のノードをスケジューリング・ロカール
    として識別し、前記マルチプロセッサ・システム内の各
    アクティブなプロセスは、各々、スケジューリング・ロ
    カールの１つに対応する、ホーム・スケジューリング・
    ロカールと現スケジューリング・ロカールとを有し、プ
    ロセスのホーム・スケジューリング・ロカールは、前記
    プロセスを実行するための好適なプロセッサの祖先であ
    るスケジューリング・ロカールであり、プロセスの現ス
    ケジューリング・ロカールは、前記プロセスを最後に実
    行したプロセッサの祖先であるスケジューリング・ロカ
    ールであり、 前記スケジューリング・ロカールの各々について、処理
    負荷を監視するステップと、 前記システム内の各アクティブなプロセスについて、当
    該プロセスのホーム・スケジューリング・ロカールと現
    スケジューリング・ロカールが異なるスケジューリング
    ・ロカールに対応するか否かを判定するステップと、 前記スケジューリング・ロカールの処理負荷に基づい
    て、前記プロセスのホーム・スケジューリング・ロカー
    ルを前記プロセスの現スケジューリング・ロカールに移
    動するか、または前記プロセスの現スケジューリング・
    ロカールを前記プロセスのホーム・スケジューリング・
    ロカールに移動するかを判定するステップと、から成る
    ことを特徴とする前記方法。
15. 【請求項１５】アクティブなプロセスを実行するための
    複数のプロセッサと、各々前記プロセッサの異なる組み
    合わせによって共有される複数の共有資源とを含むハー
    ドウエア・アーキテクチャを有するマルチプロセッサ・
    システムのためのオペレーティング・システムであっ
    て、 前記マルチプロセッサ・システムのハードウエア・アー
    キテクチャの抽象概念を維持する手段であって、前記プ
    ロセッサに対応し階層ツリーの最低レベルに位置付けら
    れる複数のリーフ・ノードと、前記プロセッサおよび共
    有資源の全てによって共有される共通資源に対応し前記
    階層ツリーの最高レベルに位置付けられるルート・ノー
    ドと、前記共有資源に対応し前記階層ツリーの少なくと
    も１つの中間レベルに位置付けられる複数の中間ノード
    とを有する階層ツリー構造の形状で、前記プロセッサと
    共有資源との物理的構成を表現する前記抽象概念を維持
    する前記手段と、 前記階層ツリーの各ノードについて実行キューを形成す
    るステップであって、リーフ・ノードと関連付けられた
    各実行キューは前記関連するプロセッサに親和化された
    アクティブなプロセスを識別し、残りのノードの１つと
    関連付けられた各実行キューは、前記ノードと関連付け
    られたリソースを共有する前記プロセッサの群に親和化
    されたアクティブなプロセスを識別するように、前記階
    層ツリーの各ノードについて実行キューを形成する手段
    と、 前記システム内の各アクティブなプロセスの進展を監視
    し、所定時間期間の間に進展しない各アクティブなプロ
    セスを、前記階層ツリー内のより高いレベルのノードの
    実行キューに昇進させる中期スケジューラと、から成る
    ことを特徴とする前記オペレーティング・システム。
16. 【請求項１６】請求項１５記載のオペレーティング・シ
    ステムであって、更に、 前記プロセッサの１つと関連付けられ、該関連するプロ
    セッサのために前記実行キューを監視し、前記関連する
    プロセッサが実行するために、前記実行キューの中で最
    高の優先度を有するアクティブなプロセスを選択する、
    少なくとも１つのディスパッチャを含み、 前記中期スケジューラは、第２所定時間期間の間に進展
    しない各アクティブなプロセスの優先度を高める、こと
    を特徴とする前記オペレーティング・システム。
17. 【請求項１７】請求項１６記載のオペレーティング・シ
    ステムにおいて、 前記中期スケジューラは、第３所定時間期間の間に進展
    しない各プロセスにフラグをセットし、 前記ディスパッチャは前記関連するプロセッサの実行キ
    ューを監視し、前記関連するプロセッサが実行するため
    に、他のプロセッサの実行キューからプロセッサを捜し
    て獲得し、 前記ディスパッチャが複数の入手可能なプロセスを有す
    る実行キューを見つけたとき、前記ディスパッチャはフ
    ラグがセットされているプロセスを選択する、ことを特
    徴とする前記オペレーティング・システム。
18. 【請求項１８】種々のアクティブなプロセスを実行する
    ための複数のプロセッサと、各々前記プロセッサの異な
    る組み合わせによって共有される複数の共有資源とを含
    むハードウエア・アーキテクチャを有するマルチプロセ
    ッサ・システムにおいて、均衡化したプロセッサ負荷を
    維持する方法であって、 前記マルチプロセッサ・システムのハードウエア・アー
    キテクチャの抽象概念を維持するステップであって、前
    記プロセッサに対応し階層ツリーの最低レベルに位置付
    けられる複数のリーフ・ノードと、前記プロセッサおよ
    び共有資源の全てによって共有される共通資源に対応し
    前記階層ツリーの最高レベルに位置付けられるルート・
    ノードと、前記共有資源に対応し前記階層ツリーの少な
    くとも１つの中間レベルに位置付けられる複数の中間ノ
    ードとを有する階層ツリー構造の形状で、前記プロセッ
    サと共有資源との物理的構成を表現する前記抽象概念を
    維持するステップと、 前記階層ツリーの各ノードについて実行キューを形成す
    るステップであって、リーフ・ノードと関連付けられた
    各実行キューは前記関連するプロセッサに親和化された
    アクティブなプロセス群を識別し、残りのノードの１つ
    と関連付けられた各実行キューは、前記ノードと関連付
    けられたリソースを共有する前記プロセッサの群に親和
    化されたアクティブなプロセス群を識別するように、前
    記階層ツリーの各ノードについて実行キューを形成する
    ステップと、 前記システム内の各アクティブなプロセスの進展を監視
    するステップと、 所定時間期間の間に進展しない各アクティブ・プロセス
    を、前記階層ツリー内のより高いレベルのノードの実行
    キューに昇進させるステップと、から成ることを特徴と
    する前記方法。
19. 【請求項１９】各々実行キューが関連付けられた複数の
    プロセッサを有するマルチプロセッサ・システムのため
    のオペレーティング・システムであって、 前記システム内の各アクティブなプロセスの進展を監視
    し、所定時間期間の間に進展しない各アクティブなプロ
    セスを、前記階層ツリー内のより高いレベルのノードの
    実行キューに昇進させる中期スケジューラと、 前記プロセッサの１つと関連付けられ、該関連するプロ
    セッサによって実行されるプロセスが待ち行列をなす実
    行キューを監視し、前記関連するプロセッサが実行する
    ために、前記実行キューの中で最高の優先度を有するア
    クティブなプロセスを選択する、少なくとも１つのディ
    スパッチャと、から成ることを特徴とする前記オペレー
    ティング・システム。
20. 【請求項２０】複数のプロセッサと、各々前記プロセッ
    サの異なる組み合わせによって共有される複数の共有メ
    モリー資源とを含むハードウエア・アーキテクチャを有
    するマルチプロセッサ・システムのためのオペレーティ
    ング・システムであって、 前記マルチプロセッサ・システムのハードウエア・アー
    キテクチャの抽象概念を維持する手段であって、前記プ
    ロセッサに対応し階層ツリーの最低レベルに位置付けら
    れる複数のリーフ・ノードと、前記プロセッサおよび共
    有メモリー資源の全てによって共有される共通資源に対
    応し前記階層ツリーの最高レベルに位置付けられるルー
    ト・ノードと、前記共有メモリー資源に対応し前記階層
    ツリーの少なくとも１つの中間レベルに位置付けられる
    複数の中間ノードとを有する階層ツリー構造の形状で、
    前記プロセッサと共有メモリー資源との物理的構成を表
    現する前記抽象概念を維持する前記手段と、 共有物理メモリ資源を表わす各ノードにおいてフレーム
    ・トラジェリを維持し、前記メモリ資源の物理メモリの
    フレーム管理および割り当てを制御し、関連するトラジ
    ェリを有する全てのノードに共通なノードを高位ポリシ
    ・ノードとして識別し、前記プロセッサの少なくとも１
    つが用いるために、前記フレーム・トラジェリから物理
    メモリのフレームを割り当てる手段と、から成ることを
    特徴とする前記システム。
21. 【請求項２１】請求項２０記載のオペレーティング・シ
    ステムであって、更に、物理メモリ空間に対するプロセ
    ス要求を受け、どのノードから前記要求された物理メモ
    リ空間を割り当てるかを識別し、前記識別されたノード
    と関連付けられたフレーム・トラジェリから、前記要求
    された物理メモリ空間を割り当てる、メモリ・マネージ
    ャを含むことを特徴とする前記オペレーティング・シス
    テム。
22. 【請求項２２】請求項２１記載のオペレーティング・シ
    ステムにおいて、前記識別されたノードはポリシ・ノー
    ドであり、前記メモリ・マネージャは、該ポリシ・ノー
    ドのポリシ制約に基づいて、前記ポリシ・ノードと関連
    付けられた１つ以上の関連するフレーム・トラジェリか
    ら、前記要求された物理メモリを割り当てることを特徴
    とする前記オペレーティング・システム。
23. 【請求項２３】種々のプロセスを実行する複数のプロセ
    ッサと、前記プロセッサの異なる組み合わせによって各
    々共有される複数の共有メモリー資源とを有するマルチ
    プロセッサ・システムのためのオペレーティング・シス
    テムを具現化するプログラム・コードを収容したコンピ
    ュータ読み取り可能媒体であって、前記オペレーティン
    グ・システムは、 前記マルチプロセッサ・システムのハードウエア・アー
    キテクチャの抽象概念を維持するステップであって、前
    記プロセッサに対応し階層ツリーの最低レベルに位置付
    けられる複数のリーフ・ノードと、前記プロセッサおよ
    び共有メモリー資源の全てによって共有される共通資源
    に対応し前記階層ツリーの最高レベルに位置付けられる
    ルート・ノードと、前記共有メモリー資源に対応し前記
    階層ツリーの少なくとも１つの中間レベルに位置付けら
    れる複数の中間ノードとを有する階層ツリー構造の形状
    で、前記プロセッサと共有メモリー資源との物理的構成
    を表現する前記抽象概念を維持する前記ステップと、 共有物理メモリ資源を表わす各ノードにおいてフレーム
    ・トラジェリを維持し、前記メモリ資源の物理メモリの
    フレーム管理および割り当てを制御するステップと、 関連するトラジェリを有する全てのノードに共通なノー
    ドを高位ポリシ・ノードとして識別し、前記プロセッサ
    の少なくとも１つが用いるために、前記フレーム・トラ
    ジェリから物理メモリのフレームを割り当てるステップ
    と、から成る方法を実行する、前記オペレーティング・
    システムを収容することを特徴とする前記コンピュータ
    読み取り可能媒体。
24. 【請求項２４】複数のプロセッサと、各々前記プロセッ
    サの異なる組み合わせによって共有される複数の共有メ
    モリー資源とを含むハードウエア・アーキテクチャを有
    するマルチプロセッサ・システムのためのオペレーティ
    ング・システムであって、 前記マルチプロセッサ・システムのハードウエア・アー
    キテクチャの抽象概念を維持する手段であって、前記プ
    ロセッサに対応し階層ツリーの最低レベルに位置付けら
    れる複数のリーフ・ノードと、前記プロセッサおよび共
    有メモリー資源の全てによって共有される共通資源に対
    応し前記階層ツリーの最高レベルに位置付けられるルー
    ト・ノードと、前記共有メモリー資源に対応し前記階層
    ツリーの少なくとも１つの中間レベルに位置付けられる
    複数の中間ノードとを有する階層ツリー構造の形状で、
    前記プロセッサと共有メモリー資源との物理的構成を表
    現する前記抽象概念を維持する前記手段と、 前記ルート・ノードと関連付けられ、割り当てられ得る
    物理メモリの各フレームのリストと、リストされている
    各フレームと関連付けられ、当該フレームが位置する前
    記メモリ資源を表わすノードを識別するポインタとを含
    む、高位フレーム・テーブルを維持する手段と、から成
    ることを特徴とする前記オペレーティング・システム。
25. 【請求項２５】複数のプロセッサと、各々前記プロセッ
    サの異なる組み合わせによって共有される複数の共有メ
    モリー資源とを含むハードウエア・アーキテクチャを有
    するマルチプロセッサ・システムのためのオペレーティ
    ング・システムであって、 前記マルチプロセッサ・システムのハードウエア・アー
    キテクチャの抽象概念を維持する手段であって、前記プ
    ロセッサに対応し階層ツリーの最低レベルに位置付けら
    れる複数のリーフ・ノードと、前記プロセッサおよび共
    有メモリー資源の全てによって共有される共通資源に対
    応し前記階層ツリーの最高レベルに位置付けられるルー
    ト・ノードと、前記共有メモリー資源に対応し前記階層
    ツリーの少なくとも１つの中間レベルに位置付けられる
    複数の中間ノードとを有する階層ツリー構造の形状で、
    前記プロセッサと共有メモリー資源との物理的構成を表
    現する前記抽象概念を維持する前記手段と、 前記システムの仮想メモリの割り当てのために、メモリ
    ・ロカールを表わす各ノードにおいてメモリ・プールを
    維持し、前記仮想メモリをプール単位に分割して前記メ
    モリ・プールに割り当てる手段と、 プール単位および該プール単位の各々が割り当てられて
    いる前記メモリ・プールの可用性を識別する、プール単
    位テーブルを維持する手段と、から成ることを特徴とす
    る前記オペレーティング・システム。
26. 【請求項２６】請求項２５記載のオペレーティング・シ
    ステムであって、更に、仮想メモリ空間に対するプロセ
    ス要求を受け、該要求された仮想メモリ空間をどのメモ
    リ・プールから割り当てるかを識別し、前記識別された
    メモリ・プールが十分な仮想メモリ空間を有していない
    場合、前記識別されたメモリ・プールに対する前記プー
    ル単位テーブルから、追加のプール単位を得て、前記識
    別されたメモリ・プールから前記要求されたメモリ空間
    を割り当てる、メモリ・マネージャを含むことを特徴と
    する前記オペレーティング・システム。
27. 【請求項２７】請求項２６記載のオペレーティング・シ
    ステムにおいて、前記メモリ・マネージャは、前記識別
    されたメモリ・プールと関連付けられた物理メモリ空間
    で、前記要求された仮想メモリ空間を支えることを特徴
    とする前記オペレーティング・システム。
28. 【請求項２８】請求項２５記載のオペレーティング・シ
    ステムであって、仮想メモリ空間を放出し、解放された
    仮想メモリ空間が属するプール単位を識別し、前記プー
    ル単位テーブルにアクセスし、前記識別されたプール単
    位が属するメモリ・プールを識別し、前記解放された仮
    想メモリ空間を前記識別されたメモリ・プールに放出す
    る、メモリ・マネージャを含むことを特徴とする前記オ
    ペレーティング・システム。
29. 【請求項２９】請求項２８記載のオペレーティング・シ
    ステムにおいて、前記メモリ・マネージャは、各メモリ
    ・プールにおいて、プール単位にサイズが等しい連続す
    る解放仮想メモリ空間を捜し、前記プール単位テーブル
    にエントリを配置し、前記解放仮想メモリと関連付けら
    れた前記プール単位がメモリ・プールへの割り当てに利
    用可能であることを指示することによって、前記解放仮
    想メモリを放出することを特徴とする前記オペレーティ
    ング・システム。
30. 【請求項３０】種々のアクティブなプロセスを実行する
    複数のプロセッサと、各々前記プロセッサの異なる組み
    合わせによって共有される複数の共有メモリー資源とを
    有するマルチプロセッサ・システムのためのオペレーテ
    ィング・システムを具現化するプログラム・コードを収
    容したコンピュータ読み取り可能媒体であって、前記オ
    ペレーティング・システムは、 前記マルチプロセッサ・システムのハードウエア・アー
    キテクチャの抽象概念を維持するステップであって、前
    記プロセッサに対応し階層ツリーの最低レベルに位置付
    けられる複数のリーフ・ノードと、前記プロセッサおよ
    び共有メモリー資源の全てによって共有される共通資源
    に対応し前記階層ツリーの最高レベルに位置付けられる
    ルート・ノードと、前記共有メモリー資源に対応し前記
    階層ツリーの少なくとも１つの中間レベルに位置付けら
    れる複数の中間ノードとを有する階層ツリー構造の形状
    で、前記プロセッサと共有メモリー資源との物理的構成
    を表現する前記抽象表現を維持する前記ステップと、 前記システムの仮想メモリの割り当てのためのメモリ・
    ロカールを表わす各ノードにおいてメモリ・プールを維
    持し、前記仮想メモリを、前記メモリ・プールに割り当
    て可能なプール単位に分割するステップと、 プール単位と、該プール単位の各々が割り当てられてい
    るメモリ・プールとの可用性を識別するプール単位テー
    ブルを維持するステップと、から成る方法を実行する、
    前記オペレーティング・システムを収容することを特徴
    とする前記コンピュータ読み取り可能媒体。