JP2011501268A - 階層的予約資源スケジューリング・インフラストラクチャ - Google Patents

Abstract

システム資源のスケジューリング。作業負荷内部における動作のスケジューリングを行うためのシステム資源スケジューリング方針にアクセスする。この方針は、作業負荷に基づいて指定され、この方針が作業負荷に特定的となるようにしている。システム資源は、方針によって指定されるように、作業負荷のために予約される。予約は、その本質が階層的となるようにし、作業負荷群も階層的に配列するとよい。更に、作業負荷をシステム資源に配分する配分メカニズムは、方針とは独立して実装することができる。システム資源使用に関するフィードバックを用いて、配分メカニズムを制御するための方針選択を決定することができる。
【選択図】 図１

Description

背景および関連技術
コンピューターおよびコンピューティングシステムは、現代生活のほぼあらゆる面に影響を及ぼしてきている。コンピューターは、一般に、仕事、リクリエーション、健康管理、輸送、娯楽、家事管理などに関わっている。家庭用コンピューター、業務用ワークステーション、およびその他のシステムのような、汎用コンピューターを含む多くのコンピューターは、種々の異なる動作を実行する。動作は、作業負荷(workload)群に分類することができ、１つの作業負荷が、個々のタスクまたは目的を遂行するための１組の動作を定める。例えば、１つの作業負荷は、メディア・プレーヤ・アプリケーションを実施するために割り振ることができる。別の作業負荷は、ワード・プロセッサー・アプリケーションを実施するために割り振ることができる。更に別の作業負荷は、カレンダー管理、電子メール、またはその他管理アプリケーションを実施するために割り振ることができる。以前から暗に言われているように、多数の異なる作業負荷が１つのシステム上で一緒に動作している場合もあり得る。

作業負荷群が１つのシステム上で一緒に動作することを可能にするには、システム資源の適性なスケジューリングを行い、異なる作業負荷群に割り当てなければならない。例えば、１つのシステム資源はプロセッサーを含む。このプロセッサーは、メディア・プレーヤ・アプリケーションのためにはディジタル・メディア・デコード処理を実行し、ワード・プロセッサー・アプリケーションのためにはフォントの助言(hinting)およびその他の表示機能を実行し、個人管理アプリケーションのためにはアルゴリズム計算を実行する能力を有することができる。しかしながら、１つのプロセッサーでは、通例、いずれの所与の１時点においても１つのタスク、または限られた数のタスクしか実行することができない。このため、システム資源を種々の作業負荷間で共有できるように、スケジューリング・アルゴリズムが、プロセッサーのような、システム資源のスケジューリングを行うとよい。

通例、システム資源のスケジューリングを行うには、異なる作業負荷の本質が異なっていても、全ての作業負荷に対して汎用アルゴリズムを用いる。言い換えると、所与のシステムに対して、システム全体の作業負荷に捕らわれない方針を用いて、システム資源のスケジューリングが実行される。

本願において特許請求する主題は、先に述べたような環境における欠点をいずれも解消する実施形態、またはその環境だけで動作する実施形態に限定されるのではない。逆に、この背景は、本明細書において記載する実施形態の一部を実用化することができる技術分野の一例を例示するために提唱したに過ぎない。

摘要
本明細書において記載する一実施形態は、システム資源のスケジューリング方法を含む。この方法は、システム資源スケジューリング方針を作業負荷に割り当てることを含む。この方針は、作業負荷内部における作業負荷動作のスケジューリングを行うためにある。この方針は、作業負荷に基づいて指定され、方針が作業負荷に特定的となるようにする。システム資源は、方針によって指定されるように、作業負荷のために予約される。

別の実施形態は、システム資源を用いて作業負荷を実行する方法を含む。システム資源は、システム特定方針にしたがって、作業負荷のための予約において予約されており、予約は、作業負荷特定方針を適用するために作業負荷によって用いられる。この方法は、方針を選択することを含む。方針は、作業負荷内部における作業負荷動作のスケジューリングを行うためにある。方針は、作業負荷をシステム資源に配分するために用いられる。作業負荷を実行したときのシステムの使用に関する情報を含むフィードバックを受ける。更に作業負荷をシステム資源に配分するために、フィードバックに基づいて、方針決定を行う。

更に別の実施形態では、システム資源上において作業負荷を実行する方法を実現する。この方法は、１つ又は複数の作業負荷に対する１つ又は複数のシステム資源スケジューリング方針にアクセスすることを含む。方針は、作業負荷内部における作業負荷動作のスケジューリングを行うためにあり、所与の方針が所与の作業負荷に特定的となるように、作業負荷に基づいて指定される。方針によって指定されるようにシステム資源の予約を示す実行計画を定式化する。作業負荷は、実行計画に基づいて、システム資源に配分される。

この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断するために用いることも意図していない。

本発明の更に別の特徴および利点は、以下に続く説明に明記されており、部分的にこの説明から自明であり、あるいは本発明の実施によって習得することもできる。本発明の特徴および利点は、添付した特許請求の範囲に特に指定した手段(instrument)および組み合わせによって実現し、獲得することができる。本発明の特徴は、以下の説明および添付した特許請求の範囲から更に一層明らかとなるであろうし、あるいは以下に明記するように、本発明の実施によって習得することができる。

本発明の先に明記した利点および特徴ならびにその他の利点および特徴を得ることができる態様について説明するために、添付図面に例示する具体的な実施形態を参照して、先に端的に説明した本発明の一層特定的な説明を行う。これらの図面は本発明の典型的な実施形態のみを図示するのであり、したがってその範囲を限定するように解釈すべきでないことを理解した上で、添付図面の使用により、実施形態について更に具体的にそして詳細に記載し説明する。
図１は、階層的作業負荷および方針構造を示す。 図２は、システム資源の予約を示す実行計画を示す。 図３は、資源管理システムおよびシステム資源を示す。 図４は、プロセッサー管理の一例を示す。 図５は、デバイス資源管理部を示す。 図６は、システム資源の予約方法を示す。 図７は、予約にしたがってシステム資源を管理する方法を示す。 図８は、一部の実施形態を実現することができる環境例を示す。

本明細書において、実施形態の一部は、種々のコンピューター・ハードウェアを含む特殊目的コンピューターまたは汎用コンピューターを備えることができる。これについては、以下で更に詳しく論ずることにする。また、実施形態の一部は種々の方法要素を含むこともできる。

作業負荷に特定した方針にしたがって、作業負荷動作のためのシステム資源予約方針を摘要する実施形態を実現することができる。言い換えると、システム資源のスケジューリングを行う全ての作業負荷に全般的に適用可能な総合的汎用方針にしたがって資源予約を実行するのではなく、所与の作業負荷に特定して指定する方針に基づいて、システム資源をスケジューリングする。加えて、階層的に適用可能な方針にしたがって、作業負荷の予約を遂行することができる実施形態も実現することができる。図１は、数々の実施形態に適用することができる種々の特徴および態様を実現する一実施形態を示す原理の一例を示す。

図１は、システム資源１００を示す。システム資源は、例えば、処理資源、ネットワーク・アダプター資源、メモリー資源、ディスク資源等のようなハードウェアを含むことができる。システム資源は、作業負荷を実行することができる。作業負荷は、プログラムがシステム資源に向けて発生するサービス要求を含む。例えば、プロセッサーに該当する作業負荷は、例えば、プロセッサーの計算を実行する要求を含む。ネットワーク・アダプター資源に該当する作業負荷は、例えば、ネットワーク送信および受信動作、ネットワーク帯域の使用等を含む。メモリー資源に該当する作業負荷は、例えば、メモリー・リードおよびメモリー・ライトを含む。ディスク資源に該当する作業負荷は、例えば、ディスク・リードおよびディスク・ライトを含む。

