JP5763168B2 - プロセッサパフォーマンスマネジメントシステムからの処理のマスキングによる電源消費の低減 - Google Patents

Description

本発明は、一般に、情報技術におけるエネルギー効率の分野に関し、特に、動的周波数電圧制御（ＤＦＶＳ：dynamic frequency and voltage scaling）とも呼ばれるプロセッサパフォーマンスマネジメント（ＰＰＭ）が採用される場合に、エネルギー効率を向上させることに関する。特に、本発明は、特定の処理（特に、ユーザアプリケーション、システムレベルサービス、又は「デーモン」）に関連付けられる計算負荷の電力パフォーマンスマネジメントアルゴリズムへの影響を低減することによって機能する省電力技術に関する。

今日、コンピュータ、及び、プロセッサ（特に、中央処理装置（ＣＰＵ））を備える他のデバイス／装置（とりわけ、大半の時間、バッテリ電力を用いて機能する、ラップトップ、ＰＤＡ、携帯電話等の携帯機器）の電力消費を低減するために、プロセッサパフォーマンスマネジメントは広く用いられている。本明細書において、「コンピューティング装置（computing apparatus）」という用語は、プロセッサを備えるデバイス／装置を指し示すための一般的な表現として用いられるべきである。

最新のプロセッサは、広範囲にわたる様々なクロック周波数及びプロセッサコア電圧（Ｖｃｃ）において機能することが可能である。動作周波数と動作電圧との各組み合わせは、プロセッサパフォーマンスの異なる標準に対応し、「パフォーマンス状態」、「動作点」、又はＡＣＰＩ（Advanced Configuration and Power Interface standard）に従って「Ｐステート」としばしば称される。各パフォーマンス状態は、異なるレベルの電力消費を伴う：電力消費は、ＣＰＵクロック周波数と共に直線的に上昇し、動作電圧の二乗に比例して上昇する。換言すると、次式（１）は、電力消費ＰがＣＰＵクロック周波数ｆ及び動作電圧Ｖと共にどのように変化するかの近似である：

ここで、Ｃはプロセッサのキャパシタンスである。

一例として、表１は、１．６ＧＨｚ Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ^ＴＭ Ｍプロセッサによってサポートされるプロセッサパフォーマンス状態を示す。

大まかに言えば、プロセッサパフォーマンスマネジメントは、そのときシステムに適用可能な条件に基づいて、及び／又はユーザによって特定されていてもよい電力マネジメントプロトコルに基づいて、プロセッサについてのパフォーマンス状態を動的に選択することを伴う。典型的には、高パフォーマンス状態（とり得る最高動作周波数及び最高動作電圧）はプロセッサの使用率が高い場合に選択され、省電力の低パフォーマンス状態（とり得る最低動作周波数及び最低動作電圧）は、プロセッサの使用率が低い場合に選択され、中間の状態は他の状況において選択されるであろう。

プロセッサパフォーマンス状態の選択に影響を及ぼす特定の要因は複数とすることができ、システムごとに異なる。考慮される典型的なパラメータは、プロセッサ使用率（又はプロセッサ「アクティビティ」）、ユーザの電力ポリシー、現在のバッテリレベル、並びに加熱条件及び熱イベントを含むが、これらに限定されない。さらに、ＰＰＭアルゴリズムによっては、これらのパラメータの予測値に基づいて、次の期間についてのプロセッサパフォーマンス状態の選択をするものもある。

ＰＰＭは、プロセッサ、ＢＩＯＳ及び／又はオペレーティングシステムにおける機能を利用して、様々な手法で実装されることができる。周知のＰＰＭシステムの例は、ＡＭＤのＰｏｗｅｒＮｏｗ！^ＴＭ、ＡＲＭのＰｏｗｅｒＷｉｓｅ ＡＶＳ（Adaptive Voltage Scaling）及びＩＥＭ（Intelligent Energy Manager）、並びにＩｎｔｅｌのＥｎｈａｎｃｅｄ ＳｐｅｅｄＳｔｅｐ^ＴＭテクノロジーを含む。

ＰＰＭシステムを分解する１つの手法は、所与の期間についてどのプロセッサパフォーマンス状態が選択されるべきであるかを決定する制御ユニットと、（例えば、Ｉｎｔｅｌ ＳｐｅｅｄＳｔｅｐ^ＴＭシステムのように、プロセッサの内部にあるレジスタに、次に対象となるプロセッサパフォーマンス状態を識別するコードを書き込むことによって）プロセッサパフォーマンス状態の所望の設定を実装するドライバモジュールと、があると考えることである。幾つかの場合に、対象となるプロセッサパフォーマンス状態及び／又は実際のプロセッサパフォーマンス状態を保持するレジスタのロケーションを判定するために、オペレーティングシステムはＢＩＯＳを参照する必要があり得る。プロセッサがパフォーマンス状態を変化させるように指示される場合、典型的には、プロセッサは所望の動作電圧を関連付けられる電圧レギュレータに特定する。

本発明は、プロセッサパフォーマンス状態における所望の変化を指示するために用いられる特定の技法に関わらず、また、指示された変化を実装するために採用される特定の技法に関わらず、適用されることができる。

しばしば、様々な電力マネジメントポリシーのグループがあり、ユーザは、所与の時間にシステムが適用することをユーザが所望するポリシーを選択し、及び／又は当該ポリシーを構成することができる。例えば、オペレーティングシステムのＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ７^ＴＭは、「パフォーマンス（Performance）」、「バランス（Balanced）」及び「パワーセーバ（Power Saver）」とそれぞれ呼ばれる３つの電力マネジメントポリシー（又は「電力プラン」）を仕様化し、ユーザは、例えば所与のポリシーにおける最大限度及び最小限度のプロセッサ使用率を特定することによって、これら３つのポリシーをカスタマイズすることが可能である。

多くの場合、プロセッサへの負荷が当該プロセッサについて選択されるパフォーマンス状態に影響を及ぼすＰＰＭモードにおいて、システムは動作するであろう。

プロセッサアクティビティを考慮してプロセッサパフォーマンスを選択するＰＰＭポリシーを実装するように構成されるコンピュータ（又はデータ処理能力を有する他のデバイス）は、計算集約的なタスクが処理されている場合は常に、高パフォーマンスプロセッサ状態（即ち、高い動作周波数及び高い動作電圧と共に高い電力消費）を選択するであろう。概して、ＰＰＭモジュールは、実際に迅速に処理されるべきである優先度が高いタスクと、緊急ではない（即ち、電力消費の低減につながる場合は、タスクをよりゆっくり完了すること、即ち、より低いプロセッサパフォーマンス状態、をユーザが容認するであろう）タスクとを、区別することができない。

この点において、コンピュータユーザがユーザのシステムのリソースをボランティアコンピューティングプロジェクトに提供し、当該ユーザのシステムが、少なくとも部分的にはプロセッサへの計算負荷に基づいてプロセッサパフォーマンス状態を選択するＰＰＭポリシーを実装するように構成されている場合に、何が起きるかを考慮されたい。

ボランティアコンピューティングにおいて、人々は、自身のコンピュータリソースを、大きな、及び殆どの場合、科学的なコンピューティングプロジェクトに寄与させる。周知のボランティアコンピューティングプロジェクトは、climateprediction.netのウェブサイトを介して主としてオックスフォード大学によって実行される気候モデリングプロジェクトである。

ボランティアコンピューティングプロジェクトに参加することができるように、ユーザは、典型的には、当該ボランティアコンピューティングプロジェクトに関連付けられるサーバから小さなアプリケーションをダウンロードし、当該アプリケーションをユーザのコンピュータにインストールする。アプリケーションは、データのブロックをダウンロードし、ボランティアに充てられたコンピュータのプロセッサを用いて計算を実行し、結果をサーバにアップロードし、次のデータのブロックをダウンロードする等する。ボランティアコンピューティングプロジェクトは、概して、計算集約的な、即ち、主に数学的な演算を実行することをプロセッサに要求するアプリケーションを伴う。このようなアプリケーションは、しばしば「ＣＰＵバウンドな（CPU-bound）」アプリケーションと称される。

