JP2005534116A - 複数の消費者をもつコンピュータシステムで資源を動的に割当てて管理する方法 - Google Patents

Abstract

オペレーティングシステム（ＯＳ）で管理され、複数の消費者アカウントを有するコンピュータシステムにおいて、資源を動的に割当てて管理する方法である。必要に応じて、個々の消費者のアカウントについて、スワップファイル中に、仮想メモリアドレス空間の各部分が割当てられる。メモリアドレス空間は、各アカウント毎に制限される。ＣＰＵ使用量が、各アカウントから要求されたタスク間で分配され、オリジナルコード中の一つ以上の特定の手続きを決めて、仮想メモリアドレス空間の割当ておよび／または制限、および／または、プロセス数および／または分配されたＣＰＵ使用量の制限に応じて、実行する特定の手続きを変更することにより、ＯＳのオリジナルコードのセグメントが変更される。

Description

発明の分野
本発明は、コンピュータシステムを管理する分野に関するものである。特に、本発明は、所与のコンピュータシステムの消費者、システムおよびＷＥＢサービスにより利用される資源を制限する方法に関するものである。

発明の背景
ＷＥＢサイトを個別にホスティングすることは、比較的コストのかかることである。その理由は、ホスティングには、サイトへのインターネットアクセスのために充分な回線容量を割当て、サイトを常時利用可能とするような（ソフトウェアとハードウェア両面の）資源を割当て、ファイアーウォールなどのセキュリティ面を管理する必要があるためである。

ＷＥＢサイトのホスティング業者（ＷＨＰ；Ｗｅｂ Ｈｏｓｔｉｎｇ Ｐｒｏｖｉｄｅｒ）は、コンピュータシステムの消費者（ｃｏｎｓｕｍｅｒ）であり、様々なサービスモデルを活用して、様々なサービスの種類に応じて、異なる種類の顧客に対応できるようにしている。通常、小規模および中規模のビジネス向けＷＥＢサイトは、専用サーバのような余裕のある資源を事前に確保しておくことはなく、共有サーバモデルで解決している。しかし、ＷＨＰの要求は変化し、それらのサイトはより複雑な処理を行うようになってきているため、これらの処理は、より多くの資源を消費するものとなってきている。ＷＨＰがより多くの資源を消費するような場合には、通常は、より多くの資源を借用するか、性能を落としてでも資源の容量を変えないで使用せざるを得ない。サイトのサービスへの要求は、時間毎に一定ではないため、顧客は、より多くの資源を借用することよりも、資源の容量を変えずに使用し続けることを選ぶ。これは、資源に対する比較的高い要求は、比較的短い時間に限って発生するという想定に基づくものである。

通常、各専用サーバは、ＯＳ（オペレーティングシステム）のインスタンスを実行している。しかし、各専用サーバでのＯＳの実行には、ＯＳの各インスタンスに対して必要とされる比較的多くの資源量を必要とする。

以下では、「コンピュータシステム」という用語は、複数のサービスを実行する複数の仮想専用サーバをホストする一つのサーバを指すものとする。ここでは、仮想専用サーバの各々は、コンピュータ資源の大部分を利用している。

このようなコンピュータシステムでは、仮想専用サーバは、実際には、コンピュータシステムのインターフェースのエミュレーションとなっており、このエミュレーションでは、リモートクライアントが、そのシステムのユーティリティとプログラムとにアクセスするものとなっている。以下では、この仮想専用サーバを、ＶＤＳ（Ｖｉｒｔｕａｌ Ｄｅｄｉｃａｔｅｄ Ｓｅｒｖｅｒ）と呼ぶ。複数のＶＤＳは、単一のホスティングコンピュータシステム上で、同時に実行することができる。

「アカウント」という用語は、特定のユーザに割当てられたマシン資源のある部分を指すものである。アカウントは、その割当てられた資源を、他のアカウントと共有することができるが、割当てられた量よりも多くの資源を同時に利用することはできない。ユーザ、ドメイン、ＶＤＳ、サービス、特定のプロセスまたはプロセスグループに対して、またはマシンの資源の他の適当なユーザに対しては、一つの「アカウント」を割当てることが可能である。

アカウントの資源消費を制限するための既存の方法の一つとしては、計算機資源を静的に分配して利用する方法がある。運営コンピュータの資源は、仮想コンピュータの間で、静的な方法で、分配される。この方法では、例えば、実際のコンピュータを、１０個の同一の仮想コンピュータに分割し、たとえ一つの仮想コンピュータだけが運用されたとしても、そのシステム資源の１０％づつを、各仮想コンピュータに割当てることになる。動的な資源割当てでは、複数のＶＤＳが同時に動作した場合でも、（あらかじめ定められたパラメータに応じて）各ＶＤＳに適切な資源割当てを行い、（全てのＶＤＳが同時に動作したとしても）各仮想コンピュータがより高い性能を果たすようになる。従って、動的な資源割当ては、ユーザの観点からは、より高い性能をもたらすものとなる。動的な資源割当ては、異なるサービス、異なるユーザなど、コンピュータ資源の任意の消費者が利用できるものとなっている。

コンピュータシステムの資源は、予算、空間的な制約など、いくつかの因子によって制限される。コンピュータシステムの資源は、とりわけ、中央演算処理装置（ＣＰＵ）の使用量、メモリアドレス空間のサイズ、データの格納容量などを含んでいる。複数の消費者により利用されるコンピュータシステムは、消費者がＷＨＰであるか、通常の消費者であるかにかかわらず、その消費者の各々に対して、コンピュータシステムの各消費者と対応する資源の所有者との間で取り決められた契約または合意に従い、少なくとも、予め定められた割合の資源を提供する必要がある。ＷＨＰは、全ての消費者が同時に最大の資源を要求する確率は低いという仮定に基づき、実際に利用可能な資源よりも多くの資源を提供することが可能である。従って、異なる消費者に対して、予め定められた割合の資源を利用可能とするためには、予め定められた資源に応じて、特定の消費者が利用可能となる資源を制限する必要がある。複数の消費者をもつコンピュータシステムにおいて、各消費者に対する資源を制限するための他の理由としては、以下のものがある。

− もし、資源が予め予約可能な種類ではない（すなわち、非予約可能な）場合には、コンピュータシステムの適切なプロセスが、資源への要求があった場合には、これらの資源を解放する必要がある。例えば、コンピュータシステムのメモリ、または適切な格納ディスクは、通常は、非予約可能な資源である。多くの数の資源を割当てることにより、以前の資源が解放される前に、プロセスがその資源を共有できないようにすることができる。残念ながら、一旦割当てられた資源を解除することは比較的複雑なものとなる。

− もし、資源が予め予約可能な種類である（すなわち、予約可能な）場合には、各タイムスライスでは、これらの資源は、資源要求中のプロセスの間で、分配される。例えば、通常、ＣＰＵは、予約可能な資源である。予約可能な資源を扱う際には、資源割当てが各タイムスロット毎に最初から行われるため、利用されていない資源を扱う状況としては、２つの可能性がある。一つは、当初の割当量よりも多くのプロセスを確保することにより、ユーザは、それ相当の性能を扱えるようになる。しかし、追加された消費者が、コンピュータシステムに接続し、資源割当て分を利用し始めると、このシステムに接続されていた以前からの消費者は、それらの全体としての性能が悪化することになる。もう一つの状況は、最初から資源を制限することにより、このような状況を回避できるものの、エンドユーザの観点からは好ましくない。

− 資源が予約可能であり、コンピュータシステムの所有者が、その消費者の各々に確保された資源量に応じて、異なる課金を施したいと希望する場合には、結果的に、所有者は、各消費者に割当てられた資源のみに、消費者の利用を限定しようとする。

「Ｅｎｓｉｍ Ｃｏｒｐｏｒａｔｉｏｎ」などのように、コンピュータ内に、「静的な仮想的コンピュータ」を設ける企業がいくつか存在する。「静的な仮想的コンピュータ」の各々に、ＣＰＵ、メモリの所定の量が割当てられる。しかし、他のユーザがそれらに割当てられた資源を使っておらず、利用可能な資源があるからといって、コンピュータの所有者は、仮想的コンピュータに対し、それに割当てられた資源以上のものを利用させることはできない。