コンテキストに応じて、作業負荷は、ユーザーまたは他のプログラム活動の結果としてプログラムが発生する要求パターンを指すこともあり、異なるレベルの要求粒度(request granularity)を表すこともあり得る。例えば、電子商取引作業負荷は、多数のサーバーに跨る可能性があり、エンド・ユーザーまたは他の業務機能によって生成されるある種の要求資源パターンを伴う。

作業負荷は、実行オブジェクトに関して定義することもできる。実行オブジェクトとは、資源を消費する作業負荷抽象化のインスタンスである。例えば、実行オブジェクトは、プロセッサーおよびメモリーを消費するスレッド、ＮＩＣ帯域幅を消費するソケット、ディスク帯域幅を消費するファイル記述子等である場合がある。

作業負荷に対してシステム資源を予約することができる。図１に示す作業負荷の内２つは、メディア・プレーヤ作業負荷１０２およびワード・プロセッシング作業負荷１０４を含む。これらの作業負荷の各々は、それぞれ、メディア・プレーヤ・アプリケーションおよびワード・プロセッシング・アプリケーションを実施する際に用いられる動作を定める。更に、図１は、これら２つの作業負荷は、各々、これらには異なる方針１０６および１０８がそれぞれ関連付けられていることも示す。これらの方針は、作業負荷１０２および１０４を実行するようにスケジューリングするために、システム資源１００をどのように予約すべきかを定めている。

種々の方針を実現することができる。例えば、１つの方針は、比率基準予約方針である。比率予約は、所定間隔でシステム資源容量の割合の形態で予約を繰り返すことを含む。例えば、比率予約方針は、ある分量のプロセッサー・サイクルを予約すべきことを指定することができる。例えば、比率予約方針では、１，０００，０００回のプロセッサー・サイクル毎に、その内の２，０００サイクルを、その方針が適用される作業負荷に割り当てるべきことを指定することができる。この種の予約は、反復作業負荷に適していることが多い。この方針の一例を、メディア・プレーヤ作業負荷１０２について示す。この場合、方針１０６は１０ｍｓ毎に１ｍｓをメディア・プレーヤ作業負荷１０２のために予約すべきことを指定している。

別の方針は、容量に基づく予約に関する。容量予約では、デバイスの容量の百分率を指定し、この容量が利用可能でなければならない時間枠には制約がない。これらの種類の方針の方が柔軟にスケジューリングすることができる。何故なら、予約の保証は時間枠を有さないからである。これの一例を、ワード・プロセッサー作業負荷１０４について示す。この場合、方針１０８は、システム資源１００の内１０％をワード・プロセッサー作業負荷１０４のために予約すべきことを指定している。

注記すべきは、方針１０６および１０８はそれらの各アプリケーションに特定的であるということであり、方針は個々のアプリケーション毎に指定されることを意味する。個々のアプリケーション毎の指定は、各アプリケーションを特定的に１つの方針に関連付けることによって遂行することができる。別の実施形態では、アプリケーションの種別を方針と関連付けることもできる。本明細書に開示する実施形態の範囲内では、他の集合体を実現することもできる。

図１に示すように、各予約は、更に詳細予約(sub-reservation)に分割することができる。予約および詳細予約を用いると、予約およびデフォルト方針の樹木状階層(tree hierarchy)を作成することができる。この階層のリーフ・ノードは、予約方針を含む。例えば、図１は、メディア・プレーヤ作業負荷１０２の下に階層状にコデック作業負荷１１０および表示作業負荷１１２があることを示す。これらの作業負荷と関連付けられているのは、それぞれ、方針１１４および１１６である。これらの方針１１４および１１６は、階層的に、メディア・プレーヤ作業負荷１０２に対する方針１０６の下にある。更に、図１は、他の階層的に配列した作業負荷および方針も示す。例えば、コデック作業負荷１１８、１２０、および１２２は、階層的にコデック作業負荷１１０の下にある。同様に、方針１２４、１２６、および１２８は、階層的に方針１１４の下にある。また、図１は、作業負荷１３０および１３２が階層的に作業負荷１０４の下にあること、そして方針１３４および１３６が階層的に方針１０８の下にあることも示す。

図１は、この例では、方針が容量に基づく予約に関して予約を指定することができ、ワード・プロセッサー作業負荷１０４において示すように、資源の百分率を指定することを示す。ワード・プロセッサー作業負荷１０４では、全システム資源１００の内１０％が指定されている。図示のように、この全システム資源の内の１０％の予約は、図１に示すような、階層的に下位にある作業負荷間において細分することができる。この場合、方針１３４は、全システム資源の内６％をＵＩ作業負荷１３４のために予約すべきことを指定し、方針１３６は、全システム資源の内２％をフォント助言作業負荷１３２のために予約すべきことを指定している。更に、図１は、方針１０６が比率に基づく方針を指定しており、これによって、方針１０６は、１０ｍｓ毎に１ｍｓをメディア・プレーヤ作業負荷１０２のために予約すべきことを指定していることも示す。

実施形態によっては、２つの容量閾値パラメータ、即ち、ソフトおよびハードを用いて予約を行うこともできる。ソフト・パラメータは、ハード容量以上のシステム資源要求を指定する。ソフト値は、最適な性能を達成するために必要となる容量である。ハード値は、作業負荷を動作させるために必要となる最小限の予約値である。実施形態によっては、予約管理システムがソフト容量要求を満たそうとするが、ソフト容量要求を満たすことができない場合、予約管理システムは代わりにハード値を用いようとすることもある。予約管理システムは、動作のために予約した資源量を削減することによるというようにして、予約を減少させることができる。ハード容量値に見合う容量がデバイスの中にない場合、実施形態によっては、予約管理システムはアプリケーションを実行しないこともある。

閾値に加えて、予約を予約緊急度と関連付けることもできる。予約緊急度とは、予約に関する優先度を決定する計量値である。予約緊急度は、システムが過大に割り当てられ、予約管理システムが、保留中の予約の内部分集合にしか資源を割り当てることができない場合に適用可能である。緊急度が高い方の予約が実行しようとする場合、予約管理システムは、緊急度が低い方の予約に、その予約を解除しなければならないことを通知する。この通知は、予約が解除されない場合、アプリケーションの終了に発展する。尚、予約緊急度は必ずしも先取りスケジューリング・メカニズムではなく、むしろ新たな予約が要求されたが資源が入手できないときに適用される割り当て優先度とすることもできる。