最も一般的な場合おいて、ボランティアコンピューティングアプリケーションは、コンピュータがしばらくの時間アイドル状態にあるときにのみ実行され、即ち、スクリーンセーバとして実行されるように構成される。この種の場合（及び他の場合）において発生する電力消費を評価するために、ベンチマークアプリケーションが書かれ、このベンチマークアプリケーションは、ダミー計算を実行して、ＣＰＵバウンドなユーザアプリケーションの振る舞いを模倣するように設計された。ベンチマークアプリケーションは、下記の装置を用いて実行された：ＳｐｅｅｄＳｔｅｐ^ＴＭテクノロジーをフィーチャーした、１５００ＭＨｚ Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ^ＴＭ Ｍ Ｂａｎｉａｓプロセッサを用い、Ｌｉｎｕｘカーネルバージョン２．６．３１を有するＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを用い、プロセッサのパフォーマンス状態をプロセッサの使用率に基づいて選択するように構成される、ソニーのＶＡＩＯ^ＴＭラップトップ（ＰＣＧ−Ｚ１ＳＰモデル）。

ベンチマークアプリケーションが上記の装置上でスクリーンセーバとして実行された場合、当該アプリケーションの実行中のプロセッサ使用率（又はプロセッサ負荷）は１００％であり、従って、ＰＰＭシステムは、利用可能な最も高いパフォーマンスのプロセッサ状態を選択した。これらの条件において、計算を完了するために約５７秒を要し、凡そ１７００ジュールのエネルギーが用いられ、平均電力消費は３０ワットとなった。ボランティアコンピューティングアプリケーションがユーザのリソースを用いることができるように、ユーザがユーザのコンピュータを意図的に純粋にオンのままにしている場合、この電力の全ては、純粋に当該ボランティアコンピューティングプロジェクトへの参加の結果として消費されている。

対照的に、例えばユーザがユーザのコンピュータを通常の事務作業に用いている間に、ボランティアコンピューティングアプリケーション（又は、他のＣＰＵバウンドなタスク）をバックグラウンドタスクとして実行することも可能である。

図１は、ユーザが（上記のように構成される）上述されたラップトップを通常の事務作業について用いる場合のＣＰＵアクティビティの典型的なパターンを図示する。図１（ａ）は、時間に伴うＣＰＵ負荷における変化の典型的なパターンの一例を図示し、図１（ｂ）は、（ＣＰＵ負荷が高い場合は高パフォーマンスプロセッサモードを選択するが、ＣＰＵ負荷が低い場合には低パフォーマンスプロセッサモードを選択するように構成される）ＰＰＭシステムの制御下で、同じ期間にわたりＣＰＵクロック周波数がどのように変化するかを示す。

図１（ａ）から、ラップトップが典型的な事務作業について用いられる場合、平均的なＣＰＵ負荷は低いこと、即ち、概して２０％を下回ることが分かるであろう。図１（ｂ）は、ＣＰＵのクロック周波数も、（例えば、事務アプリケーションが画像をロードし及び展開する場合に）時折より高い周波数に急上昇するものの、低いままであることを示す。ラップトップが通常の事務作業に用いられる場合の電力消費は、およそ１３ワットであり、これはラップトップがアイドルである（即ち、ＣＰＵ負荷がゼロに近い）場合と実質的に同じである。

ユーザが上記のテスト用のラップトップ構成上で通常の事務作業に従事している間に、ベンチマークアプリケーションがバックグラウンドタスクとして実行された場合、ベンチマークアプリケーションはプロセッサ使用率を１００％に急上昇させ、ベンチマークアプリケーションが実行されている全期間についてＰＰＭシステムに高パフォーマンスプロセッサモードを選択させた。繰り返しになるが、計算には約５７秒を要し、この期間にわたる平均電力は３０ワットであった。しかしながら、この場合、ユーザが通常の事務作業を実行するためにいずれにしても要したであろう電力に加えて、１７ワットの「余分な」電力のみが消費されたと言うのが妥当であろう（これは、スクリーンセーバの場合に用いられる１７００ジュールのエネルギーから、バックグラウンドにおいて実行される場合の９６９ジュールへの低減を表す）。

従って、ユーザがユーザのコンピュータを用いることに従事している間に、計算集約的なアプリケーション（又は、より一般的には、計算集約的なタスク）をバックグラウンドタスクとして実行させることは、当該アプリケーションをスクリーンセーバとして実行させるよりもエネルギー効率が良いが、依然として多量の付加的なエネルギーの消費を伴う。

さらに、ＣＰＵバウンドなタスクがバッググラウンドにおいて実行され、ＣＰＵ負荷を比較的低いレベルから１００％に上昇させた場合、これはやがてＣＰＵに熱ストレスを与え、コンピュータのファンはフルスピードで回転し始めた。マシンのノイズはやがてユーザにとって憂慮すべきものとなり、それ以上の時間許容することは困難になったであろう。

ボランティアコンピューティングのコンテキストにおいて試行された１つのアプローチは、ユーザのコンピュータリソースをボランティアコンピューティングアプリケーションに利用可能な時間の割合をユーザが制限することを可能にすることである。この機能性は、ＢＯＩＮＣ（Berkeley Open Infrastructure for Network Computing）と呼ばれるソフトウェアパッケージによって提供され、これはボランティアコンピューティングプロジェクトを展開するためにしばしば採用される。ユーザのコンピュータリソースは１００％よりも少ない時間についてボランティアコンピューティングプロジェクトに利用可能であるべきであるとユーザが特定する場合、ＢＯＩＮＣマネージャは、アプリケーションの状態を「スリーピング」に変更するようにオペレーティングシステムに断続的に要求して、平均ＣＰＵ使用率をユーザによって特定される割合に低下させるであろう。例えば、これが計算集約的なアプリケーションであり、当該アプリケーションが実行される２秒間の間のＣＰＵ負荷は１００％であるという仮定の下で、２０％のユーザ設定は、ＢＯＩＮＣマネージャにアプリケーションを２秒間だけ実行させ、８秒間だけ「アプリケーションをスリープにする」ことになるであろう。アプリケーションがスリープすると、ＣＰＵ負荷はそのアイドルレベル（又は、ＣＰＵによって実行される任意の他の処理に起因し得る（attributable）レベル）に下がるであろう。

ボランティアコンピューティングアプリケーションがＣＰＵに対して有することができるアクセスをユーザが制限するようにＢＯＩＮＣが提供する機能（facility）は、当該アプリケーションによって消費されるエネルギーにおける低減をもたらさない。これは下記から分かる：
αをＣＰＵ使用率の許容される度合いのユーザ設定値とする。ただし、０＜α≦１；
Ｐ_０は、ＣＰＵ負荷が０％である場合の電力消費量である（ＣＰＵはアイドルである）；
Ｐ_１００は、ＣＰＵ負荷が１００％である場合の電力消費量である；
Ｔ_１００は、ＣＰＵ負荷が１００％であり、且つ、計算が中断されない場合に計算を実行するために要するであろう時間である；
Ｔは、計算を完了するために要する実際の時間である（「スリープ」期間を含む）。

平均電力消費量は、Ｐ＝αＰ_１００＋（１−α）Ｐ_０であるべきである。ただし、（アイドルの間にコンピュータによって用いられる電力に加えて）ボランティアコンピューティングアプリケーションを実行させることに起因する「余分な」電力消費量は、Ｐ＝α（Ｐ_１００−Ｐ_０）のみである。

ＢＯＩＮＣによって導入されるスリープのために、計算時間はＴ_１００からＴ＝Ｔ_１００／αに伸びる。従って、ボランティアコンピューティングアプリケーションを実行させるために消費される「余分な」総エネルギーＥ＝Ｐ×Ｔは、（Ｐ_１００−Ｐ_０）×Ｔ_１００になり、これは「スリープ」無しの場合と全く同じである。