さらに、静的な仮想的コンピュータでは、例えば、ＷＨＰがコンピュータ資源を２つの異なる再販業者（ｒｅｓｅｌｌｅｒ）に割当て（すなわち、各再販業者に対して、資源の５０％ずつを割当て）、一方の再販業者が、それに割当てられた部分を２つのユーザに供給し、各ユーザに対して（再販業者自身に割当てられた部分の）７５％を保証しようとした場合には、このような階層的な割当ては不可能なものとなる。その理由は、各ユーザに対して割当てられた資源の２５％は、保証された資源よりも少なく、他方の再販業者の他のユーザへの影響を考えると、３７．５％では多すぎて、これは消費者が利用できない資源量となる。

従来の技術では、コンピュータシステムの資源を割当てる通常の方法は、予め定めら得た資源量を、各消費者に割当てるというものである。しかしこの方法には、いくつかの欠点がある。例えば、比較的多くの消費者をもつコンピュータシステムでは、新たに消費者をシステムに追加する際には、他の全ての消費者に対して、資源の再割当てが必要になる。例えば、コンピュータシステムの所有者が、その消費者すべてに、平等にシステム資源を分配しようとする場合、例えば、１０の消費者がいる場合、所有者は、システム資源の１０％を各消費者に割当てる（つまり、システム資源の１００％を全ての消費者に割当てる）。しかし、もし所有者が、システムに消費者を追加しようとする場合には、新たに追加された消費者にも資源が利用可能となるように、既存の１０の消費者の各々に割当てた資源を更新する必要がある。もし、多くの（例えば、１００、１０００、またはそれ以上の数の）クライアントがいる場合には、このタスクは、膨大な時間を要し、もしくは、システムのステータス変化をもたらす毎に、全ての消費者に対する全ての資源の割当て中に、ユーザエラーを生じさせやすいものとなる。一つ以上の消費者に対して、他の消費者よりも多くの資源を割当てる場合には、資源を再配分するタスクは、複雑度を増すことになる。もし、コンピュータシステムの所有者が、「再販業者」（すなわち、他の消費者に資源を配分できる資格をもっている消費者）を抱えている場合には、より複雑度が増すことになる。通常は、アカウントが消費する量と、それに対する割当量との比較が行われる。しかし、ソフトウェアは、資源を利用する各処理のシステム資源を再計算する。例えば、比較のためにチェックされる資源がメモリである場合、メモリ割当ての前にのみ比較が行われるが、この方法では、割当てが事前に行われるため、好適な割当てとは言えない。

上記のすべての方法は、複数の消費者を有するコンピュータシステムの資源を効率的に割当て管理する問題に対して、満足のゆく解決策を提供するものとは言えない。

本発明の目的は、サービスであるかユーザであるかにかかわらず、各消費者の資源消費を個々に制限する方法を提供することにある。
本発明の目的は、消費者間で資源を割当てるためのより良い方法を提供することにある。
本発明の目的は、所望の階層をもたせて、資源を割当てる方法を提供することにある。
本発明の他の目的は、動的にかつ要求に応じて、割当て資源を計算する方法とシステムを提供することにある。
さらに本発明の目的は、現在の資源割当て状況を消費者が監視できるようにする方法とシステムを提供することにある。

本発明の他の目的と利点については、以下の説明によって明確なものとなる。

発明の概要
本発明は、オペレーティングシステム（ＯＳ）により管理され、複数の消費者のアカウントを有するコンピュータシステム中の資源を動的に割当てて管理するための方法に関するものである。仮想メモリアドレス空間の各部分が、必要に応じて、消費者に対する各アカウント毎にスワップファイル中に割当てられる。メモリアドレス空間は、各アカウント毎に制限される。ＣＰＵ使用量は、各アカウントから要求されたタスク間で分配され、一つ以上の特定の手続きをＯＳのオリジナルコード中で特定し、仮想メモリアドレス空間の割当ておよび／または制限、および／または、プロセスおよび／または分配されたＣＰＵ利用量の数の制限に応じて特定の手続きが動作するように、この特定の手続きを変更することにより、ＯＳのオリジナルコードのセグメントが変更される。

好ましくは、メモリアドレス空間および／または分配されたＣＰＵ使用量の割当ておよび／または制限の変更に応じて、特定の手続きは、動的にその動作を変更する。要求された処理の決定は、シンボルテーブルに格納されている要求された処理の名前を取得すること、または、要求された処理のバイトシーケンスを識別することにより可能となる。

特定の手続きを変更するためには、割当てられたメモリアドレス空間を取得し、割当てられたメモリアドレス空間中で実行コードを生成する。オリジナルコードからコードセグメントをコピーし、コピーされたコードの開始にあるコマンドラインを保存し、さらに、オリジナルコード中の次のコマンドが開始するまで、コマンドをスキップする。オリジナルコードの開始にあるコマンドラインは、生成されたアプリケーションの開始までスキップし、生成されたアプリケーションの未使用バイトに無演算バイトを付加することにより置換される。空白のバイトが、この無演算（ＮＯＰ）データとなる。

資源の消費するための呼び出しが特定の消費のアカウントによるものでない時には常にオリジナルコードを呼び出すことにより、且つその関連パラメータによってアカウントを識別することにより、メモリアドレス空間の制限が実装される。アカウントにより資源の消費が要求される毎に、割当てられたメモリアドレス空間に応じて、アカウントが、そのクオータ（ｑｕｏｔａ）、またはそれ以上のレベルのクオータを上回ることはないことが確認される。アカウントに関連した演算の結果は、その演算が成功する毎にチェックされ、アカウントおよび／またはアカウント以上のレベルの消費データが更新される。特定されるパラメータは、ユーザＩＤ、グループＩＤまたはプログラム名である。

プロセスの数を制限する際には、アカウントにより資源の消費が要求される毎に、割当てられたプロセス数に応じて、アカウントが、そのクオータ、またはそれ以上のレベルのクオータを上回ることはないことが確認される。アカウントに関連した演算の結果は、その演算が成功する度にチェックされ、アカウントおよび／またはアカウント以上のレベルの消費データが更新される。識別されるパラメータは、ユーザＩＤ、グループＩＤまたはプログラム名である。

アカウントの資源割当方針に従って、アカウントにより要求されないＣＰＵ資源は、他の要求中のアカウント資源に動的に割当てられ、アカウント毎に最適な共有割当となるように、利用可能なＣＰＵ資源が、すべてのタスク間に分配される。タスク間のＣＰＵ使用量の分配は、実行される候補となるタスクのカウンタ計算を修正することにより得られ、タスクに対応づけられたアカウントのクオータにより各タスクが制限される。

カウンタ計算の変更は、カウンタの計算を行う関数に割り込みをかけることにより行われる。そして、ユーザアカウントに対して保証された値に基づき、タスク毎の所望のカウンタ値を計算し、同一のアカウントに所属する複数のタスクがある場合には、常に、カウンタ値が計算される際に、クオータに従ってカウンタの正しい値を保持する。タスクのカウンタ値は、これらの内部割当が使用量に応じて現在行われている間、アカウントに応じて合計される。各プロセスの動作に関する情報は保持され、最終時間の間にアカウントが受け取ったＣＰＵ資源の量が、ティック（ｔｉｃｋ）ごとに計算され、計算された量は、アカウント上のレベルに加えられる。アカウントまたはアカウント上のレベルが、その割当て以上のものを受ける際には、常に、次のＣＰＵ割当が行われるまで、タスクのカウンタはゼロに減らされる。次に実行すべきタスクが決定される際は、常に、次に実行すべきタスクの選択が有効であることが確認される。

本発明の、上記および他の特徴と利点は、以下の図面を参照して、その好適な実施例の以下の例証と制限を加えない詳細な説明によって、よりよく理解することができる。

詳細な実施例
コンピュータシステムにおいて、消費者に割当てられた資源を上回ることがないようにするためには、各消費者に対してこのシステムから利用可能となっているメモリ、プロセス数およびＣＰＵの使用を制限することが必要である。

以下で説明する実施例は、次の用語を明確に定義することにより、より明確なものとなる。
○ プログラム カーネルがメモリ上に読み出し、実行することが可能な、実行可能ファイル。
○ プロセス プログラムの実行インスタンス。ＵＮＩＸ（登録商標）の各プロセスは、プロセスＩＤ（ＰＩＤ）と呼ばれる一意の数値の識別子を持つことが保証されている。
○ スレッド プロセス中の単一の逐次制御フロー。従って、一つのプロセスは、複数の同時実行されるスレッドを有することができる。Ｌｉｎｕｘでは、各スレッドは、独自のＰＩＤを有している。