実行オブジェクトにオブジェクト特定方針予約要件がない場合、デフォルトの方針を用いて、いずれの実行オブジェクトでもスケジューリングすることができる。図１は、方針１３８、１４０、および１４２を含む、多数のデフォルト方針を示す。予約管理システムは、比率予約で予約されていない全てのタイムスロットを、容量予約またはデフォルト予約のいずれかに割り当てる。全てのデバイスに対するデフォルト方針は、システム全体において同一とすることができる。これを行うのは、負荷均衡化動作を簡略化するためである。注記すべきは、デフォルト方針が、残っている容量であればいずれでも含むというような単純なことではない場合もあることである。例えば、比率容量に基づいて、方針１０８が１０％の予約を指定し、方針１０６が１０％の予約を指定している間、デフォルト・スケジューリング方針１３８は、他に何の予約もない場合、スケジューリングすることができる少なくとも８０％のシステム資源を有する。メディア・プレーヤ作業負荷１０２またはワード・プロセッサー作業負荷１０４の一方または双方が、それぞれの予約量全部を必要とせず、システム資源予約の一部を、デフォルト・スケジューリング方針１３８が用いるために戻すと決定した場合には、デフォルト方針１３８に入手可能な資源は８０％よりも多くなることもあり得る。

デフォルト予約を、資源割り当ての備忘(reminder)を扱う方針と関連付けることもできる。ルート・ノードと同様に、各詳細予約は、このコンテキストにおいて動作し他に予約要件を有さない実行オブジェクトに対するデフォルト配置方針(default placing policy)を含むことができる。例えば、デフォルト方針１４０および１４２は、詳細予約デフォルト・スケジューリングのために用いられる。

実行計画とは、資源管理システム・コンポーネントが予約およびデバイス容量に関する情報を捕獲ために用いる抽象概念(abstraction)である。具体的には、実行計画は、ディスパッチャ(dispatcher)によって作用する資源予約を表す下位計画である。実行計画の一例を図２に示す。実行計画２００は、予約によって指定されたシステム資源のスケジューリングを示す。例示した実行計画２００は、プロセッサーのようなシステム資源についての、時間に基づく実行計画である。この例では、時間に基づく実行計画を例示するが、他のデバイスには、異なる実行計画を実施してもよいことは認められてしかるべきである。例えば、ネットワーク・デバイスに対する実行計画は、通信経路上で送られる一連のパケットで表すことができる。他の例には、メモリーのヒープのスライス、ディスクのブロック等が含まれる。ここで時間に基づく例に戻ると、実行計画は、一連のタイム・スライスであり、当該タイム・スライスを消費する役割を担う個々の方針によって管理される。予約タイム・スライスを所有する方針は、割り当て量(quanta)を用いて、更に細かい粒度にした間隔に予約の時間を区切り(time-slice)、それが管理する実行オブジェクト間で多重化することができる。スライスの粒度は、デバイスのコンテキストによって異なる。例えば、プロセッサーは、タイマーの分解能、パケット・サイズに左右され、ＮＩＣはパケット・サイズに左右され、メモリーはヒープ・サイズに左右され、ディスクはブロックに左右される等となる。

実行計画２００は、メディア・プレーヤ作業負荷１０２のための第１予約２０２と、ワード・プロセッサー作業負荷１０４のための第２予約２０４とを示す。この図示する例では、実行計画２００は、特定の作業負荷のために予約されている資源の時間期間を例示する。この例では、予約２０２および２０４は周期的に繰り返すように示されているが、予約のスケジューリングを行うために用いられる方針によっては、他の割り当ても実施することができる。例えば、予約２０２は、１０ｍｓ毎に１ｍｓをメディア・プレーヤ作業負荷１０２のために予約する必要性のために、本質的に周期性が強くてもよい。一方、予約２０４は、作業負荷をスケジューリングする方針が単にシステム資源の１０％を指定するだけであるため、もっと柔軟性があってもよい。

実行計画は、様々な機能のために用いることができる。一例では、実行計画は、十分なデバイス容量が新たな予約に利用可能か否か査定するために用いることができる。例えば、実行計画２００は、時間軸(time basis)上における利用可能なシステム資源の指示２０６を含む。予約要求を受けたとき、この指示２０６を参照して、予約要求に応対できるか否か判断することができる。

また、実行計画は、比率予約要求を満たすための間隔が得られるか否か査定するために用いることもできる。予約要件を満たすだけの十分な容量をデバイスが有していても、既存の比率予約と競合している場合、予約の頻度および継続期間を満たすのに適したスロットが得られない場合がある。

また、実行計画は、予約管理部が新たな方針のコンテキストを選択するために効率的に概観する(walk through)ことができる一連の動作を作成するために用いることもできる。これについては、図３の説明と共に以下で更に詳しく論ずる。

実行計画の計算は、新たな予約をデバイスに割り当てるときまたは予約構成(reservation configuration)が変更になったときに、広範な動作が生ずることが多い。一実施形態では、デバイス資源管理部によって計画を計算する。

予約は、デバイスの種類に特定的な容量計量値を用いる。この計量値は、資源およびオペレーティング・システムのコンフィギュレーションとは独立でなければならない。しかしながら、オペレーティング・システムはデバイスの容量に関する情報を提供することもできる。

容量予約は、実行計画の一部として静的にスケジューリングすることができ、あるいは予約管理部によって割り当てられるタイム・スライスのように動的にスケジューリングすることもできる。静的な予約は、例えば、資源の動的な評価(evaluation)および査定(assessment)とは逆に、予め割り当てた分割部分を割り当てることを含むことができる。静的割り当ては、資源管理部の性能オーバーヘッドを低く抑える利点がある。動的割り当ては、スケジューリング階層の同じレベルのデフォルト方針において実行する負荷を扱う際に柔軟性を高めることができる。

これより図３を参照すると、予約管理アーキテクチャ・システム３００が示されている。先に説明したスケジューリング階層は、全てのデバイスについて従う共通のスケジューリング・パラダイムとすることができる。しかしながら、階層の深さおよび広さ、ならびに方針の複雑度は、デバイス毎に異なる。

予約管理アーキテクチャ・システム３００のコンポーネントは、２つのカテゴリー、即ち、記憶部および手順に編成されている。これらのコンポーネントは、方針、デバイス種別のいずれかに特定的であるか、あるいは汎用である。図３において、方針コンポーネント群が一緒に纏められている。他の全ての手順は、デバイス種別に特定的である。記憶部は、方針状態記憶部３０２は例外であるが、システムのデバイス全てに共通である。以下の一連の動作は、典型的なスケジューリング・セッションにおいて実行され、新たな実行オブジェクトを予約管理システム３００に投入することから開始する。

１に示すように、方針３０４−１にしたがって、新たな実行オブジェクトを予約管理システム３００に投入する。配置アルゴリズム３０６が、この実行オブジェクトを、方針状態記憶部３０２に格納されているキューの１つに移動させる。方針状態記憶部３０２は、実行の優先順位または状態を表すことができるキューを含む、方針の内部状態を格納する。

２に示すように、配置アルゴリズム３０６は、方針配分アルゴリズム３０８をコールする。方針配分アルゴリズム３０８は、次の実行オブジェクトを実行のために選別する。

３において、デバイス・ディスパッチャ３１０をコールし、実行のために選択された実行オブジェクトに対してコンテキスト切換を行う。ディスパッチャ３１０は、方針３０４−１または方針３０４−１から３０４−Ｎまでのいずれとも別個にかつ独立して実装されている。即ち、ディスパッチャ３１０は、適用する方針とは無関係に用いることができる。

４において、予約管理システム３００のディスパッチャ３１０は、システム資源３１２に前述の実行オブジェクトを実行させる。注記すべきは、システム資源３１２は予約管理システム３００とは別個であってもよいことである。デバイスのコンテキストに応じて、実行オブジェクトの実行を保留にするかまたは完了する。例えば、プロセッサーの例では、プロセッサーに対して割り当てられたタイム・スライスが終了するか、または実行オブジェクトは待機しておりしかも凍結されているか、または実行オブジェクトは自発的に放棄される。