実際、計算集約的なアプリケーションのＣＰＵへのアクセスがこのように制限される場合、消費される総エネルギーは実際には上昇することが現実に分かっている。図２は、ＢＯＩＮＣによって提供される機能性を再現するように適合されるベンチマークアプリケーションの変更されたバージョンがテスト用のラップトップ構成上で実行された場合に、（ボランティアコンピューティングアプリケーションがＣＰＵにアクセスできる時間の割合を表す）パラメータαの値と共に電力消費量がどのように変化したかを示す。図３は、これらの実験においてパラメータαの値と共に計算時間がどのように変化したかを示す。

図２から、αのほぼ全ての値について、スリープが無い場合（即ち、α＝１の場合）よりもエネルギー消費量は大きいことが分かる。さらに、図３は、αの１よりも小さい全ての値について、計算の持続時間は増加することを示す。換言すれば、ＢＯＩＮＣによって提供される機能を用いてＣＰＵ使用率を制限することは、主にエネルギー消費量の増加及び計算を完了するために要する時間の長期化という結果になるように見える。

さらに、パラメータαがＢＯＩＮＣプリファレンスにおいて０．２よりも大きい値に設定される場合、ＣＰＵへの熱ストレスはファンを作動させ、マシンが急速に耐えがたいほど騒々しくなることが見出された。

ボランティアコンピューティングアプリケーション（又は、他のＣＰＵバウンドなタスク、例えば、ユーザアプリケーション、システムレベルサービス、マルチタスキングオペレーティングシステム環境におけるデーモン等）がスクリーンセーバとして実行されてもバックグラウンドタスクとして実行されても、このアプリケーションを実行させることに伴うエネルギーの相当な余分の消費があることが上記から分かるであろう。この著しいエネルギー使用量の一因は、ボランティアコンピューティングアプリケーションの実行が、（１００％又は１００％に迫る）高いＣＰＵ使用率を伴うという事実にあり、これは、このアプリケーションが実際にはプロセッサからの高いパフォーマンスを必要としなくても、ＰＰＭシステムが高パフォーマンスプロセッサモードを選択することにつながる（ユーザはタスクを急いで実行させることへの必要性を実際には有しない。ユーザは、当該タスクの実行が完了されるために要する期間の延長を許容し得る）。

より一般的に考慮すると、少なくとも部分的にはプロセッサ使用率に基づいてプロセッサパフォーマンス状態を選択するＰＰＭシステムは、高パフォーマンス状態の選択を促すプロセッサ負荷の一部が実際にはユーザにとって緊急でもなく優先度も高くない場合でも、相当な割合で電力を消費し得る。

明らかに、プロセッサによって実行されるべき唯一のタスクが緊急でない場合、ユーザは、プロセッサを常に低パフォーマンス／低電力消費状態に設定する電力マネジメントプロファイルを選択し得る。しかしながら、これは、緊急なタスクと緊急でないタスクとにプロセッサが直面させられる場合には、適当ではない。そのような状況においては、プロセッサパフォーマンス状態を設定する場合にＣＰＵ負荷を考慮するＰＰＭプロファイルをそのままにしておく方がユーザには良いだろう。

特許文献１は、様々なワークロードに優先順位の明示的な割当てがあり、それにより、ＰＰＭアルゴリズムがプロセッサパフォーマンス状態をプロセッサ使用率だけでなく、当該ワークロードの優先順位にも基づいて選択することができるようにコンピュータシステム（特に、そのオペレーティングシステム）が構成される技法を記載する。しかしながら、既存のコンピュータシステム（又は、データ処理能力を有する他のデバイス）がこの技法を利用することが可能になるためには、各システム／デバイス上のオペレーティングシステムをアップデートする必要があるであろう。これは、非常に多くの異なるタイプのオペレーティングシステム（及び、様々なオペレーティングシステムのバージョン）が現在使用されていることを考えると、非現実的なタスクである。

米国特許出願公開第２００９／０１９９０１９号明細書

本発明は、計算集約的ではあるがユーザにとって緊急でないタスク、即ち、実行の完了のために要する時間における幾らかの増加をユーザが許容できるタスクにプロセッサが直面する場合に、比較的低パフォーマンスのプロセッサ状態が維持されることを可能にするための異なるアプローチを提案する。オペレーティングシステムのレベルにおいて問題に対処する代わりに、本発明は、タスクがＰＰＭシステムからマスクされるようにタスクを適合させて、タスク自体のレベルにおいて問題に対処する。

より具体的には、本発明は、本明細書に添付される特許請求の範囲において定義されるエネルギー消費量低減方法、コンピュータプログラムプロダクト、コンパイラ及びコンピューティング装置を提供する。

本発明に係る技法は、ＣＰＵへの負荷に少なくとも部分的に基づいてプロセッサパフォーマンス状態を選択するＰＰＭアルゴリズムを採用するシステム上で計算集約的であるが緊急ではないタスクが実行される場合に為されるべきエネルギー節約を可能にする。本発明は、タスクの実行に関連付けられる計算負荷のＰＰＭアルゴリズムへの影響を低減する。特に、本発明は、選択されるタスクの実行に関連付けられるＣＰＵへの計算負荷をＰＰＭシステムが充分に考慮した場合よりも、比較的低いパフォーマンスのプロセッサ状態をＰＰＭシステムが維持するであろう可能性をより高くする。選択されるタスクの実行に関連付けられるＣＰＵ負荷は、ＰＰＭシステムから充分に又は部分的にマスクされたと見なすことができる。このマスキングは、通常要したであろう割合のエネルギーのみを用いてタスクが実行されることを可能にすることができる。

さらに、本発明のエネルギー節約技法は、プロセッサへの熱ストレスを低減し、（雑音も同時に低減しつつ）冷却ファンを動作させるために必要な時間を低減する利点を提供する。

本発明のエネルギー節約技法は、採用される特定のプロセッサ、オペレーティングシステム、ＰＰＭシステム、又はデバイスアーキテクチャに依存せず、関連するオペレーティングシステム及び／又はＰＰＭシステムがＣＰＵ負荷をヒューリスティックとして用いてプロセッサ電力状態を判定する限り、実質的に任意の最新のプロセッサ、オペレーティングシステム、及び／又はデバイスアーキテクチャと共に用いられることができる。

本発明のエネルギー節約技法は、マルチコアプロセッサの場合でも採用されることができる。本発明のマスキング技法を採用しているタスクが第１のプロセッサコア上で実行されており、図らずして異なるプロセッサコア上に移行される場合、マスキングプロシージャにおいて短期間の悪影響（perturbation）があり得るが、最悪の場合でも、これはすぐに減少するＣＰＵ負荷における一時的な増加となる。

本発明のさらなる特徴及び利点は、添付の図面に関連して、限定ではなく例として与えられる本発明の好適な実施形態の以下の説明から明らかになるであろう。

ＣＰＵ負荷を図示するグラフである。 ラップトップが通常の事務作業に用いられる場合におけるＣＰＵクロック周波数を示すグラフである。 パラメータα（ＢＯＩＮＣソフトウェアパッケージによって提供されるオプションに従ってアプリケーションを実行するためにＣＰＵに許可される時間の割合）に依存して、ユーザアプリケーションが実行される場合に消費されるエネルギーがどのように変化するかを図示するグラフである。 図３は、図２の実験中に、パラメータαと共に計算時間がどのように変化するかを図示するグラフである。 パラメータＴ及びＳの変化する値と共に（ベンチマークアプリケーションを実行する場合の）エネルギー節約がどのように変化するかを図示するグラフである。 Ｔ及びＳの変化する値と共に（ベンチマークアプリケーションを実行する場合の）プロセッサが最低電力モードにとどまる時間の割合がどのように変化するかを示すグラフである。 本発明の第１の好適な実施形態の有効性を説明する実験中のアクティブ期間Ｔの持続時間と共にベンチマークアプリケーションを実行することで消費される総エネルギーがどのように変化したかを図示する。 図５（ａ）の実験において、Ｔと共にベンチマークアプリケーションの実行を完了するために要した時間がどのように変化したかを図示する。 図５（ａ）の実験において、Ｔの様々な値についてＣＰＵが低電力（アイドル）パフォーマンスモードにあった時間の割合を示す。 図５（ａ）の実験において、ベンチマークアプリケーションの実行に起因し得る余分なエネルギー消費量がＴと共にどのように変化したかを図示する。 本発明の第１の好適な実施形態の有効性を説明する実験中のアクティブ期間Ｔの合間のインターバルＳの持続時間と共に、消費される総エネルギーがどのように変化したかを図示する。 図６（ａ）の実験において、ベンチマークアプリケーションの実行を完了するために要した時間がＳと共にどのように変化したかを図示する。 図６（ａ）の実験において、Ｓの様々な値についてＣＰＵが低電力（アイドル）パフォーマンスモードにあった時間の割合を示す。 図６（ａ）の実験において、ベンチマークアプリケーションの実行に起因し得る余分なエネルギーの消費量がＳと共にどのように変化したかを図示する。 気候モデルの実行に起因し得る余分なエネルギー消費量がアクティブ期間Ｔの合間のインターバルＳと共にどのように変化したかを図示する。