ＬｉｎｕｘＯＳでは、プロセスを生成する関数は、ｄｏ＿ｆｏｒｋである。プロセス終了を扱う関数は、ｅｘｉｔの種類のものである。単純な実装方法としては、「ｒｏｏｔ」アカウント（ＵＩＤ＝０）が所有するプロセス以外のアカウント毎のプロセスの初期化と終了に応じて、システムが増加、減少させるユーザ毎のカウンタ値を保持する方法が考えられる。アカウントが、そのクオータを上回るような新しいプロセスを初期化しようとした場合には、システムは、「ｆｏｒｋ」（または、「ｖｆｏｒｋ」、「ｔｈｒｅａｄ＿ｃｒｅａｔｅ」）関数の実行に失敗する。この場合、階層的な意味（セマンティック）は、メモリ管理のものと同一である。

以下では、コンピュータシステムにおける、特定のアカウントのメモリ消費を制限するための構成について説明する。まず始めに、明確化のために、Ｕｎｉｘ、Ｌｉｎｕｘ等のオペレーティングシステムにおけるメモリ割当の方法を説明する。

各実行アプリケーションは、メモリエリアの一部分を取得し、その部分からアプリケーションは実行または動作する。メモリエリアは、以下、メモリアドレス空間と称し、特定の実行アプリケーションの所定のデータを含んでいる。メモリアドレス空間は、各アプリケーションに対して固有の仮想メモリの一部分である。各アプリケーションは、独自の仮想メモリの領域を持っているが、この領域は、通常は、他のアプリケーションのアドレス空間やまたは、アプリケーションが実行される物理的なコンピュータの容量とは無関係なものとなっている。

通常、メモリは、「ページ」に分割され、各ページは、メモリ管理アプリケーションによって取り扱われる基本ユニットとなっている。メモリ管理は、コンピュータの物理メモリ、または、ハードディスク（の「スワップ」といわれる領域）に、「ページ」を格納する。「スワップ」は、格納メモリとして動作し、通常、すべてのプログラムに対して、十分な物理メモリ空間がない場合に、アプリケーションのデータ部をハードディスク上に一時的に退避する。スワップは、複数のファイルの組、または、特定のディスクパーティション、あるいは、それら両者からなっている。以下の理由から、情報は、ハードディスク上（の「スワップ」内または実ファイル中）に格納される。

− メモリ管理は、現状で必要とされる他のページについては、相対的に関連性の少ない「ページ」を、（応答の速い）物理メモリ上の空き格納空間である「スワップ」に転送する。メモリ管理は、アプリケーションによって変更される可能性のあるページのみを転送し、一方、他のページについては、それらの初期アドレス（これについては、後に説明する）から復帰させることが可能である。

− ページは、プログラムの書き込み可能な領域の一部分であるが、プログラムは、それを変更することはできない。このような場合、ページは、それが次に必要となった際に、ディスクからロードされる。

− ページは、アプリケーション「コード」の部分（すなわち、アプリケーションが実行するコマンドラインであるが、アプリケーションのデータ部分ではない）である。アプリケーションコードは、アプリケーション自身によっては変更することはできないため、もし、メモリ上からページが削除されれば、メモリ管理は、それを、アプリケーションファイルから再び取得することができる。

− ページは、アプリケーションの「読み取り専用」データの一部分である。「読み取り専用」データは、アプリケーション自身によっては変更することはできないため、もし、メモリ上からページが削除されれば、メモリ管理は、それを、アプリケーションファイルから再び取得することができる。

− ページは、Ｕｎｉｘの「ｍｍａｐ」が行なわれたファイルのような、オペレーティングシステムのファイルの一部分である。「ｍｍａｐ」関数は、「ｍｍａｐ」に渡された変数で特定されたファイル（または、他のオブジェクト）からのオフセットから開始する「長さ（ｌｅｎｇｔｈ）」バイト、たとえば、変更可能なファイル記述子（ｆｄ）を、メモリ内の「ｓｔａｒｔ」パラメータなどの「ｍｍａｐ」関数に渡されるパラメータのアドレスにマッピングする。

− マッピングの後、プログラムは、プログラムが割当てたバッファ中の情報をすぐには読み取ることを必要とせず、そのメモリ内の任意の部分にあるかのように、ファイルをアクセスすることが可能となる。この場合、ページをハードディスクから読み出すことが可能となるので、ファイルはアプリケーションのメモリの一部分にマッピングされ、スワップファイル中のページを保持する必要はない。

本発明の一実施例によれば、消費者のアカウントに割当てられたメモリを上回ることを避けるために、このアカウントのスワップファイル上で、割当てられたメモリアドレス空間が制限される。一方、アプリケーションにより使用される物理メモリは制限されないため、これにより、オペレーティングシステムが動作し、どのページをスワップさせるべきかを決定する方法と干渉することを防ぐ。ＬｉｎｕｘやＵｎｉｘなどのオペレーティングシステムでは、プログラムが利用するメモリの量は、以下の一つ以上の方法により影響を受ける。

− プロセスが生成された際の初期メモリ割当

− 利用可能な全てのメモリを用いた一つ以上の要求による、メモリの拡張（例えば、Ｕｎｉｘの関数「ｍａｌｌｏｃ」は、より多くのメモリをプロセスに割当てることをＯＳに要求する。ＯＳは、プログラムが要求するよりも多くのものを割当て、後に、プログラムがより多くのページを要求するような場合を扱えるようにしている。これは、ＯＳのメモリ管理の一部である。関数「ｍａｌｌｏｃ」は、Ｃ言語とＣ＋＋言語の標準関数であり、Ｗｉｎｄｏｗｓ（登録商標）のようなＯＳでも利用可能である）

− ファイルを特定のメモリアドレス空間にマッピングする、（例えば、関数「ｍｍａｐ」を用いた）ファイルへのマッピング。

− 共有メモリ領域の生成（例えば、関数「ｓｈｍｇｅｔ」を用いる。関数「ｓｈｍｇｅｔ」は、あるプログラムについて、ある量のメモリをＯＳに要求でき、そのプログラムに対して識別子を付与する。他のプログラムも同様に、この付与された識別子を用いて、このメモリを使うことができる。関数「ｓｈｍｇｅｔ」は、プロセス間で情報を共有するための構成である。

以下で説明するように、上記の全ての方法と他の可能な方法と、オペレーティングシステムのカーネル中の比較的少ない数の関数にマッピングされる。

例えば、カーネルバージョン２．２のＬｉｎｕｘでは、全ての操作は、カーネル中の関数「ｄｏ＿ｍｍａｐ」にマッピングされる。関数「ｄｏ＿ｍｍａｐ」は、以下のパラメータを得る。

− アクセスモード・パラメータ−読込み／書込み（ＲＷ）か、読込のみ（ＲＯ）かを指定する。もしＲＯであれば、メモリは、読込のためだけにアクセスすることができ、この場合、情報はメモリの元の格納位置から取り出されるため、スワップ空間は割当てられない。この場合、本発明の方法は、なにもしない。

− マッピング・パラメータ−ＲＷの場合、プライベート使用か共有かを指定する。共有の場合、共有される記憶装置の生成者のみが、当該メモリに割当てられる。プライベートという用語は、特定のプログラムだけがアクセスできるメモリ、例えば、特定のプログラムが実行開始したときに割当てられたメモリ、または「ｍａｌｌｏｃ」されたメモリを指すものである。共有という用語は、例えば、共有オブジェクトのローディング中にプロセス間で共有されるものを指すものである。（共有オブジェクトの例としては、ダイナミック・リンク・ライブラリ（ＤＬＬ）がある。ＤＬＬは、小さいプログラムの集まりであり、個々のプログラムは、Ｗｉｎｄｏｗｓ２０００環境のコンピュータで、実行中のより大きなプログラムから必要となった場合に呼び出される。

関数「ｄｏ＿ｍｍａｐ」は、Ｌｉｎｕｘでの一例であり、このような動作は、他の関数にも同様に適用される。
従って、スワップ空間の割当てを含むような状況のみで、アプリケーションは、ＲＷのプライベートメモリを要求する。