５に示すように、方針状態遷移手順３１４を呼び出し、実行オブジェクト記憶部３１６および方針状態記憶部３０２において実行オブジェクトの状態を更新する。

６に示すように、時間アカウンティング手順(time accounting procedure)３１８が、資源コンテナ記憶部３２０を用いて、実行オブジェクトの使用統計を更新する。資源コンテナは、タスクを達成するために作業負荷によって用いられるシステム資源を論理的に収容する抽象概念である。例えば、資源コンテナは、ホストされるアプリケーションのコンポーネント全てについて定めることができる。資源コンテナは、アプリケーションによる資源の使用に関する統計情報を格納する。

７において、予約管理部３２２は、次の予約がどれであるか判断し、次の方針を実行するために然るべきスケジューラ・コンポーネントを呼び出す。これを達成するには、一実施形態では、図２に示す実行計画のような実行計画全体を調べる。図３に示す例では、この動作には２つの潜在的な成果がある。第１の成果は、図２に示したタイム・スライスの内の１つのようなスライス、またはパケット・スライス、ヒープ・スライス、ブロック・スライス等のその他のスライスが適宜スケジューリング階層の現在のレベルにおける現在の方針に割り当てられる。図３における８Ｂに示すように、現在の方針の配分アルゴリズム３０８をコールする。第２の成果は、方針３０４−２のような異なる方針または３０４−Ｎまでの他のいずれかの方針を用いての別の予約への切換を含み、ここでＮは表される方針の数である。予約管理部３２２は次の予約（図では８Ａとして示す）の実行計画に切り換えて、新たな計画を用いて同じ動作を実行する。

総合実行オブジェクト記憶部３１６は、スケジューリング方針（例えば、３０４−１）からはアクセスできない場合もあるが、逆に方針によって現在管理されている実行オブジェクトのビューは見ることができる。潜在的な性能利得に加えて、これは、方針が、そのコンテキストにおいてスケジューリングされていない実行オブジェクトの状態を修正しようとしないことを保証する。１つのデバイスから他のデバイスへの負荷均衡動作は、異なるデバイス上において実行している予約間において実行オブジェクトを移動させることによって遂行することができる。状態遷移手順３１４および配分手順３１０は、方針状態記憶部３０２と実行オブジェクト記憶部３１６との間における不一致を検出し、補正処置を講ずる。殆どの場合、補正処置は余分なスケジューリング動作を実行することを伴う。

これより図４を参照すると、プロセッサー・スケジューラの潜在的実施態様が示されている。注記すべきは、他の実施態様、ならびにネットワーク資源、メモリー資源、ディスク資源等のような異なるシステム資源に対する別の実施態様も実現できることである。図４に提案するスケジューリング・フレームワークでは、共通インフラストラクチャによって調整される多数のスケジューリング方針によって、プロセッサーのスケジューリングが行われる。インフラストラクチャによって提供されるプロセッサー・スケジューラのコンポーネント、および方針によって提供されるコンポーネントを図４に示す。プロセッサーのコンテキストでは、以下の機能が実装される。タイマー・サポート、コンテキスト切換、および凍結通知。

プロセッサー・スケジューラ・コンポーネントは、任意期間のタイマー割り込み（固定量ではなく）を定めることができてしかるべきである。タイマー割り込みのコンテキストは、予約、またはその予約に応対する方針からの予約の更なる細分のいずれかとすることができる。例えば、優先順位に基づく方針は、現在の予約のコンテキスト内において固定の割当量(quantum)を定めることができる。特定の時点において、多数のタイマーの期限が存在し、プロセッサー・スケジューラ・コンポーネントは、次の期限を指定し、コンテキストを設定し、その割り込みに応対するためにしかるべきスケジューラ・コンポーネントをコールすることによって、種々のタイマー割り込みを管理することができなければならない。タイマー間隔管理部４０４は、スケジューラ時間コンテキストのスタックを維持し、このスタックにおいて次に最も近いタイム・スライスを用いて、タイマー割り込みのスケジューリングを行う。タイマー・コンテキストは、多数の情報を含む。例えば、タイマー・コンテキストは、コンテキストの種類に関する情報を含む。これは、具体的に、スケジューリング方針によって定められた予約または実行オブジェクトタイム・スライスを指す。タイマー・コンテキストは、タイマー割り込みが発生する時間間隔に関する情報を含む。タイマー・コンテキストは、予約については現予約管理部４００へのポインタ、またスケジューリング方針については状態遷移管理部４１２へのポインタを含む。タイマー・コンテキストは、予約について、現在の実行計画へのポインタを含む。

タイマー割り込みディスパッチャ４０８は、タイマー割り込みによって誘起され、そして先取の種類およびタイマー・コンテキストに応じて、スケジューリング機能のスケジューリング・エントリ・ポイントをコールする。ある実行オブジェクトに対するタイム・スライスが終了した場合、または実行オブジェクトが凍結された場合、現在の状態遷移管理部がコールされ、最終的に、予約コンテキストの中で次の実行オブジェクトをスケジューリングする。予約に対するタイム・スライスが終了した場合、次の予約および方針を選択するために、現在の実行計画コンテキストによって、予約管理部をコールする。

図４は、プロセッサー・スケジューラ・コンポーネントの典型的な制御フローを示す。１Ａにおける新たな予約の場合において示すように、予約管理部４００は新たなタイマー・コンテキスト・オブジェクトを作成する。このタイマー・コンテキスト・オブジェクトは、予約時間間隔、それ自体のコールバック・エントリ・ポイント、および現実行計画に対する参照を含む。１Ｂにおける実行オブジェクトのスケジューリングの場合、ディスパッチャ４０２は、実行オブジェクト時間間隔、および状態遷移管理部コールバック機能へのポインタを有するコンテキストを作成する。２に示すように、時間間隔管理部４０４は、要求のコンテキストをタイマー・コンテキスト・スタック４０６に押し込む。３において、時間間隔管理部４０４は、最も近いタイム・スライスを発見し、タイマー割り込みディスパッチャ４０８にコンテキストを設定し、タイマー４１０をプログラムする。４において、タイマー４１０からのタイマー割り込みが発生し、タイマー割り込みディスパッチャ４０８を呼び出す。５において、タイマー割り込みディスパッチャ４０８はそのコンテキストを調べ、予約が終了した場合には予約管理部４００コールバック機能をコールし、あるいは実行オブジェクトタイム・スライスが終了した場合には、状態遷移管理部４１２をコールする。６において、状態遷移管理部４１２をコールした後、実行オブジェクト・スケジューリング制御フローを実行し、本プロセスにおける別の繰り返しのためにディスパッチャ４０２をコールする。

これまでは、１つのデバイスのスケジューリング・インフラストラクチャの設計を説明の中心とした。しかしながら、実施形態は、デバイス資源管理部によって多数のデバイスを管理する機能を含むこともできる。これは、多数の共有プロセッサーを用いるマルチコア・デバイスや、多数のオペレーティング・システムを用いるハイパーバイザー技術(hypervisor technologies)が近年普及していることを考えると、特に有用であると言える。