図４から図７を参照しつつ、現在好適である、本発明の第１の実施形態が説明されるであろう。

ＣＰＵ負荷を判定するためにＰＰＭシステムによって用いられる詳細なヒューリスティックは、特にオペレーティングシステムのタイプ／バージョン間で異なる。例えば、オペレーシングシステムのＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ７^ＴＭは、プロセッサアクティビティの計算（accounting）を、現在のシステムアクティビティに基づいてどのパフォーマンス状態が適当かを判定する際により精密度が高い新しいやり方で扱う。

本発明は、ＣＰＵ使用率を評価するためにＰＰＭシステムが用いている特定のヒューリスティクスに関わらず適応されることができ、プロセッサがＣＰＵバウンドなタスク又は処理を実行しているとしても、ＰＰＭシステムがプロセッサについて比較的低いパフォーマンス状態を維持するように欺いて、ＣＰＵ使用率に少なくとも一部は基づいてプロセッサパフォーマンス状態を選択するプロファイルに従ってＰＰＭシステムが実行されている間にエネルギー節約は達成されることができるという概念に基づく。

本発明は、概して、ＰＰＭシステムがＣＰＵ負荷を一定時間ごとに評価し、所与の時間間隔についてのＣＰＵ負荷について判定される値に基づいて、どのプロセッサパフォーマンス状態を選択すべきかを決定するという知見に基づく。本発明によれば、タスクの実行に関連付けられる平均的なプロセッサ使用率は、ＣＰＵ負荷を判定する際にＰＰＭシステムが適用する評価期間にわたって低減されるので、ＰＰＭアルゴリズムには、タスクは「見え（see）」ない（又は、部分的にしか「見え（sees）」ない）。換言すれば、タスクの実行に関連付けられる計算負荷は、ＰＰＭシステムによって選択されるプロセッサパフォーマンス状態への低減された影響を有するようにされる。

本発明の第１の好適な実施形態において、ＣＰＵ負荷を評価するためにＰＰＭシステムによって用いられる各評価期間にわたってタスクがそのＣＰＵ使用率を低減することができるように採用される技法は、定期的な短いインターバルをアクティブ期間の合間に設けて、タスクが非常に短い期間にわたって実行されるように構成することである。ＢＯＩＮＣにおいて用いられるアプローチと同様に、本発明の第１の好適な実施形態において、タスクは「マイクロスリープ」（即ち、ごくわずかなスリープであり、ここでの「マイクロ」という用語の使用は、これらのごくわずかなスリープの持続時間をマイクロ秒に限定しない）を有すると見なされ得る。

本発明の第１の好適な実施形態の場合、アクティブ期間及びそれらの合間のインターバルの持続時間は、ＰＰＭシステムの評価期間にわたってタスクによって生じる平均的なＣＰＵ負荷が比較的低くなり、プロセッサについてより高いパフォーマンス状態の選択をトリガする可能性が低くなるように設定される。しかし、この低減された平均的なＣＰＵ負荷は依然としてゼロではない。即ち、計算上、依然として幾らかの進展が為されている。従って、ＢＯＩＮＣにおけるスリープとは異なり、本発明の第１の好適な実施形態において用いられるマイクロスリープは、エネルギー消費量における低減を確実にもたらす。

実際に、ＢＯＩＮＣは、本発明において採用されるタイミング粒度（timing granularity）を生成することはできない。ＢＯＩＮＣソフトウェアパッケージが用いられてボランティアコンピューティングアプリケーションが展開される場合、当該アプリケーションは、シグナルハンドラを実装するＢＯＩＮＣライブラリにコンパイルされなければならない。ボランティアに充てられるプロセッサ上でのアプリケーションの実行中、ＢＯＩＮＣマネージャは、別個のプロセスとして実行され、（オペレーティングシステムによって提供されるプロセス間通信機能を用いて）アプリケーションに一定時間ごとに信号を送信する。シグナルハンドラがＢＯＩＮＣマネージャから信号を受信する場合、どのくらいの時間が経過したかをチェックし、必要であればアプリケーションをスリープにする。アプリケーションをスリープにするための技法は、アクティブ期間、及び本発明に関与する短期間のマイクロスリープを生成することができない。

図４から図７は、エネルギー節約を実現するための第１の好適な実施形態に係るアプローチの有効性を実証する。上述されたベンチマークアプリケーションは、下記の疑似コードに従って、テスト用のラップトップ構成上で実行される：

この疑似コードは、ベンチマークアプリケーションにプロセッサにアクセスさせて期間Ｔの間に少量の作業を実行させ、インターバルＳの間はスリープにする。

Ｔ及びＳの値を、本発明の第１の好適な実施形態の効果を実証するように変化させた。

Ｓ＝０の場合、これはベンチマークアプリケーションがプロセッサに連続的にアクセスすることを意味し、平均的なＣＰＵ使用率は１００％となり、プロセッサについて（ＰＰＭシステムによって）高パフォーマンスモードを選択することになる。これは、上述されたスクリーンセーバ又は従来のバックグラウンド実行と同じである。

Ｔ及びＳの双方が、ＰＰＭシステムの評価期間Ｐａ（これは、ＧＮＵ／Ｌｉｎｕｘを用いる我々の例において、およそ１０ミリ秒である）と比較して大きい値に設定される場合、ＣＰＵ使用率が１００％であるＰＰＭ評価期間（アクティブ期間Ｔの間）と、ＣＰＵ使用率が０％であるＰＰＭ評価期間（スリープＳの間）とが存在する。従って、ある期間の間は高パフォーマンスモードが選択され、他の期間については低パフォーマンスモードが選択される。これは、省電力無しの、ＢＯＩＮＣの使用制限機能を用いて得られる振る舞いと同じである。

図４は、Ｔ及びＳが評価期間Ｐａよりも大きい及び小さい異なる値に設定された場合に
観察された振る舞いを図示する。図４（ａ）は、Ｔ及びＳの値と共にエネルギー使用量がどのように変化したかを図示し、図４（ｂ）は、プロセッサが最低電力パフォーマンス状態において費やす時間の割合に対してＴ及びＳの値を変化させることが有した効果を図示する。

下記の表２は、図４（ａ）及び図４（ｂ）においてグラフに描かれるデータ点の一覧である。

図４（ａ）から分かるように、Ｔが本例における評価期間Ｐａにおおよそ等しい約１０^７ＣＰＵチック以上であった場合、ベンチマークアプリケーションを実行させるために要した余分なエネルギーは、バックグラウンドにおいてアプリケーションを中断無しに実行させるために要した９６９ジュールのエネルギーを超えた。同様に、図４（ｂ）は、Ｔが１０^７ＣＰＵチック（≒Ｐａ）前後の値をとった場合、プロセッサは、最低電力を用いるパフォーマンス状態においてあまり時間を費やさなかったことを示す。