「ｄｏ＿ｍｍａｐ」などの関数が所定のメモリアドレスを返すが、ページが使われるまでは、物理メモリ（およびスワップの）メモリにページが割当てられないことは重要な点である。割当てはページ単位で行われるので、プログラムは、１００ページを割当てて、それらのページの中の（例えば、メモリの開始と終了にある）２ページにのみアクセスが可能である。その場合、２ページのみがメモリ中に割当てられ、従って、これらがスワップに移動できることになる。

本発明の一実施例によれば、ページを割当てる際には、全てのページを用いて、メモリ使用量の計算を行うものと仮定している。本発明の他の実施例によれば、ページが初めて使用される毎に、実際のメモリ消費をチェックする。しかし、この方法では、有効なアドレスにアクセスしている間には、プログラムの動作を止めることになり、ＯＳの動きに従わないものとなってしまう。プログラムが正常に動作できるようにするために、本発明の実施例により制御されていることを意識させないように、本発明は、ＯＳの動きに従うものとする。

ＯＳとの干渉
従来例では、オペレーティングシステムの動作を変更するためのいくつかの既知の方法がある。

− オペレーティングシステムのソースコードを変更する方法。ソースコードは常に利用可能であるとは限らないため、この方法には問題がある。もしソースコードが利用可能な場合には、ソースコードを常に保守する必要があるため、ソースコードを変更する解決方法は、配布されうるコードのすべてのバージョンを更新する必要がある。

− コード中の「ｈｏｏｋ」を使う方法。通常、ＯＳは、利用可能な「ｈｏｏｋ」を備えている。これらのｈｏｏｋは、ユーザが定義した特定のモジュールをＯＳが起動する場所であり、そこではＯＳは特定の処理を実行する。しかし、「ｈｏｏｋ」は、ＯＳの一部として実装する必要があるため、ＯＳの製作者がその処理を特定した場所でのみ利用可能となる。

本発明の一実施例では、コードの変更を行わない。それに代えて、以下に説明するように、カーネルのコード中で、必要となる手続を決め、これを適切なコードに変更する。

必要な手続きの特定
必要な手続きはカーネルコード中に存在し、カーネル中でその場所を特定は、例えば、適切なシンボルテーブル中に格納された必要な手続きの名前を用いて行う。もちろん、必要な手続きは、他の方法で決めることも可能であり、例えば、関数が「Ｅｘｐｏｒｔされない」場合には、その関数等の特定のバイトシーケンスを決めるための構成を利用することも可能である。

必要な処理の変更
図２は、本発明の位置実施例による、必要な手続きの変更の概略を示した図である。必要な処理の変更（すなわち、元のコードの変更）は、以下の手順で行われる。

− 以下で述べるように、例えば、Ｌｉｎｕｘのカーネル２．２の「ｉｎｓｍｏｄ」プログラムを用いて、全ての関数をロードする。

− 新コード２１により用いられるメモリアドレス空間の必要な領域を割当てる。

− 割当てられたこの領域中にコードを生成する。このコードは、コマンド列（すなわち新コード２１）であり、以下に述べるロジックを実行する。
− コピーされたコード２２の始めのコマンドライン保持し、Ｏｒｉｇｉｎａｌコード２０の次のコマンドの開始にジャンプする。

− Ｏｒｉｇｉｎａｌコード２０の始めのコマンドラインを、新コード２１の開始へのジャンプに置き換え、無演算（ＮＯＰ）を表すバイトを、適切なコマンドの終りまで付加する。例えば、関数が、各々４バイトからなる３つのコマンドから始り、「ジャンプ」が６バイトから構成されている場合、「ジャンプ」によって意図しないコードを実行することがないように、２つのＮＯＰが付加される。

新コード２１では、コピーコード２２中のコードを呼び出すことにより、オリジナルコード２０を呼び出すことができる。オリジナルコード２０は、実際の処理を実行する。この処理は、プログラムの情報や、カーネル中のパラメータや、割当てを行うために必要な他の処理を変更することによる、メモリ割当て、ＣＰＵ割当て、他の適切な論理割当てなど、所定のシステムモジュールのサービスである。本発明の一実施例によれば、オリジナルコード２０は、新コード２１とは独立して実行される。オリジナルコード２０の実行は、新コード２１からコピーコード２２を呼び出すことによって得られる。コピーコード２２は、オリジナルコード２０を呼び出し、実際の論理割当て（例えば、メモリ割当ておよび／またはＣＰＵ割当て）を行う。コピーコード２２は、オリジナルコード２０を呼び出すことだけができ、それは、オリジナルコード２０のコピーは含まない。これは、比較的大きな容量を持つオリジナルコード２０を重複して格納することを防ぐために必要なことである。オリジナルコード２０を呼び出した後、コピーコード２２は、新コード２１に戻る。その時点で、新コード２１は、実行された割当て処理の結果とその関連処理とが、良好なものであることを検証する。新コード２１が検証を終えた後、割当て処理の結果が、オリジナルコード２０中のコードを呼び出したプログラムに戻される。

本発明の一実施例によれば、メモリアドレス空間上で、コンピュータシステムによって消費される資源の制限を実装する方法は、以下に示すものとなる。
− 資源を利用するための呼び出しが、特定の消費者のアカウントによらないものである場合には、オリジナルコード２０に呼び出しがなされる。アカウントの識別情報は、ユーザＩＤ，グループＩＤ、プログラム名など、いくつかのパラメータを用いて得られる。

− 資源を消費するための呼び出しがアカウントによるものである場合には、メモリを割当てることにより、アカウントが、そのクオータ、またはそれ以上のレベルのクオータを上回らないことを保証する。アカウントが、そのクオータを上回る場合には、実行コマンドは、その操作を行なわなくてもよい。

− 実行結果をチェックし、実行結果が良好となる毎に、特定のアカウント（またはそれ以上のレベルのアカウント）に関して必要となる情報を更新する。
本発明の他の実施例によれば、オリジナルコード２０は、新コードで置き換えられる。好ましくは、これに限定されることはないが、新コードは、オリジナルコードのいくつかを含んでいる。この実装は、新コードにメモリを割当てるステップと、オリジナルコードの開始を、新コードに対して「ｊｕｍｐ」処理で置き換えるステップとを含んでいる。新コードは、オリジナルコードを完全に無視するために、「Ｒｅｔｕｒｎ」処理で終了することが好ましい。

どの実装方法を用いるかの判断は、実装する者に委ねられており、この判断は、オリジナルおよび新コードの容量、両者の差、個人的な好みなど、様々なパラメータに従って行われる。

本発明の一実施例によれば、メモリ消費を正しく制限するためには、途中でなんらかのコンテキストスイッチを行うことなく、上述したすべての段階を経ることが必要である。コンテキストスイッチという用語は、ＯＳが一つのプロセス実行を停止し、他のプロセスの実行を継続している段階を指すものである。その後、停止状態にあるプロセスに戻り、そのプロセス実行を継続する。その他に、同一のアカウントの２つのプロセスが、両方のアカウントがともに正規である必要性は問わないが、同時に演算を行い、割当てが正規のものであるという結果に達するようにしてもよい。例えば、Ｌｉｎｕｘでは、カーネル中のコードは、コンテキストスイッチを行うことなく、単一スレッドの環境で実行される。

新プロセスが生成された際には、そのプロセスを生成したプロセスと同一のページを継承し、それ自身の用途のために、ページの変更を開始する。本発明の一実施例によれば、このような場合は、追加のシステムコール（例えば、ＵＮＩＸでの「ｆｏｒｋ」、「ｅｘｅｃ」など）に割り込みをかけ、コマンドに渡される指示値（すなわち、フラグ）に従って、用いられたメモリを増加または減少させることにより対処する。

例えば、Ｌｉｎｕｘは、読取り専用として検索されたページを変更し、読み取り／書き込み可能としてアクセスできるようにしている。この処理は、適切なシステムコールを用いて実行される。このようにして、アプリケーションは、実際に要求したものより多くのページをスワップ領域で使うことができる。