一実施形態では、デバイス資源管理部は、同じ種類のデバイス群に跨るタスクを実行する役割を担う。予約のデバイスへの割り当て、負荷均衡化、および負荷軽減というような動作は、通例、デバイス資源管理部によって実行する動作である。実施形態によっては、これを遂行するにあたって、異なるデバイスに合わせて実行計画を修正する場合もあり、更に予約を実行計画間で移動させることを含む場合もある。デバイス資源管理部は、デバイス・スケジューラのコンポーネントと比較すると、呼び出される頻度は相対的に低い。したがって、相対的に費用がかかる動作を実行することができる。

実施形態によっては、デバイス資源管理部によって実行する動作は、４つのカテゴリーに分けることができ、これらのカテゴリーについてここで論ずる。最初のカテゴリーは、予約のデバイスへの割り当て、およびデバイス・スケジューラのための実行計画の作成である。予約割り当てが行われるのは、アプリケーションが新たな予約を要求したとき、または予約構成設定(configuration)が行われたときである。デバイス資源管理部は、最初に、デバイスの利用可能な容量を調べ、予約をデバイスに割り当てる。容量に加えて、ある種の作業負荷の実行を妨げる可能性もある、デバイスの電力状態、および性能というような、他にも潜在的な考慮事項がある。デバイス資源管理部は、予約緊急方針を適用する役割を担う。これは、予約のために利用可能な資源がない場合に該当する。新たな予約の予約緊急度が、既存の予約（群）と比較され、デバイス資源管理部は、緊急性が低い方の予約のアプリケーション（群）に、その予約を取り消すように通知するか、あるいは一定の時間枠内に遂行しない場合これらを終了させる。クオータ(quotas)は、特殊な方針である。クオータとは、作業負荷の資源使用を制限することを目的とするシステム強制方針である。クオータには、上限(cap)および累増(accrual)という２つの格別の種類が含まれる。上限クオータは、閾値として作用して、資源の利用を一定の限度に抑える。例えば、あるアプリケーションには、プロセッサー容量の１０％の上限がある場合がある。累増クオータは、更に長い時間期間における資源の総使用に対する制限である。例えば、ホストされているウェブ・サイトは１回の請求期間では５ＧＢよりも多いネットワーク帯域幅を使用してはいけないことを、１つの累増クオータが指定することができる。累増クオータにおいて用いられる同じ通知を、予約先取りの場合に適用することができる。資源不足および低い関連緊急度のために実行されない予約要求は、整列させて、資源が解放されたときに割り当てることができる。

予約の割り当てが決定した後、デバイス資源管理部は、デバイスに合わせて実行計画を計算し直さなければならない。実施形態によっては、デバイス・スケジューリング階層のルート実行計画(root execution plan)の再計算だけで済む場合もある。また、デバイス資源管理部は、実行計画計算サービスを、デバイス・スケジューリング階層のルート・レベル以外において一次予約を細分することが必要なスケジューラに提供することができる。

また、デバイス資源管理部は、同じ予約が多数のデバイスにおいて同じ開始時刻に行われなければならない集団スケジューリング(gang scheduling)をサポートすることもできなければならない。この特徴は、特に、同期化を必要とする場合もあるスレッド群の同時実行を必要とする場合もある同時ランタイム(concurrency run-times)には有用である。異なるデバイス上で全てのスレッドを同時に実行することにより、同期化が行われたときにこれらの全てが実行するので、調整コストは最小限に抑えられる。

また、デバイス資源管理部は、デバイス・スケジューリング階層のルート・ノードに対するデフォルト・スケジューリング方針において実行する実行オブジェクトの負荷を均衡化する役割も担う。この動作は、異なるデバイスの方針状態記憶部間で実行オブジェクトを移動させることによって、実行計画間で実行オブジェクトを移動させることを伴う。これを遂行するには、この動作に関与するデバイスの実行オブジェクト・ビューを変更する。負荷均衡化についての判断には、レイテンシの考慮というような、オペレーティング・システムにおける発見法を必要とすることもあり得る。

デバイス資源管理部は、システム資源を監視し、上限クオータ閾値を適用する。これは、デバイス資源管理部と方針ディスパッチャとの協力を必要とする動作である。デバイス資源管理部は、方針に提示された実行オブジェクト・ビューから実行オブジェクトを除外することによって、既定期間実行オブジェクトを保留にする。

本例では、デバイス資源管理部は、オペレーティング・システム・サービスを用いて、デバイスを数え上げて、デバイス・コンフィギュレーションを検査し、容量および可用性を判断する。デバイス資源管理部が動作するためにオペレーティング・システムによって用いられるサービスは、ここではシステム資源管理部と呼ばれるコンポーネントに編入される。デバイス資源管理部は、デバイス・スケジューラおよび負荷均衡化動作の開始および終了に関して特殊な動作を必要とするハードウェア障害、ホット・スワップ等のために、システム資源管理部のイベント通知システムを利用する。

図５は、管理システム５００のコンポーネントを示す。この例では、デバイス資源管理部５１０は４つの注目すべき動作を実行する。第１の動作は、実行計画の計算を含む。１に示すような、新たな予約に対して、和合性(affinity)計算部５０２は予約を実行するのに適したデバイスを選択する。予約和合性計算部５０２は、実行計画計算部５０４をコールして、そのデバイスに合わせた新たな実行計画を求め、次いでこの実行計画を、選択したデバイスの予約管理部５０６に受け渡す。予約構成の変更または既存の予約の細分の場合、和合性計算を飛び越す。

第２の動作は、ハードウェア変更に関係する。２に示すように、ソフトウェア資源管理部５０８は、デバイス資源管理部５１０に、予約および実行オブジェクト軽減手順５１２を通じて、変更が発生したことを通知する。デバイス資源管理部５１０は、次いで、ハードウェアの変更に応じて、デバイスに現在割り当てられている予約および実行オブジェクトを軽減する。例えば、デバイスが低電力モードに移行しようとしている場合、実行オブジェクトおよび予約を他のデバイスに割り当てし直すことができる。実行計画計算部５０４をコールして、影響を受けるデバイスの実行計画を計算し直す。

第３の動作は、負荷均衡化に関係する。３に示すように、実行オブジェクト負荷均衡部５１４は、関与するデバイスの実行オブジェクト・ビューを変更することによって、ルート・デバイス・スケジューリング階層においてデフォルトの方針で実行している実行オブジェクトを割り当てし直す。

第４の動作は、上限クオータ強制に関係する。４に示すように、上限クオータ・エンジン５１６は、実行オブジェクトがその閾値を超過したか否か判断する。違反が検出された場合、実行オブジェクト記憶部５１８において実行オブジェクトの状態を修正する。方針の実行オブジェクト・ビューからこの実行オブジェクトを除外することによって、所定の時間量だけこの実行オブジェクトを保留にする。上限クオータ・エンジン５１６は、方針ビューにおいてこの実行オブジェクトを確立し直す。実行オブジェクトが現在実行中である場合、上限クオータ・エンジン５１６はこの実行オブジェクトにフラグを立てて、方針時間アカウンティングコンポーネントによって、ビューの変更を行う。

これより図６に移ると、方法６００が示されている。方法６００は、システム資源のスケジューリングを行うための行為を含むことができる。この方法は、作業負荷のためにシステム資源スケジューリング方針にアクセスすることを含む（行為６０２）。この方針は、作業負荷の動作をスケジューリングするためにあり、方針が作業負荷に特定的となるように、作業負荷に基づいて指定される。例えば、図１における多くの例の中に示すように、方針１０６は作業負荷１０２に特定的となっている。一実施形態では、作業負荷はシステムの方針を用いて、当該作業負荷を実行するために用いられる作業負荷特定方針に基づいて、この作業負荷のための予約のスケジューリングを行うことができる。