しかしながら、Ｔ及びＳがより小さな値に設定された場合、興味深い振る舞いが観察された。Ｓ及びＴの小さな値の範囲内で、ＰＰＭ評価期間の間、平均的なＣＰＵ負荷は１００％未満のままであり、従って、ＰＰＭシステムはベンチマークアプリケーションのためにＣＰＵパフォーマンス状態を増加させなかったが、計算上の有益な進展は依然として達成された。

図５は、Ｓが５００マイクロ秒に設定され、Ｔが１０^５から１０^７ＣＰＵチックの範囲における異なる値に設定された場合に、本例において観察された結果を示す。Ｔは、Ｉｎｔｅｌと互換性のあるプロセッサに提供されるＣＰＵタイプスタンプカウンタを用いて測定された。このカウンタは、ＣＰＵのクロックチックごとにインクリメントされ、オペレーティングシステムの介入なしに単一命令を用いて読まれることができる。

図５（ａ）は、実験の間に消費された総エネルギーがＴの値と共にどのように変化したかを図示する；図５（ｂ）は、ベンチマークアプリケーションの実行を完了させるために要した時間がＴと共にどのように変化したかを図示する；図５（ｃ）は、Ｔの様々な値について、ＣＰＵが低電力（アイドル）パフォーマンスモードにあった時間の割合を示す；また、図５（ｄ）は、ベンチマークアプリケーションの実行に起因し得る余分なエネルギー消費がＴと共にどのように変化したかを図示する。

図５（ｄ）は、ベンチマークアプリケーションの実行に起因し得る付加的な電力消費における明確な最小値を示す。この最小値は、Ｔが１０^６ＣＰＵクロックチックに設定された場合に生じた：マシンは依然として低パフォーマンス（低電力／アイドル）モードにあったが、有益な作業が依然として為されていた。計算時間は、１９０秒、即ち、（スクリーンセーバとして実行されようとバックグラウンドにおいて実行されようと）中断無しのＣＰＵ使用率の場合における持続時間の３倍強に伸びた。しかし、マイクロスリープと共にベンチマークアプリケーションを実行させることに起因し得る余分なエネルギー消費量の総量は、ベンチマークアプリケーションがバックグラウンドにおいて中断無しに実行されたフルパワーの場合に要したエネルギーの５０％未満であった。さらに、（ＣＰＵ負荷１００％において）ベンチマークアプリケーションがバックグラウンドにおいて中断無しに実行される上記の場合と比較して、１０００００ＣＰＵチックよりも大きい、グラフに描かれる全てのＴの値について、マイクロスリープアプローチを用いたエネルギー節約が観察された。図５のグラフには図示されていないが、図４及び図５から、このタスクによって課される平均的なＣＰＵ負荷が各評価期間の間に１００％よりも小さくなることを確実にするためには、Ｔに上限があること、つまり、Ｔは評価期間Ｐａの持続時間よりも小さく設定されるべきであること、即ち、Ｔ＜Ｐａに設定されるべきことが理解されるであろう。

図６は、Ｔが１０^６ＣＰＵチックに設定され、Ｓが２５マイクロ秒単位で１〜１０００マイクロ秒に増加された場合に観察された結果を示す。図６（ａ）は、実験の間に消費された総エネルギーがＳの値と共にどのように変化したかを図示する；図６（ｂ）は、ベンチマークアプリケーションの実行を完了させるために要した時間がＳと共にどのように変化したかを図示する；図６（ｃ）は、様々な値のＳについて、ＣＰＵが低電力（アイドル）パフォーマンスモードにあった時間の割合を示す：また、図６（ｄ）は、ベンチマークアプリケーションの実行に起因し得る余分なエネルギー消費がＳと共にどのように変化したかを図示する。

図６は、非アクティブ期間Ｓの小さな値について、即ち、１〜５００マイクロ秒の範囲において、ＰＰＭシステムが混乱し、ＣＰＵを高パフォーマンス状態から低パフォーマンス状態へ切り替え、及び元の状態へ戻す傾向があることを示す。実際、Ｓがあまりに小さい場合、オペレーティングシステムは、要求されたスリープ機能をアクティブループに置換し、ＣＰＵ負荷１００％のアセスメントにつながる。しかしながら、５００マイクロ秒よりも長い非アクティブ期間Ｓについては、ＣＰＵは低パフォーマンス／低電力状態に維持され、ベンチマークアプリケーションの実行に起因し得るエネルギー消費は低く維持された状態で、振る舞いは安定する。

図６（ｄ）から、本実験において、ベンチマークアプリケーションが中断無しにバックグラウンドにおいて実行される場合と比較して、９０マイクロ秒と１００マイクロ秒との間の小さなＳの値の範囲、及び約１３０マイクロ秒を超える、グラフに描かれる全てのＳの値について、（ＰＰＭシステムが上述したように「混乱している」低い値においても）エネルギー節約が実現されることが分かる。最も低いエネルギー消費は、５００マイクロ秒と６００マイクロ秒との間のＳの値について、実現される。ただし、同様のエネルギー節約は、より大きな値のＳにおいても実現される。

理論上、Ｓに上限は存在しない。ただし、ごくわずかなスリープの持続時間が長くなればなるほど、対象タスクを完了するためにかかる時間は長くなるであろう。従って、この特定の実験において、エネルギー節約と計算の時間との間の最適なトレードオフは、スリープ時間Ｓを５００〜６００マイクロ秒の範囲に設定することを含む。

最適よりも低いエネルギー節約（及び幾らかのファンノイズ）を許容することができる場合、Ｓの値を最適なエネルギー効率を与える値よりも低いが充分に大きく、評価期間Ｐａにわたる平均的なＣＰＵ負荷が依然として１００％未満であるように設定することによって、例えば、本例においては、Ｓを９０マイクロ秒と１００マイクロ秒との間、又は１３０〜５００マイクロ秒の範囲に設定することによって、タスクのより速い実行を実現することができる。

実際には、最適なエネルギー節約を提供するであろう、アクティブ期間Ｔ及び非アクティブ期間Ｓの値の特定の範囲は、考慮中の特定のタスク及びプラットフォーム（プロセッサ、オペレーティングシステム、ＰＰＭシステム）に依存して、状況ごとに変化するであろう。

上記の実験において、ベンチマークアプリケーションは、１５．３ワットの電力消費について実行され得るが、これはマシンの「アイドルの」電力消費（１３ワット）を２．３ワットだけ超過し、４４０ジュールのエネルギーが消費されることと同じである。ベンチマークアプリケーションが連続的に実行される場合よりも約３．３倍長く計算にかかるが、上記の実験は、本発明の第１の好適な実施形態に係るアプローチが、同じ計算集約なアプリケーションがバックグラウンドにおいて中断無しに実行される場合よりも２．２倍、及び、当該アプリケーションがスクリーンセーバとして実行される場合よりも３．８倍少ないエネルギーが用いられることを可能にすることを示す。

本発明の第１の好適な実施形態に従ってタスクの断続的な実行、即ち、ごくわずかなスリープのインターバルでインターリーブされるごくわずかな算出の期間を達成する多くの異なる手法が存在する。ユーザアプリケーション又はシステムレベルサービス（デーモン）の場合に、オリジナルコードに如何なる変更も必要としない１つの簡単な技法は、アプリケーション（又はサービス）がファンクションコールを呼び出す度に、経過したクロックサイクルが確認され、所望の時間Ｔが経過したことが分かった場合には、（持続時間Ｓの）ごくわずかなスリープが導入されるように、特別なコンパイルオプションを用いてアプリケーション（又はシステムレベルサービス）を再コンパイルすることにある。これは、例えば、多くのコンパイラにおいて利用可能なプロファイリングオプションを利用することによって達成されることができ、また、下記の実験においては、ファンクションコールが呼び出される度にごくわずかなスリープが導入されるように、ＧＮＵオペレーティングシステムのツールにおいて利用可能な「ｍｃｏｕｎｔ」プロファイリング機能の適合されたバージョンが用いられた。

第２の技法は、Ｔの現在の値をテストし、Ｔが所望の値に達したときに、プログラムを選択された期間Ｓについてスリープにする特殊関数を、一定の間隔で命令リストに挿入することによって、（ＣＰＵによって実行されるべきタスクを表す）低レベル命令の線形リストを変更することを伴う。