実際のスワップ割当ては、特定のページが変更された際に、実行される。従って、プログラムは、１００ページを変更のために利用することを要求できるが、その中の２ページのみを変更することが可能である。結果として、２ページのみが、スワップアドレス空間に保持され、他のページは、それらの元の場所から検索される。通常、プログラムは、正規のコマンドを実行している間は、メモリアドレス空間がなくなることはないため、プログラムは、要求した全てのページを用いることになると仮定できる。すでに上述したように、スワップ割当ての実行は、メモリの割当てと似たものとなる。

前のレベルのノードは、資源を過剰に割当てることが可能であるが、全ての後のレベルのノードの実際の資源使用は、前のレベルのクオータを上回ることはできない。

本発明の一実施例によれば、資源の利用の比較的迅速な計算が、カーネルのメモリアドレス空間中でのアカウントの階層構造を表すツリー形式を用いることにより行われる。

各アカウントに対して、その現状の割当てとそのクオータとが、カーネルメモリアドレス空間に保存されている。従って、割当て要求を処理する際には、現状の割当量と要求されたメモリとの和と、アカウントの割当量とを比較し、もし、その和が、その資源を上回る場合には、そのアカウントより上のレベルについて、同様の比較を行う。

本発明の一実施例によれば、以下に説明するアカウントの階層構造により、各アカウントを独立に扱うことなく、比較的多数のアカウントの管理が可能となる。

図１は、本発明の一実施例による、複数の消費者を有するコンピュータシステムにおける、資源の階層的な割当ての概略を示したものである。ブロック１０は、コンピュータシステムの全資源（すなわち、１００％）を表す。ブロック１１から１４（すなわち、コンピュータシステムのノード）は、コンピュータシステムの各消費者の（パーセント表示での）割当て資源量を表す。メモリ、ＣＰＵなど、所定の資源は、階層的なツリー形式に分割され、各レベル（すなわち、レベル０、レベル１およびレベル２）が、その下位レベルのものに対して、１００％のクオータを提供するものとなっている。例えば、レベル１のブロック１２で表された消費者に割当てられた資源は、コンピュータシステムの全資源の２０％とする。しかし、ブロック１２に割当てられた資源である２０％は、レベル２のブロック１６と１５に対して割当てられる１００％の資源に相当する。本発明の他の実施例によれば、資源を一定値として割当て、パーセント（比率）で割当てないことも可能である。この一実施例から他の実施例への変換は、当業者にとっては、自明なことである。計算の簡単化のため、計算アルゴリズムで用いる値は、絶対値とし、比較演算のコストを削減することが好ましい。

各レベルでは、各ブロック（すなわち、ノード）は、システム資源における一定のクオータを有するものとなっているか、特定のグループの一部を含むものとなっているかのいずれかである。各グループのクオータは、他のグループに対して相対的に定義される。例えば、コンピュータシステムが、３つの消費者グループ（すなわち、ブロック１１から１３）を有している場合には、グループ１２の各メンバーは、グループ１１のメンバーの２倍の量の資源を受け、また、グループ１３の各メンバーは、２番目のグループの２倍の量の資源を受けるものとなる。

本発明の一実施例によれば、再販業者と非再販業者という、２種類のグループが存在し、各種類は、異なる利用形態を指すものとなっている。再販業者のグループでは、資源の１００％をいくつかの再販業者の間で分割することができ、各再販業者は、それ自身に割当てられた資源を他の再販業者（またはユーザ）に分割し共有可能となるが、これらの共有割当てについては、特定のレベルの資源を、その上位レベルで消費される資源に影響を与えずに、余分に再販することが可能となっている。非再販業者のグループは、特定のレベルでのみ用いられる。３つのグループがあり、各グループには、ｓｉｍｐｌｅ，ｍｅｄｉｕｍ，ｌａｒｇｅの異なる重み付けがなされている場合を考える。ここでは、各リソースにおける特定の量を保証することは好ましくない。むしろ、ここでは、３つのグループ間の関係を定義することが好ましい。この場合、アカウントを各グループに付与し、全アカウントとそれらに従う各種のアカウントとに従って、アカウント毎の資源の計算を行う。例えば、値がそれぞれ１、２、および４である場合には、

となる。
本式により、パラメータＸの値が求まり、これから各グループに割当てる資源が得られる。アカウントが追加される毎に、パラメータＸを再計算し、それに応じて各種のアカウントを更新する。この方法は、この計算の実行とアカウント毎の更新とをユーザに対して要求することに比べて、容易なものである。

本図は、再販業者の場合について説明したものである。グループの特性は、１００％で、いくつかのアカウントにより示されており、各アカウントは、その種類を示するものを有している。

データセンタ１６は、３０％のシステム資源を一つのクライアントに割当てて、グループ１１から１３には、各々一つのメンバーが含まれている（すなわち、レベル１には、全部で４アカウントの消費者がいる）と仮定する。グループ１１のメンバーがＸ％の資源を受ける場合には、全資源は、

（数２）
３０＋Ｘ＋２Ｘ＋４Ｘ＝１００％
となる。
従って、グループ１１のメンバーは、１０％を受け取り、グループ１２のメンバーは、２０％を受け取り、グループ１３のメンバーは、４０％を受け取る。

本発明の本実施例によれば、追加のアカウント（すなわち消費者）を追加し、上述したように、グループ間の重み付けなどの予め定められたパラメータに従って、計算された資源の量は、自動的に更新することができる。さらに、これにより、いくつかの階層レベルが可能となる。例えば、グループ１２のメンバーが、それの割当てられた資源を、２つの下位アカウント１４、１５と共有したい場合には、２つの下位アカウント１４、１５の各メンバーは、全システム資源の１０％を受けることができる。各下位アカウント１４、１５は、これらの上位レベルのグループ１２から、割当てられた資源の２０％のうち半分（５０％）を受けることができる。

さらに、（各レベルの）資源の所有者は、管理できる全てのアカウントに割当てられた共有資源を全て使い切るような場合はないと仮定した場合、過剰販売（ｏｖｅｒｓｅｌｌ）、すなわち、その割当て資源の１００％を越える量の販売が可能となる。しかし、コンピュータシステムは、使う資源が該当のレベルで１００％を上回るような状況を回避することができる。例えば、２つのアカウントがあり、各々５０％の資源割当てとし、一方のアカウントは２つの下位アカウントを有し、各々はその上位アカウントの６０％が割当てられているとした場合、下位アカウントの資源割当ては３０％を上回ることができる。しかし、全てのアカウントがアクティブである場合には、２つのアカウントは共に５０％を上回ることはできない。

もちろん、パーセント表示を、人間のオペレータは、簡単に管理することができる。アルゴリズム中の値は、絶対値として保存される。
例えば、資源の所有者は、過剰販売を許すかどうか、さらに、その過剰量をどれほどにするかを決定することができる。しかし、本例によれば、過剰販売がある場合には、所有者は、保証された資源を保持できるとは限らないため、正規のルールを守ることは所有者の責任となる。

以下では、コンピュータシステムにおける、特定のアカウントのＣＰＵ消費を制限するための機構について説明する。ＣＰＵ消費の制限は、上述したように、カーネルのコード中の必要な手続きを特定し、それを好適なコードに変更することにより行われる。

本発明の好適な実施例では、ＣＰＵ使用量は、各アカウントにより要求されたタスク間で分割される。タスクの分割は、ＣＰＵにより実行する必要のあるプロセスのスケジューリングに基づき行われる。スケジューリングは、ＯＳにより制御される。説明を明確にするため、ＬｉｎｕｘＯＳを例にとり、プロセスのスケジューリングを説明する。しかし、このプロセスのスケジューリングの原理は、他のＯＳ（オペレーティングシステム）に対しても同様なものである。

Ｌｉｎｕｘでは、実行する必要のある各プロセスは、次の値を持っている。それは、スケジューリングのポリシー、スケジュールグループ中での優先度、そして良好な値である。現状のＬｉｎｕｘでは、以下の３つのスケジューリングの原則がサポートされている。それは、先入れ先出しスケジューリング（ＳＣＨＥＤ＿ＦＩＦＯ）、ラウンドロビンスケジューリング（ＳＣＨＥＤ＿ＲＲ）、そしてデフォルトのＬｉｎｕｘ時分割スケジューリング（ＳＣＨＥＤ＿ＯＴＨＥＲ）。これらのスケジューリングの意味を、以下説明する。

ＬｉｎｕｘＯＳのスケジューリングについての下記の説明は、以下で説明するＣＰＵ消費を制限する構成をよりよく理解する上で、基礎的な知識となる。