更に、方法６００は、方針によって指定された作業負荷のためにシステム資源を予約する行為（行為６０４）を含む。これの一例を実行計画２００に示す。ここでは、予約２０２および２０４が、作業負荷特定方針のために実施される。

更に、方法６００は、システムのデフォルト・スケジューリング方針を用いて、他の作業負荷のために、スケジューリングされていない残りのシステム資源の少なくとも一部を保存することも含むことができる。図２は、２０６において、システム・デフォルト・スケジューリング方針を用いた予約を示す。

方法６００の実施形態によっては、この作業負荷が階層的に別の作業負荷の下になる場合がある。例えば、図１は、例の中でもとりわけ、作業負荷１０２よりも階層的に下になっている作業負荷１１０および１１２を示す。一実施形態では、作業負荷のためにシステム資源を予約すること（行為６０４）は、この作業負荷に対する方針、およびこの作業負荷よりも階層的に高い作業負荷に対する方針双方によって指定されて実行する。一例をあげると、作業負荷１１０のための予約は、方針１１４および方針１０６双方に基づいてスケジューリングすることができる。

方針は、多数の異なるパラメータに関して指定することができる。例えば、方針は、比率による資源の予約、容量による資源の予約を指定すること、または期限による資源の予約を指定することができる。

一実施形態では、方針によって指定されたように作業負荷のためにシステム資源を予約する際（行為６０４）、多数のシステム資源について実行計画を参照することが含まれ、多数のシステム資源の中からのシステム資源の各々は、同じデバイス種別を含む。例えば、システムが多数の異なるプロセッサーを含むこともあり得る。実行計画に基づいて、複数のシステム資源の中で作業負荷の負荷均衡化を目指すように、システム資源の予約を行う。代替実施形態では、システム資源の予約は、１つのデバイスから他のデバイスへの作業負荷を軽減することを目指して行われる。例えば、システムからデバイスを除外しようとする場合、または容量が少なくなる低電力状態にデバイスを移行させる場合、またはその他の理由で、このようなデバイスから利用可能な容量がある他のデバイスに、作業負荷を移行させることが望ましいこともある。別の代替実施形態では、上限クオータを強制することを目指して、システム資源の予約を実行する。

これより図７を参照すると、他の方法７００の実施形態が示されている。方法７００は、例えば、コンピューティング環境において実用化することができる。この方法は、システム資源を用いて作業負荷を実行する行為を含む。システム資源は、システム特定方針にしたがって、作業負荷のために既に予約されている。これらの方針は、作業負荷の動作をスケジューリングするためである。この方法は、方針を選択することを含み、この方針はある作業負荷に特定的であり（行為７０２）、この方針を用いて作業負荷をシステム資源に配分し、方針にしたがって作業負荷を実行し（行為７０４）、作業負荷を実行した場合システムの使用に関する情報を含むフィードバックを受け取り（行為７０６）、このフィードバックに基づいて、更に作業負荷をシステム資源に配分するために、方針決定を行う（行為７０８）ことを含む。これの一例を図３に示す。図３は、方針３０４−１から方針３０４−Ｎまでをどのようにしてディスパッチャ３１０と共に用いて、システム資源３１２によって作業負荷を実行させるかを示す。

方法７００において、方針決定を行う（行為７０８）のは、実行計画に基づくことができる。実行計画は、作業負荷のためのシステム資源の予約を定める。例えば、システム資源３１２上において作業負荷を実行した後、実行計画２００のような実行計画を参照して、予約２０２および２０４の内の１つのような予約と比較して、作業負荷をシステム資源３１２上で実行した時間量に基づいて、方針変更を行うべきか否か判断することができる。

本明細書において記載した実施形態の一部は、以前に実現されたスケジューリング・システムに対して１つ又は複数の利点を提供することができる。例えば、実施形態の中には、特殊化に配慮したものがある。即ち、システム資源のスケジューリングは、作業負荷の要件を満たすように、カスタム化が可能であるとよい。１つのスケジューリング方針が全ての作業負荷の要件を満たすことができない場合もある。本明細書における実施形態の中には、デフォルトの方針を用いるか、またはアプリケーションに合わせて特定的に設計した新たなスケジューリング方針を定める選択肢を、作業負荷が有する場合もある。

実施形態の中には、拡張性に配慮したものもある。本明細書に記載されている実施形態を用いると、スケジューリング方針は、作業負荷要件を取り込むように拡張可能にすることもできる。この属性は、所望の特殊化の実現に配慮する。デフォルトのシステムが供給する方針に加えて、資源管理インフラストラクチャは、単に既存の方針から選択するだけでなく、作業負荷がこれらの方針を指定できるように、挿入可能な(pluggable)方針アーキテクチャを提供することができる。

実施形態の中には、一貫性に配慮したものもある。同じ資源管理インフラストラクチャを異なる資源に用いることができる。スケジューリング・アルゴリズムは、通例、デバイス種別の要件を満たすように特殊化されている。プロセッサー、ネットワーク、およびディスク・スケジューラは、異なるアルゴリズムを用いることもでき、オペレーティング・システムの異なる要素に実装されることもできる。しかしながら、実施形態の中には、全てのスケジューラが、コンポーネントを特徴化するために同じモデルを用い、更に同じ統計およびクオータ・インフラストラクチャを用いることができる場合もある。

実施形態の中には、周期性に配慮したものもある。作業負荷の部分集合の応答性は、システムの負荷およびスケジューリング方針とは独立しているとよい。オペレーティング・システムは、レイテンシに敏感なアプリケーションに対して、システム資源の既定部分を保証できるとよい。

実施形態の中には、適応性に配慮したものもある。スケジューリング方針は、システムの動的挙動を取り込むように修正することができる。挿入可能な方針スケジューリングモデルによって、上位のシステム・コンポーネントおよびアプリケーションが、それらのシステム性能を調和させるように方針を調節することが可能になる。

また、実施形態は、コンピューター実行可能命令またはデーター構造を搬送するまたは格納したコンピューター読み取り可能媒体を含むこともできる。このようなコンピューター読み取り可能媒体は、汎用コンピューターまたは特殊目的コンピューターによってアクセスすることができる入手可能な媒体であればいずれでも可能である。一例として、そして限定ではなく、このようなコンピューター読み取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたはその他の光ディスク・ストレージ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望のプログラム・コード手段をコンピューター実行可能命令またはデーター構造の形態で搬送または格納するために用いることができしかも汎用コンピューターまたは特殊目的コンピューターがアクセス可能なその他のいずれの媒体も含むことができる。ネットワークまたはその他の通信接続（有線、ワイヤレス、あるいは有線またはワイヤレスの組み合わせのいずれか）を通じて情報をコンピュータに転送または提供する場合、コンピューターはこの接続をコンピューター読み取り可能媒体と見なすことは適正である。つまり、このような接続はいずれも、コンピューター読み取り可能媒体と呼ぶことは適正である。以上の組み合わせも、コンピューター読み取り可能媒体の範囲に含まれてしかるべきである。