第３の技法は、ネイティブＣＰＵをエミュレートするバーチャルマシン上で予めアプリケーション（システムレベルサービス、デーモン等）を実行することにある。バーチャルマシンは、コードをプロファイルしてＣＰＵに負担をかけるプログラムの部分を発見し、ＣＰＵ上でネイティブに（即ち、バーチャルレイヤで）実行され、アプリケーションを選択された間隔でスリープにする新たな命令ストリームを生成する。

本発明の第１の好適な実施形態は、上述された３つの技法への言及によって限定されないことが理解されるべきである：他の適切な技法は、当業者であれば容易に想到するであろう。

最新の気候モデリングアプリケーションは、上述された３つの技法のうちの第１の技法に従って再コンパイルされ、上記のテスト用のラップトップ構成を用いてバックグラウンドにおいて実行された。図７は、Ｔ（計算のごくわずかな期間各々の持続時間）がプロセッサクロックの１０^６．２サイクルに固定された場合に、再コンパイルされたアプリケーションによって要求されるエネルギー消費が様々な値のＳ（スリープの持続時間）についてどのように変化したかを図示する。図７が示すように、最適な値のＳ（この場合は７００マイクロ秒であった）について、気候モデルは、完了のために３０８ジュールを要し、８２．３秒を費やした。対照的に、同じ気候モデルがテスト用のラップトップ構成上でスクリーンセーバとして実行された場合、これは２５．８秒で完了したが、７８２．７０４ジュールのエネルギーを要した。従って、再コンパイルされたアプリケーションを実行するために要するエネルギー消費は、同じアプリケーションをテスト用ラップトップコンピュータ上でスクリーンセーバとして実行するために要するエネルギーよりも２．５倍少なくされ得る。

上記の実験において、ＰＰＭシステムによって用いられる評価期間Ｐａの持続時間の明示的知識なしに様々な値のＴ及びＳが調査された。実際に、（テスト用のラップトップ構成におけるように）特にＬｉｎｕｘオペレーティングシステムが用いられる場合、評価期間Ｐａの持続時間は、動的に変更させることができる。本発明に係る技法がタスクの設計に適用されることにより、タスクがタスク自身をＰＰＭシステムからマスクできるようにする場合、Ｔ及びＳについて適当な値を設定するために、多数の異なるアプローチが用いられることができる。

１つのアプローチは、実験を前もって実行して、一般のＣＰＵ（又はＣＰＵファミリー）及びオペレーティングシステムの種々の組み合わせを用いて実行される場合に、どのＴ及びＳの値が対象タスクについて良好なエネルギー節約を提供するかを判定するソフトウェアプロバイダにある。関連する値は、例えばルックアップテーブル又はデータベースにおいてリストアップされることができ、タスクは書き込まれるか又は適合され、これにより、タスクを実行しようとしているＣＰＵ又はＣＰＵファミリー及びオペレーティングシステムについてリストアップされている値に、タスクはアクセスする。このアクセスは、値リストをタスク自体にハードコードすることによって直接的に、又は、特定のロケーション（これは、ＣＤＲＯＭ、ＲＡＭ、ＲＯＭ、光ディスク等の記憶媒体、又は、例えばインターネット、ＬＡＮ、若しくはＷＡＮを介してアクセスされるロケーションであり得る）からＳ及びＴの適当な値をフェッチするようにタスクを設計することによって間接的に提供されることができる。

リストから読み出したＳ及びＴの初期値を適合して、これらの値を最適化するようにタスクが設計されることは有利である。これは、例えば、ＣＰＵ周波数といったヒューリスティクスを用いて、リストから読み出された初期のＳ及びＴの値への適当な調整を判定するようにタスクを設計することによって達成されることができる。別の技法は、読み出された初期の値から始めてＳ及びＴの最適な値を判定する小さなベンチマーク処理を実行することができるように、タスクを設計することにある。

実際に、Ｓの値を、おおよそ５００マイクロ秒（Ｌｉｎｕｘオペレーティングシステムが用いられる場合）又は１０００マイクロ秒（Ｗｉｎｄｏｗｓ^ＴＭオペレーティングシステムが用いられる場合）に設定し、Ｔの値を微調整することによって、多くの場合に良好な結果を達成することができることが分かった。

本発明の第１の好適な実施形態の変更例において、例えば、タスクがより緊急になる場合に（達成されることができるエネルギー節約を制限することを代償にして）タスクの完了を加速するために、プロセッサによるタスクの実行中に、タスクが動的な手法でＳ及びＴの値を調整するようにタスクを設計することは有利であることが分かった。これは、計算の完了を実現する期限が存在するアプリケーションにおいて特に有益である。

例えば、幾つかのボランティア計算アプリケーションにおいて、ボランティアに供給されるデータの各ブロックに関連付けられる期限が存在し、当該期限が終了する前に、処理されたデータがサーバに返されることが必要である。本発明の第１の実施形態の変更例がそのようなタイプのボランティア計算アプリケーションに適用される場合において、Ｔ及びＳの現在の値は関連するデータのブロックに関連付けられた期限よりも遅くに所与の計算の完了をもたらすであろうとタスクが判定するとき、タスクはＳ及びＴの値を調整して、当該タスクのより速い完了を実現することができる（非常に緊急な場合に、中断無しに計算が継続するように、Ｓの値はゼロに設定されることができる）。

この機能性は、任意の好都合な手法で達成され得る。例えば：
タスクの完了の期限がＤとして表され、当該タスクをＣＰＵ負荷１００％で完了するために費やされる時間がＴ_１００と示され、低電力モードにおけるＣＰＵを用いたタスクの実行を完了させるために要する時間がＴ_ｌｐと示され、所与の瞬間ｔにおいて完了されたタスクの割合がδ（ただし、０≦δ≦１）と示される場合、タスクは実行中の所定の時間に下記のテストを行うように構成され得る：
所定の瞬間ｔにおいて、低電力モードにおいて完了するまでの時間をチェックする（即ち、（１−δ）×Ｔ_ｌｐの値を判定する）；
低電力モードにおいて計算を完了するために充分な時間が残されているか否かを判定するために、安全マージンΔＴを持たせて、低電力モードにおける完了までの時間［即ち、（１−δ）×Ｔ_ｌｐ］を、期限前に利用可能な残りの時間と比較し、即ち、（Ｄ−ｔ）と比較する；また、
[｛（１−δ）×Ｔ_ｌｐ｝＋ΔＴ]＜（Ｄ−ｔ）の場合、（ＣＰＵ負荷を１００％まで上昇させ、エネルギー節約を終わらせそうであっても）Ｓをゼロに設定し、即ち、それ以後はタスクを連続的に実行する。

タスクが実際に実行される場合に、一連のアクティブ期間の合間に介在するであろうインターバルＳの持続時間がタスクによって設定される値に一致することを保証することはしばしば不可能である。これは、タスクが特定の持続時間のスリープを要求し得るが、システムは当該タスクを幾らか長い期間についてスリープにし得るためである。ただし、これは低パフォーマンスプロセッサ状態の維持を阻止しないであろう。

エネルギーを節約するためにタスクがＰＰＭシステムからマスクされることができる本発明の一般原理は、様々な手法において実装されることができ、そのうちの幾つかは特定のＰＰＭシステム及びアルゴリズムに固有の特徴を利用する。

例えば、国際公開第２００７／１０３０５１号は、ＣＰＵ負荷に基づくだけでなく、実行されているタスクのメモリバウンドな程度を定量化するパラメータも考慮して、プロセッサのパフォーマンス状態が選択されるＰＰＭシステムを提案する。別の例において、米国特許出願公開第２００９／００８９５９８号明細書は、ＣＰＵ負荷だけでなく、少なくとも部分的にはプロセッサがいつストールされるかのアセスメントに基づいて、プロセッサパフォーマンス状態が選択されるＰＰＭシステムを提案する。これらのＰＰＭシステムによれば、タスクがメモリバウンドであると考えられる場合、又は、タスクの実行中にプロセッサがストールされると考えられる場合、より低いパフォーマンス状態がＣＰＵについて選択される。本発明の第２の実施形態は、タスクがこれらのタイプのＰＰＭシステムからタスク自体をマスクすることを可能にする。これは、タスクのコードにダミー命令を挿入し、これらのＰＰＭシステムのフィードバックメカニズムを欺くことによって達成される。