スケジューラは、どの実行可能なプロセスが次にＣＰＵで実行するのかを決定するカーネル部分である。Ｌｉｎｕｘスケジューラは、３つの異なるスケジューリングのポリシーを提供しており、１つは、通常プロセスに関するものであり、残り２つは、リアルタイムアプリケーションに関するものである。静的な優先度の値、ｓｃｈｅｄ＿ｐｒｉｏｒｉｔｙが、各プロセスに付与され、システムコールを介してのみこの値が変更される。概念的には、各プロセスに対し、カーネルは、リアルタイムプロセスに対して静的な優先度の値に等しく、時分割プロセス（通常プロセス）に対する実際のＣＰＵ使用量と、静的な優先度の値とから求められた、動的な優先度の値を維持する。次に実行するプロセスを決定するために、Ｌｉｎｕｘスケジューラは、最も大きい動的な優先度の値をもつ空でないリストを探し、このリストの先頭にプロセスを登録する。各プロセスに対し、スケジューリングの原則は、同一の静的な優先度の値をもつプロセスのリスト中のどの場所に当該プロセスを挿入し、そのプロセスをリスト中でどのように移動させるかを決定する。

Ｌｉｎｕｘでは、ＳＣＨＥＤ＿ＯＴＨＥＲは、多くのプロセスで利用されるデフォルトの汎用の時分割スケジューラのポリシーであり、ＳＣＨＥＤ＿ＦＩＦＯとＳＣＨＥＤ＿ＲＲとは、実行可能なプロセスを選択する上で正確な制御を必要とする特別なリアルタイムアプリケーションで用いられる。ＳＣＨＥＤ＿ＯＴＨＥＲによりスケジューリングされるプロセスには、静的な優先度の値０が付与され、ＳＣＨＥＤ＿ＦＩＦＯまたはＳＣＨＥＤ＿ＲＲによりスケジューリングされるプロセスには、１から９９までの範囲で静的な優先度の値が付与される。

特権を有するプロセスのみが、０よりも大きな静的な優先度の値を持つことになり、これにより、ＳＣＨＥＤ＿ＦＩＦＯまたはＳＣＨＥＤ＿ＲＲの下でスケジューリングされる。システムコールであるｓｃｈｅｄ＿ｇｅｔ＿ｐｒｉｏｒｉｔｙ＿ｍｉｎおよびｓｃｈｅｄ＿ｇｅｔ＿ｐｒｉｏｒｉｔｙ＿ｍａｘを用いて、システムに合致するＰｏｒｔａｂｌｅ ＯＳ Ｉｎｔｅｒｆａｃｅ ｔｈａｔ ｂａｓｅｄ ｏｎ Ｕｎｉｘ（ＰＯＳＩＸ）において有効な優先度の値の範囲を見つけることができる。

全てのスケジューリングは、プリエンプティブなものである。もし、より高い静的な優先度をもつプロセスが、実行可能な状態である場合には、現状のプロセスはプリエンプトされ待機リスト（ｗａｉｔ ｌｉｓｔ）内へ戻される。スケジューリングのポリシーは、同一の静的な優先度の値をもつ実行可能なプロセスのリスト内での順位を決定するだけである。

ＳＣＨＥＤ＿ＦＩＦＯは、０より大きな静的な優先度をもつものに適用される。これは、ＳＣＨＥＤ＿ＦＩＦＯプロセスが実行可能である時に、常に、現在実行中の通常のＳＣＨＥＤ＿ＯＴＨＥＲプロセスを直ちにプリエンプトすることを意味している。ＳＣＨＥＤ＿ＦＩＦＯはタイムスライスを伴わない単純なスケージュリングアルゴリズムである。ＳＣＨＥＤ＿ＦＩＦＯのポリシーの下でスケジューリングされたプロセスについては、以下のルールが適用される。より高い優先度をもつ他のプロセスによってプリエンプトされたＳＣＨＥＤ＿ＦＩＦＯプロセスは、その優先度のリストの先頭に置かれ、それより高い優先度をもつ全てのプロセスが再び停止すると、直ちに処理を再開する。ＳＣＨＥＤ＿ＦＩＦＯプロセスが実行可能となると、そのプロセスは、その優先度のリストの最後に置かれる。ｓｃｈｅｄ＿ｓｅｔｓｃｈｅｄｕｌｅｒまたはｓｃｈｅｄ＿ｓｅｔｐａｒａｍの呼び出しにより、ＰＩＤで識別されるＳＣＨＥＤ＿ＦＩＦＯプロセスが実行可能である場合には、そのプロセスはリストの最後に置かれる。ｓｃｈｅｄ＿ｙｉｅｌｄを呼び出すプロセスは、リストの最後に置かれる。同一の優先度をもつ実行可能なプロセスの待機リストの中では、ＳＣＨＥＤ＿ＦＩＦＯのポリシー下でスケジューリングされたプロセスは、他のイベントによって移動されることはない。ＳＣＨＥＤ＿ＦＩＦＯプロセスは、Ｉ／Ｏ要求によりその実行が停止するまで、または、より高い優先度を持つプロセスによりプリエンプトされるまで、あるいは、そのプロセスがｓｃｈｅｄ＿ｙｉｅｌｄを呼び出すまで、実行を続ける。

ＳＣＨＥＤ＿ＲＲは、ＳＣＨＥＤ＿ＦＩＦＯの単純な拡張である。ＳＣＨＥＤ＿ＦＩＦＯについて上述した事項は、各プロセスが最大タイムカンタムだけ実行することが許されるという点を除いて、ＳＣＨＥＤ＿ＲＲに対しても適用される。もし、ＳＣＨＥＤ＿ＲＲプロセスが、タイムカンタムに等しいかそれより長い時間だけ実行されていた場合には、そのプロセスは、その優先度のリストの最後に置かれる。より高い優先度をもつプロセスによりプリエンプトされ、それに続いて、実行プロセスとして実行を再開するＳＣＨＥＤ＿ＲＲプロセスは、そのラウンドロビン・タイムカンタムの未経過も部分を満了することになる。タイムカンタムの長さは、ｓｃｈｅｄ＿ｒｒ＿ｇｅｔ＿ｉｎｔｅｒｖａｌにより求められる。

ＳＣＨＥＤ＿ＯＴＨＥＲは、静的な優先度０でのみ用いられる。ＳＣＨＥＤ＿ＯＴＨＥＲは、特別な静的優先度の実時間構成を必要としない全てのプロセスに対応したＬｉｎｕｘ標準の時分割スケジューラである。実行すべきプロセスは、静的な優先度０のリストの中でのみ決定された動的な優先度に基づき、このリストの中から選ばれる。動的な優先度は、良好（ｎｉｃｅ）なレベル（良好と設定されたもの、または優先度を設定するためのシステムコールにより設定されたもの）に基づくものであり、プロセスが実行可能となっている各タイムカンタムに対して上がるが、スケジューラによる実行を拒むものではない。これにより、全てのＳＣＨＥＤ＿ＯＴＨＥＲプロセス中の良好な進行が保証される。

通常は、ユーザプロセスは、スケジュールのデフォルトタイプに基づくものである。従って、本発明においては、特定のアカウントのＣＰＵ消費の制限は、スケジュールのデフォルトタイプに基づくタスクに対してのみ行われる。

スケジュールのデフォルトタイプに属するタスクについては、Ｌｉｎｕｘのスケジューラは、以下のように動作する。

− （以下で説明するように）必要が生じた場合、スケジューラは、実行する候補となっている全てのタスクを調べ上げ、各々にカウンタを割当てる。このカウンタは、当該タスクが実行される際のティック（ｔｉｃｋ）の数を保持するものである。その数の計算は、タスクに与えられるティックは、その良好な値（タスクが、最新のタイムカンタムで実行されたかどうかの影響を含む値）に関連して、処理が行われる。

− 各ティック（通常は、１／１００秒）毎に、スケジューラは、どのタスクが現状のものであるかを判定し、そのタスクのカウンタを１だけ減らす。もしカウンタが０に到達した場合には、このタスクは現状のカンタムについてそのクオータを終了し、他のタスクが実行される。どのタスクを選択するかはタスクのカウンタ値に基づいて行われ、最大のカウンタ値をもつタスクが選ばれる。ここで重要なのは、実行状態にあるタスクだけが選択され、これは、他の状態にあるプロセスは、何かを待っていて、たとえ、それを得たとしてもＣＰＵを使うことができないということである。