コンピューター実行可能命令は、例えば、命令およびデーターを備えており、汎用コンピューター、特殊目的コンピューター、または特殊目的処理装置に、一定の機能または機能の一群を実行させる。本主題は、構造的特徴および／または方法論的行為に特定した文言で記載したが、添付する特許請求の範囲において定義する発明は、本明細書において記載した具体的な特徴や行為のいずれにも必ずしも限定されないことは言うまでもない。むしろ、これら具体的な特徴および行為は、特許請求の範囲を実現する形態例として開示したに過ぎない。

図８および以下の論述は、本発明を実現可能とするのに適したコンピューティング環境の端的な総合的な説明を行うことを意図している。必須ではないが、本発明の説明は、ネットワーク環境においてコンピューターが実行するプログラム・モジュールのような、コンピューター実行可能命令という一般的なコンテキストで行う。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データー構造等を含み、特定のタスクを実行するか、または特定の抽象的データー・タイプを実現する。コンピューター実行可能命令、付随するデーター構造、およびプログラム・モジュールは、本明細書に開示した方法のステップを実行するプログラム・コード手段の例を表す。このような実行可能命令または付随するデーター構造の特定的なシーケンスは、このようなステップにおいて記載した機能を実施するための対応する行為の例を表す。

本発明は、多くの種類のコンピューター・システム構成を有するネットワーク・コンピューティング環境においても実施できることは当業者には認められよう。コンピューター・システム構成には、パーソナル・コンピューター、ハンドヘルド・デバイス、マルチプロセッサー・システム、マイクロプロセッサー主体またはプログラマブル消費者用デバイス、ネットワークＰＣ、ミニコンピューター、メインフレーム・コンピューター等が含まれる。また、本発明は分散型システムにおいても実施することができ、この場合、ローカルおよびリモート・処理装置が、（有線接続データー・リンク、ワイヤレス・データー・リンク、または有線接続およびワイヤレス・データー・リンクの組み合わせにいずれかによって）通信ネットワークを通じてリンクされており、双方がタスクを実行する。分散型・環境では、プログラム・モジュールは、ローカルおよびリモート双方のメモリー記憶デバイスに配置することもできる。

図８を参照すると、本発明を実施するシステム例は、コンピューター８２０の形態とした汎用コンピューターを含む。コンピューター８２０は、図示のように多数のプロセッサーを含んでもよい演算装置８２１、システム・メモリー８２２、およびシステム・バス８２３を含むことができる。システム・バス８２３は、システム・メモリー８２２を含む種々のシステム構成要素を演算装置８２１に結合する。システム・バス８２３は、メモリー・バスまたはメモリー・コントローラ、周辺バス、および種々のバス構造のいずれかを用いるローカル・バスを含む数種類のバス構造のいずれでもよい。システム・メモリーは、リード・オンリ・メモリー（ＲＯＭ）８２４およびランダム・アクセス・メモリー（ＲＡＭ）８２５を含む。基本入／出力システム８２６（ＢＩＯＳ）は、起動中のように、コンピューター８２０内のエレメント間におけるデーター転送を補助する基本的なルーチンを含み、ＲＯＭ８２４内に格納することができる。

また、コンピューター８２０は、磁気ハード・ディスク８３９からの読み取りおよびこれへの書き込みを行なう磁気ハード・ディスク・ドライブ８２７、リムーバブル磁気ディスク８２９からの読み取りおよびこれへの書き込みを行なう磁気ディスク・ドライブ８２８、ならびにＣＤ ＲＯＭまたはその他の光媒体のようなリムーバブル光ディスク８３１からの読み取りおよびこれへの書き込みを行なう光ディスク・ドライブ８３０を含むこともできる。磁気ハード・ディスク・ドライブ８２７、磁気ディスク・ドライブ８２８、および光ディスク・ドライブ８３０は、それぞれ、ハード・ディスク・ドライブ・インターフェース８３２、磁気ディスク・ドライブ・インターフェース８３３、および光ドライブ・インターフェース８３４によって、システム・バス８２３に接続されている。これらのドライブおよびそれに付随するコンピューター読み取り可能媒体は、コンピューター８２０のために、コンピューター実行可能命令、データー構造、プログラム・モジュール、およびその他のデーターの不揮発性ストレージを備えている。本明細書に記載する環境例では、磁気ハード・ディスク８３９、リムーバブル磁気ディスク８２９、およびリムーバブル光ディスク８３１を採用したが、データーを格納するための他の種類のコンピューター読み取り可能媒体も用いることができ、磁気カセット、フラッシュ・メモリー・カード、ディジタル・バーサタイル・ディスク、ベルヌーイ・カートリッジ、ＲＡＭ、ＲＯＭ等が含まれる。

プログラム・コード手段は、１つ又は複数のプログラム・モジュールを備えており、磁気ハード・ディスク８３９、リムーバブル磁気ディスク８２９、リムーバブル光ディスク８３１、ＲＯＭ８２４、またはＲＡＭ８２５上に格納することができ、オペレーティング・システム８３５、１つ又は複数のアプリケーション・プログラム８３６、その他のプログラム・モジュール８３７、およびプログラム・データー８３８を含む。ユーザーは、コマンドおよび情報をコンピューター８２０に、キーボード８４０、ポインティング・デバイス８４２、またはマイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナ等のようなその他の入力デバイス（図示せず）によって入力することができる。これらおよびその他の入力デバイスは、多くの場合、システム・バスに結合されているシリアル・ポート・インターフェース８４６を介して、演算装置８２１に接続されている。あるいは、入力デバイスは、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）のようなその他のインターフェースによって接続することも可能である。モニター８４７またはその他の形式の表示装置も、ビデオ・アダプター８４８のようなインターフェースを介して、システム・バス８２３に接続されている。モニターに加えて、パーソナル・コンピューターは、スピーカーおよびプリンター等のような、その他の周辺出力装置（図示せず）も含むことができる。

コンピューター８２０は、リモート・コンピューター８４９ａおよび８４９ｂのような１つ又は複数のリモート・コンピューターへの論理接続を用いて、ネットワーク環境において動作することも可能である。リモート・コンピューター８４９ａおよび８４９ｂは、各々、別のパーソナル・コンピューター、サーバー、ルーター、ネットワークＰＣ、ピア・デバイス、またはその他の共通ネットワーク・ノードとすることができ、通例、コンピューター８２０に関して先に説明したエレメントの多くまたは全てを含むが、図８には、メモリー記憶デバイス８５０ａおよび８５０ｂ、ならびにそれらに付随するアプリケーション・プログラム３６ａおよび３６ｂのみを示す。図８に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）８５１およびワイド・エリア・ネットワーク（ＷＡＮ）８５２を含む。ここでは、これらを一例として示すのであって、限定ではない。このようなネットワーク環境は、事務所、企業規模のコンピューター・ネットワーク、イントラネットおよびインターネットにおいては、珍しくはない。

ＬＡＮネットワーク環境で用いる場合、例えば、コンピューター８２０は、ネットワーク・インターフェースまたはアダプター８５３を介してローカル・ネットワーク８５１に接続する。ＷＡＮネットワーク環境で用いる場合、コンピューター８２０は、モデム８５４、ワイヤレス・リンク、またはインターネットのようなワイド・エリア・ネットワーク８５２上で通信を確立するその他の手段を含むことができる。モデム８５４は、内部または外部でも可能であり、シリアル・ポート・インターフェース８４６を介してシステム・バス８２３に接続することができる。ネットワーク環境では、コンピューター８２０に関して図示したプログラム・モジュール、またはその一部をリモート・メモリー記憶装置に格納することができる。尚、図示のネットワーク接続は一例であり、ワイド・エリア・ネットワーク８５２を通じて通信を確立する他の手段も使用可能であることは認められよう。