任意の好都合なダミー命令がタスクのコードに挿入され、上記のタイプのＰＰＭシステムのフィードバックメカニズムがタスクをメモリバウンドであると推論するように欺き得る。適切なダミー命令の１つの例は、ランダムな（ただし、有効な）メモリロケーションからＣＰＵレジスタにデータをロードするようにＣＰＵに要求し、このデータロード作業について如何なる計算の必要も存在しない命令にある。要求されるデータをＣＰＵがレジスタにロードしている間、ＣＰＵは実際にはタスクを進展させていないため、タスクが短期間休止していると考えることができる。メモリから読み出されるデータの量が大きいほど、このごくわずかなスリープの持続時間は長くなる。従って、ロードされるべきデータの量は、ごくわずかなスリープ期間Ｓの持続時間を制御する。

本発明の第２の実施形態において、タスクの命令フローを変更することは、オペレーティングシステムからの如何なるサポートも要しない。従って、第１の実施形態と同様に、エネルギー節約は、オペレーティングシステムのレベルにおいて取られる動作というよりも、タスクのレベルにおける動作によって達成されることができる。

本発明の第２の実施形態において、アクティブ期間Ｔ及びスリープインターバルＳの持続時間を設定する場合に第１の実施形態の場合と同じ考察が適用されるので、簡潔にするため、これらの特徴はここでは繰り返さない。

本発明の上記第１及び第２の実施形態においては、計算集約的なタスクがバックグラウンドにおいて実行されている場合でも、この特定のタスクがＣＰＵに課す平均的なＣＰＵ負荷を低減することによってＣＰＵの低電力／低パフォーマンス状態を維持することができると仮定される。しかしながら、バックグラウンドタスクによって課される低減されたＣＰＵ負荷は、同時に実行されている他のタスク（例えば、ユーザが従事するフォアグラウンドタスク）によって課されている任意のＣＰＵ負荷に付加される。このような他のタスクがＣＰＵ負荷１００％を課す（exert）場合、バックグラウンドタスクは如何なる余分なエネルギーの使用も生じさせていない。他方、このような他のタスクが当該タスクだけでは高パフォーマンスなＣＰＵ状態の使用をトリガするために充分なＣＰＵ負荷を課さないが、バックグラウンドタスクの重畳によりＰＰＭシステムが高パフォーマンス状態を選択することをトリガする状況があり得る。この状況が当てはまるのは、バックグラウンドタスクが実行されている全期間を通じて極めてまれであり、従って、本発明の第１及び第２の実施形態は有益なエネルギー節約をもたらすであろうことが理解されるであろう。ただし、本発明の第３の実施形態は、この状況が回避されることを可能にする。

本発明の第３の実施形態によれば、第１及び第２の実施形態に関連して上述された方法のうちのいずれかを用いて、短いアクティブ期間において、その合間にごくわずかなスリープインターバルを有した状態で実行するようにタスクは構成される。また、他のタスクによって課される負荷に加えて現在のタスクに起因する負荷によって課される全負荷が、ＰＰＭシステムの評価期間Ｐａの間、１００％未満のままであるように、平均的なＣＰＵ負荷のアセスメントに基づいてＳ及びＴの値を適応的に変更するように、タスクはさらに構成される。これは、平均的なＣＰＵ負荷と、所与のＰステートにおいてプロセッサが費やす時間とに関する情報についてオペレーティングシステムに問い合わせるようにタスクを構成することによって達成されることができる。

概して、本発明の第１、第２及び第３の実施形態に係る発明は、最初からプログラムコードの一部を形成し、又はタスクの旧バージョンのコンパイルの結果、コードの一部を形成する命令によって、タスクがタスク自体をＰＰＭシステムからマスクするように、上記で議論された原理に従って設計されたタスク（ユーザアプリケーション、システムレベルサービス、デーモン等）を表す表現をプログラムコードにおいて発見するであろう。典型的には、このプログラムコードは、好都合な物理的な媒体（例えば、ＣＤＲＯＭ、ＲＡＭ、ＲＯＭ、光ディスク、テープ、又は他の記憶媒体）に記録される特別に適合されたプログラムコードを含む、コンピュータプログラムプロダクトとして具現化されるであろう。プログラムコードは、ネットワーク（例えば、ＬＡＮ、ＷＡＮ、インターネット等）を介してブロードキャストされ又は送信されてもよい。

しかしながら、本発明の第４の実施形態によれば、選択されるタスクは、タスク自体の外部にあるが、選択されるタスクが実行される場合にこれらのタスクにマイクロスリープを導入することによって、選択されるタスクをＰＰＭシステムからマスクするように動作するディレクタアプリケーションによってＰＰＭシステムからマスクされることができる。このディレクタアプリケーションは、オペレーティングシステムの一部を形成せず、例えば、記憶媒体からインストールされ、インターネットからダウンロードされる等のアドオンである。ディレクタアプリケーションは、明らかな不適合が生じる場合を除き、上述された第１から第３の実施形態の種々の特徴を実装することができることが理解されるべきである。

本発明は、本発明の幾つかの目下好適な実施形態に関して上述された。添付の特許請求の範囲において定義されるような本発明の範囲内における好適な実施形態において変更例及び発展形が為され得ることを当業者は容易に理解するであろう。

本発明は、ユーザアプリケーションをＰＰＭシステムからマスクする実施形態に関連して上述された。しかしながら、同じ技法は、ユーザアプリケーション以外のプロセス、特に（印刷、ファイル共有、データベースサービス等を含む）システムレベルサービス、Ｕｎｉｘのデーモン、及び他のマルチタスキングオペレーティングシステムを、ＰＰＭシステムからマスクするために適用されることができる。

本発明は、ボランティアコンピューティングアプリケーションのエネルギー効率を改善することに特に関連して上述された。しかしながら、本発明は、計算集約的であるが必ずしも緊急ではない他のタスク（例えば、フラクタルのレンダリング、編集後のビデオデータの圧縮、ビデオ及びオーディオのコーディング及びデコーディング、並びにその他多数）により広く適用可能である。

本発明の種々の実施形態は、付加的な機能性を提供する補助モジュールに関連して用いられることができる。例えば、幾つかの場合に、本発明の第１から第４の実施形態の技法を用いてＰＰＭシステムからマスクされるタスクとやりとりするために、ユーザインタフェースが提供され得る。このユーザインタフェースは、ユーザがマスキング処理の種々のパラメータ、特に下記の１つ以上を制御することを可能にする：アクティブ期間Ｔの持続時間及び／又はごくわずかなスリープインターバルＳについて設定される値、Ｓ及びＴについて適当な（初期の）値を取得するためにタスクがアクセスすべきソース、タスクの実行の完了のために費やされる時間、並びに、タスクの実行のために要する時間に比較したエネルギー節約の相対的重要度。ユーザインタフェースは、タスクが実行されるＣＰＵ及び／又はオペレーティングシステムの詳細（例えば、ＣＰＵ及びオペレーティングシステムを識別すること、ＣＰＵクロック周波数を特定すること等）をタスク／マスキング処理にユーザが手動で通知することを可能にし得る。

Claims (12)