− もし、正のカウンタ値をもつ実行可能なタスクがない場合には、新しいタイムカンタムが開始され、すべてのタスクについてカウンタ値が再計算される。

− タスクが、これ以上ＣＰＵを使うことができないような段階に到達する場合もある。例えば、タスクが、ディスク上のファイルにアクセスしようとする場合である。この場合、タスクはＣＰＵの使用を断念し、スケジューラに対して、実行される次のタスクを選択するように要求する。多くの場合、プログラムは、待ち状態となるような多くの個所を含んでおり、実際には、その状態にある時間が長いものとなる。

本発明の一実施例によれば、カウンタを変更して、アカウントのクオータにより、各タスクを制限するようになっている。カウンタの計算を変更するには、以下のように、ＯＳの動作とやりとりする必要がある。

− クオータに応じたカウンタの正しい値を計算した際に、その値を保持する。

− 次に実行するタスクを決定する毎に、次ぎに実行するタスクの選択が有効であることを確認する。このオプションは基本的なものであり、いくつかの場合で、タスクには、（同一のアカウントのほかのタスクが、そのクオータよりも多くを消費している場合には）より少ないＣＰＵ資源が与えられるか、（もしアカウントの他のタスクがクオータを要求しない場合には）より多いＣＰＵ資源が与えられる。

本発明の一実施例によれば、カウンタ計算の変更は以下のように行われる。

− 「カウンタ」を計算する関数を停止する。

− ユーザアカウントに保証された値に基づき、各タスクについて所望のカウンタ値を計算する。もし同一のアカウントに複数のタスクが属する場合には、アカウントに応じてこれらのカウンタ値の合計を計算し、それらのタスクがこれまでの使用状況に応じてこれらの内部割当てを行う。各プロセスについては、その動作に関する情報、特に、そのプロセスが主にＣＰＵタスクであるか、ＩＯタスクであるかに関する情報を保持する。主にＩＯタスクから構成されているアプリケーションは、いずれにせよティック全体にわたり、ＣＰＵを利用することはないため、ＣＰＵタスクに比べて高い優先度が与えられる。（一方、アプリケーションの処理に使われる時間は、それに確保された時間よりも短いものとなっている）。本発明の他の実施例によれば、ＣＰＵ資源は、全てのタスク間で均等に分配される。このようなカウンタ値の計算は、ＬｉｎｕｘＯＳがタスクに対してアルゴリズムを適用する際に、本発明に従って計算される値を使用できる。

− 各ティック毎に、アカウントが最後に受けたＣＰＵ資源の量を計算し（以下を参照のこと）、そのアカウントより上位のレベルに、その計算した値を加える。もしそのアカウント（または、その上位のレベル）が、その割当よりも多くの値を受け取る場合には、タスクのカウンタをゼロに減らし、次のＣＰＵ割当てがあるまで、ＣＰＵを使用しないようにする。この操作は、ＣＰＵを利用する他のタスクがある場合だけで行われ、それ以外の場合には、ＣＰＵを利用できなくするようにして、タスクへのＣＰＵ割当てのループ（待ち）のみが得られるようになっている。

本発明の一実施例による、ＣＰＵ使用量の計算方法について、以下説明する。計算方法を拡張するため、計算関数の簡単さとは別に、以下のガイドラインが与えられる。

１．何らかの一定の時間での状態のみを考慮し、長い間アイドル状態であったアカウントが、多くのＣＰＵ時間を得ることがないように（すなわち、アイドル状態の時間を補償するように）する。例えば、アカウントが５０％のＣＰＵ利用率で、そのアカウントが1時間のアイドル状態を続けていた場合、（もし、他のアカウントもＣＰＵ資源を必要としているならば）そのアカウントが全ＣＰＵ資源を得るのは不公平なものとなる。そのアカウントは、その時間の５０％のみを得るべきであり、この５０％はその時間に渡って一定となるべきである。

２．最近の１秒間で１ティックのＣＰＵ資源を持つアカウントが、最近の５秒間に１ティックのＣＰＵ資源を持つアカウントとは異なって扱うようにするため、時間経過の構成が必要となる。

本発明の一実施例によれば、どのタスクを実行するかに関する情報が得られ、次に、コンピュータのティックが起こった時にのみ、その計算が行われる。経過したティックの間には、１つ以上のタスクがＣＰＵを利用したかもしれないが、通常は、そういう場合にはならない。例えば、既に実行を開始したタスクが、ディスクからの情報を要求し、その実行中にディスクを停止させると、タスク間の切換えが行われ、ティックの残りの間にＣＰＵが他のタスクに割当てられる。他の実施例としては、タスク間の切り替える関数を停止させた後で、サブティック（ｓｕｂ−ｔｉｃｋ）のレベルで計算を行うことも可能である。しかし、このような状況は比較的まれなことであり、本計算では、このような状況は考慮しないことにする。

ＣＰＵ消費量は、アカウントがティックの間にＣＰＵ資源を用いたかどうかに応じて、各ティックごとに０または１の値を持つ一組の算術関数を用いて計算が行われる。全ての計算は、ティック以外の任意の時間に行われる。ティック（ｔｉｃｋ）という用語は、説明を明確にするためだけに使用している。説明のため、同一レベル（すなわち、階層がない場合）には、Ｎ個のアカウントが存在するものと仮定する。複数のレベルに対する計算は、上記と同様に行われる。特定のアカウントのＣＰＵ使用量を求める関数を、図３に示すが、ここでは、アカウントは、時間ｔ軸の全体にわたってＣＰＵを使うのではなく、限られた時間の間隔でのみ（すなわち、参照符号３１および３２で示すように、関数値が１の値をもつ時のみ）、ＣＰＵ資源を利用する。

本発明の好適な実施例によれば、時間経過のファクタを計算するために用いられる関数は、非線形であり、特定のアカウント「ｉ」がＣＰＵ時間の割当てを受けてからの経過時間に応じて、ＣＰＵ時間の重み付けを行う。従って、この時間経過の関数は、次式で与えられる。

特定のアカウント「ｉ」の利用度の関数は、時間経過のファクタを考慮し、結果として、時間ｔにおける特定のアカウントのＣＰＵ使用量を与えるものとなる。利用度の関数は、次式で与えられる。

以下のパラメータ「Ｒｉ」は、特定のアカウント「ｉ」に対して消費された資源を定義するものである。「Ｒｉ」は、反復値であり、ティック毎に更新される。このパラメータは、時間経過の影響を受けるため、現在アクティブになっているアカウント「ｊ」については、

で与えられ、特定のアカウント「ｉ」（ｉ¹ｊ）については、次式で与えられる。

以上のように、このパラメータは、以下の特徴を持っている。
１．合計は常に１である。
２．時間経過の効果がある。

しかし、上記の計算は、ティックごとに、全てのアカウントについての情報を更新する必要がある。（数百、数千のアカウントがある場合には、この計算量は膨大なものとなる。）従って、本発明の一実施例では、本計算により実行される操作数を減らすため、ティック毎に、（１＋Δ）を掛け合わせた新しい変数「Ｃ」を、次式のように定義する。

ここで、「Ｃ」は、全ての数について、全ての値について共通部分である。従って、Ｒｉを計算する代りに、Ｒｉ×Ｃの値を計算する。結果として、「Ｃ」とＲｊを変更することだけが必要となり、すべてのＲｉを求める必要はない。

この新しい値は、カーネルのメモリ中にで維持される。このように、変更されたアカウント「ｉ」の「Ｒ」だけを、次式に従って、更新すればよい。

アカウント「ｋ」（ここで、「ｋ」は「ｉ」であってもよい）の実際の資源消費量は、次式で与えられる。

この計算は、（「Ｃ」の各値は、常に増加し、その比は極めて小さい値であるため）オーバーフローとアンダーフローとの影響を考慮したものになっている。
計算を行う際には、常に、アカウントとその上位のレベルの消費率がチェックされる。もし、これらの値のいずれかが、保証された値を上回る場合には、スケジューラによる次ぎの資源割当てが行われるまで、タスクはより多くの資源を得られない。