実施形態は、以上で論じた資源に合わせて作業負荷を処理する機能を含むことができる。この処理は、本明細書において既に説明したような、作業負荷特定方針を用いて遂行することができる。

本発明は、その主旨または本質的な特徴から逸脱することなく、他の具体的な形態においても具体化することができる。記載した実施形態は、あらゆる観点において、例示に過ぎず、限定としては見なさないものとする。したがって、本発明の範囲は、前述の説明ではなく、添付した特許請求の範囲によって示されることとする。特許請求の範囲の均等の意味および範囲に該当する全ての変更は、その範囲に含まれるものとする。

Claims (20)

1. コンピューティング環境における、システム資源のスケジューリング方法であって、
   システム資源スケジューリング方針（１０６）を割り当てる行為であって、前記方針が、作業負荷（１０２）内における動作のスケジューリングを行い、前記方針が前記作業負荷に対して特定的となるように、作業負荷に基づいて前記方針を指定する行為（行為６０２）と、
   前記方針によって指定されたように、前記作業負荷のためにシステム資源を予約する行為（行為６０４）と、
   を備えている、方法。
2. 請求項１記載の方法であって、更に、スケジューリングされずに残っているシステム資源の少なくとも一部を、システムのデフォルト・スケジューリング方針を用いる別の作業負荷のために確保する行為を備えている、方法。
3. 請求項１記載の方法において、前記作業負荷が他の作業負荷よりも階層的に下にあり、前記作業負荷のためのシステム資源を予約する行為は、前記作業負荷に対する方針と、前記作業負荷よりも階層的に上にある前記別の作業負荷に対する方針との双方によって指定されるように実行する、方法。
4. 請求項１記載の方法において、前記方針は、比率によって資源の予約を指定すること、容量によって資源の予約を指定すること、または期限によって資源の予約を指定することの内少なくとも１つである、方法。
5. 請求項１記載の方法において、前記システム資源は、プロセッサー、ネットワーク資源、メモリー資源、またはディスク資源の内少なくとも１つである、方法。
6. 請求項１記載の方法において、前記方針によって指定されるように前記作業負荷のためにシステム資源を予約する行為は、
   複数のシステム資源についての実行計画を参照する行為であって、前記複数のシステム資源の中からのシステム資源の各々が、同じデバイス種別から成る、行為と、
   前記実行計画に基づいて、前記複数のシステム資源間で前記作業負荷の負荷均衡化を目指すようにシステム資源を予約する行為と、
   を備えている、方法。
7. 請求項１記載の方法において、前記方針によって指定されるように前記作業負荷のためにシステム資源を予約する行為は、
   複数のシステム資源についての実行計画を参照する行為であって、前記複数のシステム資源の中からのシステム資源の各々が、同じデバイス種別から成る、行為と、
   前記実行計画に基づいて、１つのデバイスから別のデバイスへの作業負荷を軽減することを目指すようにシステム資源を予約する行為と、
   を備えている、方法。
8. 請求項１記載の方法において、前記方針によって指定されるように前記作業負荷のためにシステム資源を予約する行為は、
   複数のシステム資源についての実行計画を参照する行為であって、前記複数のシステム資源の中からのシステム資源の各々が、同じデバイス種別から成る、行為と、
   前記実行計画に基づいて、上限クオータを強制することを目指すようにシステム資源を予約する行為と、
   を備えている、方法。
9. コンピューティング環境において、システム資源を用いて作業負荷を実行する方法であって、前記システム資源は、システム特定方針にしたがって、作業負荷のために予約されており、前記予約は、作業負荷によって、作業負荷特定方針を適用するために用いられ、
   （ａ）方針を選択する行為であって、該方針が作業負荷内において動作のスケジューリングを行うためである、行為（行為７０２）と、
   （ｂ）前記作業負荷をシステム資源に配分するために前記方針を用いる行為（行為７０４）と、
   （ｃ）前記作業負荷を実行したときに、前記システムの使用に関する情報を含むフィードバックを受ける行為（行為７０６）と、
   （ｄ）更に作業負荷を前記システム資源に配分するために、前記フィードバックに基づいて方針決定を行う行為（行為７０８）と、
   を備えている、方法。
10. 請求項９記載の方法であって、更に、複数の作業負荷に対して指定された異なる方針にしたがって、前記複数の作業負荷を実行するために、行為（ｂ）から（ｄ）を繰り返す行為を備えている、方法。
11. 請求項９記載の方法において、前記方針決定を行う行為は、実行計画に基づき、該実行計画は作業負荷のためのシステム資源の予約を定める、方法。
12. 請求項１１記載の方法であって、更に、１つ又は複数の容量に基づく予約を指示するために前記実行計画を定式化する行為を備えている、方法。
13. 請求項１１記載の方法であって、更に、１つ又は複数の比率に基づく予約を指示するために前記実行計画を定式化する行為を備えている、方法。
14. 請求項９記載の方法において、前記システム資源は、プロセッサー、ネットワーク資源、メモリー資源、またはディスク資源の内の１つ又は複数である、方法。
15. 請求項９記載の方法において、前記作業負荷をシステム資源に配分するために前記方針を用いる行為は、
    前記方針とは別個に実装されたディスパッチャにおいて、該ディスパッチャがいずれの特定の方針とも独立して動作するように、前記システム資源によって実行されるべき作業負荷を示す前記方針からの情報を受け取る行為と、
    前記ディスパッチャが、前記作業負荷を選択し、前記システム資源に前記作業負荷を実行させる行為と、
    を備えている、方法。
16. 請求項９記載の方法において、更に作業負荷を前記システム資源に配分するために、前記フィードバックに基づいて方針決定を行う行為は、前記フィードバックに基づいて、新たな方針または同じ方針の内少なくとも１つを選択することを含む、方法。
17. コンピューティング環境において、システム資源上で作業負荷を実行する方法であって、
    １つ又は複数のシステム資源スケジューリング方針にアクセスする行為であって、前記方針は、１つ又は複数の作業負荷内において動作のスケジューリングを行うためにあり、所与の方針が所与の作業負荷に特定的となるように、前記方針を作業負荷に基づいて指定する、行為と、
    前記方針によって指定されるように、前記システム資源の予約を指示する実行計画を定式化する行為と、
    前記実行計画に基づいて、前記システム資源に作業負荷を配分する行為と、
    を備えている、方法。
18. 請求項１７記載の方法において、実行計画を定式化する行為は、同じ実行計画において、比率に基づく予約と容量に基づく予約とを含ませる行為を含む、方法。
19. 請求項１７記載の方法において、実行計画を定式化する行為は、階層的に関係付けられた方針に基づいて予約を含ませる行為を含む、方法。
20. 請求項１７記載の方法において、前記実行計画に基づいて前記システム資源に作業負荷を配分する行為は、いずれの特定の方針とも独立して動作するように、前記方針とは別個に実装したディスパッチャが、前記システム資源によって実行されるべき作業負荷の指示を受け取る行為と、前記ディスパッチャが、前記作業負荷を選択し、前記システム資源に前記作業負荷を実行させる行為と、
    を備えている、方法。

Images