1. 評価期間Ｐａの間のプロセッサ負荷のアセスメントを考慮してパフォーマンス状態を選択するプロセッサパフォーマンスマネジメント（ＰＰＭ）システムによってプロセッサのパフォーマンス状態が制御されている間に、バックグラウンドにおいてタスクを実行する場合に、当該プロセッサによって消費されるエネルギーを低減する方法であって、当該エネルギー低減方法は：
   （ａ）アクティブ期間（Ｔ）の間に前記プロセッサに前記タスクの一部を実行させるステップと、
   （ｂ）各アクティブ期間の後、インターバル（Ｓ）について、前記プロセッサに前記タスクを実行することを停止させるステップと、
   （ｃ）前記タスクが完了されるまで、ステップ（ａ）及びステップ（ｂ）を繰り返し実行するステップと、
   を含み、
   前記タスクの実行の開始と終了との間の前記ＰＰＭシステムの各評価期間（Ｐａ）の間に、１００％未満であるが０％よりも大きい平均的な負荷を前記タスクの実行が前記プロセッサに課すように、前記評価期間（Ｐａ）の持続時間よりも短い、前記アクティブ期間（Ｔ）及び前記インターバル（Ｓ）の持続期間が選択される、
   エネルギー消費低減方法。
2. ステップ（ｂ）は、前記タスクの命令シーケンスが１つ以上の如何なる計算の必要も存在しない命令であるダミー命令を含むように設定し、前記インターバル（Ｓ）の間に前記プロセッサに当該ダミー命令の１つ以上を実行させることを含む、請求項１に記載のエネルギー消費低減方法。
3. ステップ（ｂ）は、前記インターバル（Ｓ）について、前記タスクによる前記プロセッサへの負荷を０％にすることを含む、請求項１に記載のエネルギー消費低減方法。
4. 実行中に、現在の実行期間の間に経過した時間のチェックが為され、所定の期間（Ｔ）が経過した場合には前記インターバル（Ｓ）について前記タスクによる前記プロセッサへの負荷を０％にするように要求が為されるように、前記タスクは構成される、請求項１に記載のエネルギー消費低減方法。
5. 前記タスクは、前記タスクがファンクションコールを呼び出す度に、前記経過した時間のチェックが為されるように構成される、請求項４に記載のエネルギー消費低減方法。
6. 前記プロセッサに依存する前記アクティブ期間（Ｔ）及び前記インターバル（Ｓ）のうちの少なくとも１つの前記持続期間を設定するステップ、を含み、
   前記タスクを実行するためにオペレーティングシステムが用いられる、
   請求項１に記載のエネルギー消費低減方法。
7. 前記アクティブ期間（Ｔ）及び前記インターバル（Ｓ）のうちの少なくとも１つの前記持続期間は、前記タスクの実行の前記開始と前記終了との間に変化する、請求項１に記載のエネルギー消費低減方法。
8. コンピュータ使用可能な媒体上に記憶され、プロセッサ（ＣＰＵ）によって実装されるように適合されるタスクを表すソフトウェアコードを含むプログラムであって、
   前記プロセッサのパフォーマンス状態は、評価期間（Ｐａ）の間のプロセッサ負荷のアセスメントを考慮して前記プロセッサについてのパフォーマンス状態を選択するプロセッサパフォーマンスマネジメント（ＰＰＭ）システムによって制御され、
   前記タスクは、前記プロセッサを用いて当該プログラムが実行される場合に、それぞれのアクティブ期間（Ｔ）の間に前記タスクの一部が前記ＣＰＵによって実行され、前記アクティブ期間の合間に前記プロセッサが前記タスクを実行することを停止するインターバル（Ｓ）が設けられるように適合されるプログラムコードを含み、
   前記評価期間（Ｐａ）の持続時間よりも短い、前記アクティブ期間（Ｔ）及び前記インターバル（Ｓ）の持続時間が、前記評価期間（Ｐａ）の間に、前記タスクの実行が１００％未満であるが０％よりも大きい平均的な負荷を前記プロセッサに課すように、前記プログラムコードは適合される、
   プログラム。
9. プロセッサを備え、評価期間（Ｐａ）の間のプロセッサ負荷のアセスメントを考慮してプロセッサパフォーマンス状態を選択するプロセッサパフォーマンスマネジメント（ＰＰＭ）を実装するように構成されるコンピューティング装置であって、
   前記コンピューティング装置は、評価期間選択されるタスクの一部を評価期間（Ｐａ）の間に繰り返し実行し、各アクティブ期間の後、インターバル（Ｓ）について前記選択されるタスクを実行することを停止することによって、前記選択されるタスクを実行するように構成され、
   前記選択されるタスクの実行の開始と終了との間の各評価期間（Ｐａ）の間の前記ＰＰＭシステムの各評価期間（Ｐａ）の間に、前記選択されるタスクの前記実行が、１００％未満であるが０％よりも大きい平均的な負荷を前記プロセッサに課すように、前記評価期間（Ｐａ）の持続時間よりも短い、前記アクティブ期間（Ｔ）及び前記インターバル（Ｓ）の持続時間が設定される、
   コンピューティング装置。
10. プロセッサ上で実行されるべき第一のタスクを表す第一のプログラムコードを再コンパイルするように適合されるコンパイラであって、
    プロセッサパフォーマンス状態は、評価期間（Ｐａ）の間のプロセッサ負荷を考慮して当該パフォーマンス状態を選択するプロセッサパフォーマンスマネジメントシステムによって制御され、
    前記コンパイラは、前記プロセッサ上で実行される場合に、前記第一のプログラムコードを再コンパイルし、それにより、第二のタスクを表す第二のプログラムコードが取得され、
    前記第二のタスクは、
    （ａ）アクティブ期間（Ｔ）について前記第一のタスクが実行されるステップと；
    （ｂ）各アクティブ期間（Ｔ）の後、インターバル（Ｓ）について実行を停止するステップと；
    （ｃ）前記第一のタスクの実行が完了するまで、ステップ（ａ）及びステップ（ｂ）を繰り返すステップと；
    を実行するように構成され、
    前記第二のプログラムコードは、前記第一のタスクの実行の開始と終了との間の前記ＰＰＭシステムの各評価期間（Ｐａ）の持続時間よりも短い、前記アクティブ期間（Ｔ）及びインターバル（Ｓ）の持続時間により、前記各評価期間（Ｐａ）の間に、前記第一のタスクの実行が、１００％未満であるが０％よりも大きい平均的な負荷を前記プロセッサに課すように適合される、
    コンパイラ。
11. 前記コンパイラは、前記第一のプログラムコードを再コンパイルし、それにより、前記第二のタスクを表す第二のプログラムコードが取得され、前記第二のタスクが前記プロセッサ上で実行される場合に、
    前記第一のタスクがファンクションコールを呼び出す度に、経過したクロックサイクルを確認するステップと、
    前記アクティブ期間（Ｔ）について前記第二のタスクが前記プロセッサ上でアクティブであったことを当該確認するステップが示す場合、前記インターバル（Ｓ）について前記第一のタスクによる前記プロセッサへの負荷を０％にするステップと、
    を実行するように構成される、請求項１０に記載のコンパイラ。
12. コンピュータ使用可能な媒体上に記憶され、プロセッサを備えるコンピューティング装置上で実行される場合に、当該プロセッサによるタスクの実行を制御するように適合されるソフトウェアコードを含むプログラムであって、
    前記プロセッサのパフォーマンス状態は、評価期間（Ｐａ）の間のプロセッサ負荷を考慮してプロセッサパフォーマンス状態を選択するプロセッサパフォーマンスマネジメントシステムによって制御され、
    前記ソフトウェアコードは、前記プロセッサに、
    （ａ）アクティブ期間（Ｔ）について前記タスクを実行するステップと；
    （ｂ）各アクティブ期間（Ｔ）の後、インターバル（Ｓ）について前記タスクを実行することを停止するステップと；
    （ｃ）前記タスクの実行が完了するまで、ステップ（ａ）及びステップ（ｂ）を繰り返すステップと；
    を実行させるように適合され、
    前記タスクの実行の開始と終了との間の前記ＰＰＭシステムの評価期間（Ｐａ）の持続時間よりも短い、前記アクティブ期間（Ｔ）及びインターバル（Ｓ）の持続時間により、前記各評価期間（Ｐａ）の間に、前記タスクの実行が、１００％未満であるが０％よりも大きい平均的な負荷を前記プロセッサに課す、
    プログラム。

Images