以上、説明したように、スケジューリングアルゴリズムは、タスクの良好値に基づいて、タスクが得ることができるティックの量を決定する。しかし、良好値は、特定のレベル数（例えば、４０レベル）を持つものであるため、最大のＣＰＵ使用量と最小のＣＰＵ使用量をもつタスク間の比の最大値は、４０にしかならない。ここで、３つのアカウントがあるものと考え、一つのアカウントはＣＰＵの９０％を使って1つのタスクのみを実行し、他の２つのタスクを残りのＣＰＵ（１０％、すなわち５％づつ）が行い、５つのタスクを各々実行する場合を想定する。この場合、比は１：９０であり、この状況は、Ｌｉｎｕｘのデフォルトの計算によっては扱うことはできない。

本発明の他の実施例では、良好値以外の高レベル計算を行い、Ｌｉｎｕｘがスケジューリング行う際には、いくつかのアカウントのみを考慮し、他のアカウントは考えない。例えば、上述した場合では、一つのスケジュールの周期の間は、一つの小さいアカウントに全１０％を割当て、次のスケジュールの周期の間に、他のアカウントにそれ（１０％）を割当てる。同様の構成をアカウント中のタスクに適用し、いくつかのアカウントのみが各時間に実行するようにする。これは、選択されたタスクが、割当てられた全資源を消費することはないために、タスクに保証された資源量を得られないであろう静的な解決方法となる。

本発明の一実施例によれば、スケジューラを変更し、新しいスケジューリングの周期が完了するたびに、ひとつに満たないタスクに、いくつかのティックを割当てるようにする。タスクの累積重みに応じて、タスクが受けるティックの数が与えられる。この解決方法は、動的なものであり、これらのタスクには、応分の割当量が確保される。

タスクごとに、累加重みとなる付加値を与え、スケジューラは、現在の割当てでの、ひとつに満たないティックに割当てるティックの数を知る。タスク選択を行う毎に、スケジューラは、ひとつに満たないティックのタスクに対して、充分な時間があるかどうかを判定し、もし、時間がある場合には、（その重みに基づき）それらのタスクから一つを選択し、そのタスクを実行する。

以上の例および説明は、もちろん例証を目的として与えられたものであり、いかなる方法によっても、発明を制限しようとするものではない。当業者であれば理解できるように、本発明は、上述した方法以上の手法を用いることにより、多様な方法で実施することが可能である。例えば、消費者が、資源の割当て前に、資源割当てのポリシーを監視することも可能であるが、これは本発明の範囲を逸脱するものではない。

図１は、本発明の一実施例における、複数の消費者をもつコンピュータシステムにおける資源の階層的な割当について、その概略を示した図である。 図２は、本発明の一実施例における、ＯＳの動作を変更する一部として、要求された手続きの修正について、その概略を示した図である。 図３は、特定のアカウントによるＣＰＵの使用について、その概略を示した図である。

Claims (16)

1. オペレーティングシステム（ＯＳ）で管理され、複数の消費者のアカウントを有するコンピュータシステムにおいて、資源を動的に割当てて管理する方法であって、
   ａ）消費者に関する個々のアカウントについて、スワップファイル中に、仮想メモリアドレス空間の各部分を割当てるステップと、
   ｂ）各アカウント毎に前記メモリアドレス空間を制限するステップと、
   ｃ）各アカウントから要求されたタスク間でＣＰＵ使用量を分配するステップと、
   ｄ）オリジナルコード中の一つ以上の特定の手続きを決めることにより、さらに、前記メモリアドレス空間の割当ておよび／または制限、および／または、プロセス数および／または分割されたＣＰＵ使用量の制限に応じて、実行する特定の処理を変更することにより、前記ＯＳのオリジナルコードのセグメントを変更するステップと、を含む前記方法。
2. 請求項１記載の方法において、さらに、前記メモリアドレス空間および／または前記分配されたＣＰＵ使用量の割当ておよび／または制限を変化させることに応じて、実行する特定の処理を動的に変更するステップを含む前記方法。
3. 請求項１記載の方法において、要求された手続きを決めることは、シンボルテーブルに格納された前記要求された手続きの名称を取得することを含む前記方法。
4. 請求項１記載の方法において、要求された手続きを決めることは、該要求された手続きのバイトシーケンスを識別することにより、実行される前記方法。
5. 請求項１記載の方法において、特定の手続きの変更は、
   ａ）割当てられたメモリアドレス空間を取得するステップと、
   ｂ）前記割当てられたメモリアドレス空間で、実行コードを生成するステップと、
   ｃ）オリジナルコードからコードセグメントをコピーするステップと、
   ｄ）前記コピーされたコードの開始のコマンドラインを保存し、前記オリジナルコード中の次のコマンドの開始までスキップするステップと、
   ｅ）前記オリジナルコードの開始のコマンドラインを、前記生成されたアプリケーションの開始までスキップするステップに置き換え、前記生成されたアプリケーションの非使用バイトに無演算バイトを付加するステップと、を含む前記方法。
6. 請求項４記載の方法において、空白バイトは無演算（ＮＯＰ）データである前記方法。
7. 請求項１記載の方法において、前記メモリアドレス空間の制限は、
   ａ）資源を消費するための呼び出しが特定の消費者のアカウントによるものでない時は常にオリジナルコードを呼び出し、関連パラメータにより前記アカウントを識別するステップと、
   ｂ）アカウントにより資源の消費が要求される毎に、前記アカウントは、前記アカウントのクオータまたはその上位レベルのクオータを越えないように前記割当てられたメモリアドレス空間に従って、検証するステップと、
   ｃ）前記アカウントに関連する処理の結果をチェックし、前記処理が成功する毎に、前記アカウントおよび／または前記アカウントの上位レベルの消費データを更新するステップと、を実行することにより実施される前記方法。
8. 請求項７記載の方法において、特定するパラメータは、ユーザＩＤ、グループＩＤまたはプログラム名である前記方法。
9. 請求項１記載の方法において、前記メモリアドレス空間の前記制限は、オリジナルコードを新コードと置き換えることにより実施され、当該実施は、
   ａ）新コードにメモリを割当てるステップと、
   ｂ）オリジナルコードの開始を、新コードへのジャンプ処理により置き換えるステップと、を含む前記方法。
10. 請求項９記載の方法において、オリジナルコードを完全に無視するために、新コードは復帰処理で終了する前記方法。
11. 請求項９記載の方法において、新コードは、オリジナルコードの処理の一部を含む前記方法。
12. 請求項１記載の方法は、さらに、タスクにより使用されていないＣＰＵ資源を、他のタスクに動的に割当てるステップを含む前記方法。
13. 請求項１記載の方法において、ＣＰＵ使用量は、全てのタスク間で均等に分配される前記方法。
14. 請求項１記載の方法において、各タスクが前記タスクに関連したアカウントのクオータにより制限されるように、タスク間でのＣＰＵ使用量の分配は実行される候補となるタスクのカウンタの計算を変更することにより得られる前記方法。
15. 請求項１４記載の方法において、カウンタ計算の変更は、
    ａ）カウンタの計算を実行する関数に処理を中断させるステップと、
    ｂ）ユーザアカウントに保証された値に基づき、各タスクに対する所望のカウンタ値を計算し、同一のアカウントに所属する複数のタスクが存在する場合に常に前記値が計算される際に、クオータに応じてカウンタの正しい値を保持し、それらの現状の利用状況に応じて、それらのタスクの内部割当てが現在行われている間に、アカウントに応じて前記タスクのカウンタ値を合計するステップと、
    ｃ）各プロセスの動作に関する情報を保存するステップと、
    ｄ）各時間刻み毎に、アカウントが最近の時間に受け取ったＣＰＵ資源量を計算し、前記計算された資源量を、前記アカウントの上位のレベルに加えるステップと、
    ｅ）前記アカウント、または、前記アカウントの上位のレベルが、その割当量よりも多くの資源量を受け取る毎に、次のＣＰＵ割当てが行われるまで、タスクのカウンタをゼロに減らすステップと、
    ｆ）実行すべき次のタスクを決定する毎に、次に実行すべきタスクの選択が有効であることを確認するステップと、を含む前記方法。
16. 実質的に説明し例証したように、複数の消費者のアカウントを有するコンピュータシステムの資源を動的に割当て管理する方法。

Images