(57)【要約】【課題】複数の処理タスクを実行する際に、プロセッサの利用履歴からプロセッサの目標プロセッサ実行レベルを計算する方法、コンピュータ・プログラム・プロダクト及び装置を提供する。【解決手段】所定のタスク時間間隔内で与えられた処理タスクを実行する際にプロセッサ利用を表示するタスク・ワーク値を計算し、タスク・ワーク値に従って異なる目標プロセッサ実行レベルを計算する。所定のタスク時間間隔は、複数の処理タスクのそれぞれについて独立して設定され、与えられた処理タスクの第１のスケジュールの開始から処理タスクの次のスケジュールの開始までの期間である。【選択図】図１
2004164643.tif 000002
【特許請求の範囲】
【請求項１】
複数の処理タスクを実行する際にプロセッサの利用履歴から、前記プロセッサの目標プロセッサ実行レベルを計算する方法において、
所定のタスク時間間隔内で与えられた処理タスクを実行する際にプロセッサ利用を表示するタスク・ワーク値を計算するステップと、
前記タスク・ワーク値に従って異なる前記目標プロセッサ実行レベルを計算するステップと、
を含む前記方法。
【請求項２】
前記与えられた処理タスクのそれぞれ複数の前回実行に対応して複数のタスク・ワーク値を計算すること及び前記複数のタスク・ワーク値を組み合わせて前記与えられた処理タスクの将来実行のために前記目標プロセッサ実行レベルを計算することを含む請求項１記載の方法。
【請求項３】
前記所定のタスク時間間隔は、前記複数の処理タスクのそれぞれについて独立して設定される請求項２記載の方法。
【請求項４】
前記所定のタスク時間間隔は、前記与えられた処理タスクの各実行について独立して設定される請求項３記載の方法。
【請求項５】
前記所定のタスク時間間隔は、前記与えられた処理タスクの第１のスケジュールの開始から前記処理タスクの次のスケジュールの開始までの期間であり、前記所定のタスク時間間隔は、前記第１のスケジュールに関連している請求項４記載の方法。
【請求項６】
前記与えられた処理タスクの前回実行に対応する前記複数のタスク・ワーク値は、前記与えられた処理タスクのために指数関数的に減衰する平均ワーク・ダン値を計算するように組み合わされる請求項２記載の方法。
【請求項７】
前記所定のタスク時間間隔内でアイドル時間長値を検出すること及び前記タスク・ワーク値と前記アイドル時間長に従って前記与えられた処理タスクについてのタスク実行デッド・ラインを計算することを含む請求項１記載の方法。
【請求項８】
前記タスク実行デッド・ラインは、前記与えられた処理タスクの複数の前回の実行のそれぞれについて計算され、かつ、複数のタスク実行デッド・ラインは、組み合わされて指数関数的に減衰する平均タスク実行デッド・ライン値を計算する請求項７記載の方法。
【請求項９】
前記与えられた処理タスクに対する前記目標プロセッサ実行レベルは、前記指数関数的に減衰する平均ワーク・ダン値及び前記与えられた処理タスクに対応する指数関数的に減衰する平均タスク実行デッド・ライン値に従って計算される請求項７記載の方法。
【請求項１０】
前記与えられた処理タスクの処理中に少なくとも１回の中断された実行期間を検出するステップであって、前記少なくとも１回の中断された実行期間は、前記第１のタスクの完了前に処理を前記与えられた処理タスクから、更に異なる処理タスクへ切り換えられる期間を表すステップと、
前記少なくとも１回の中断された実行期間中にプロセッサ利用を含むように前記与えられた処理タスクのための前記タスク・ワーク値を計算するステップと、
を含む請求項１記載の方法。
【請求項１１】
前記与えられた処理タスクが前記上側しきい値より大又は等しい期間に前記中断された実行期間を検出することなく、前記与えられた処理タスクが実行し続けたとき、前記タスクに対する前記目標プロセッサ実行レベルを自動的に再計算するように、前記所定のタスク時間間隔に対する前記上側しきい値を設定することを含む請求項１０記載の方法。
【請求項１２】
各タスクについてフラグ値を記憶すると共に、前記フラグ値は、対応するタスクが実行し始めて実行を未だ完了していないときを示す請求項１記載の方法。
【請求項１３】
前記与えられた処理タスクのそれぞれの前回の実行についての各タスク・ワーク値は、前記タスク・ワーク値を組み合わせて前記タスクの前記将来実行に対する前記目標プロセッサ実行レベルを計算するときに、対応する所定のタスク時間間隔により正規化される請求項２記載の方法。
【請求項１４】
コンピュータを制御して複数の処理タスクを実行する際にプロセッサの利用履歴から、前記プロセッサの目標プロセッサ実行レベルを計算するコンピュータ・プログラムを搭載したコンピュータ・プログラム・プロダクトにおいて、
所定のタスク時間間隔内で与えられた処理タスクを実行する際にプロセッサ利用を表示するタスク・ワーク値を計算するように動作可能なタスク・ワーク値計算コードと、
前記タスク・ワーク値に従って異なる前記目標プロセッサ実行レベルを計算するように動作可能な目標プロセッサ計算コードと、
を含む前記コンピュータ・プログラム。
【請求項１５】
前記タスク・ワーク計算コードは、前記与えられた処理タスクのそれぞれ複数の前回の実行に対応して複数のタスク・ワーク値を計算し、かつ、前記複数のタスク・ワーク値を組み合わせて前記与えられた処理タスクの将来実行のために前記目標プロセッサ実行レベルを計算することを含む請求項１４記載のコンピュータ・プログラム・プロダクト。
【請求項１６】
前記所定のタスク時間間隔は、前記複数の処理タスクのそれぞれについて独立して設定される請求項１５記載のコンピュータ・プログラム・プロダクト。
【請求項１７】
前記所定のタスク時間間隔は、前記与えられた処理タスクの各実行について独立して設定される請求項１６記載のコンピュータ・プログラム・プロダクト。
【請求項１８】
前記所定のタスク時間間隔は、前記与えられた処理タスクの第１のスケジュールの開始から前記処理タスクの次のスケジュールの開始までの期間であり、前記所定のタスク時間間隔は、前記第１のスケジュールに関連している請求項１７記載のコンピュータ・プログラム・プロダクト。
【請求項１９】
前記与えられた処理タスクの前回の実行に対応する前記複数のタスク・ワーク値は、前記与えられた処理タスクのために指数関数的に減衰する平均ワーク・ダン値を計算するように組み合わされる請求項１５記載のコンピュータ・プログラム・プロダクト。
【請求項２０】
前記所定のタスク時間間隔内でアイドル時間長値を検出すること及び前記タスク・ワーク値と前記アイドル時間長に従って前記与えられた処理タスクについてのタスク実行デッドラインを計算することに動作可能な検出コードを含む請求項１４記載のコンピュータ・プログラム・プロダクト。
【請求項２１】
前記タスク実行デッド・ラインは、前記与えられた処理タスクの複数の前回の実行のそれぞれについて計算され、複数のタスク実行デッド・ラインは、組み合わされて指数関数的に減衰する平均タスク実行デッド・ライン値を計算する請求項２０記載のコンピュータ・プログラム・プロダクト。
【請求項２２】
前記与えられた処理タスクに対する前記目標プロセッサ実行レベルは、前記指数関数的に減衰する平均ワーク・ダン値及び前記与えられた処理タスクに対応する指数関数的に減衰する平均タスク実行デッド・ライン値に従って計算される請求項２０記載のコンピュータ・プログラム・プロダクト。
【請求項２３】
前記与えられた処理タスクの処理中に少なくとも１回の中断された実行期間を検出するように動作可能な実行中断期間検出コードであって、前記少なくとも１回の中断された実行期間は、前記第１のタスクの完了前に処理を前記与えられた処理タスクから更に異なる処理タスクへ切り換えられる期間を表す前記実行中断期間検出コードを更に含み、
前記タスク・ワーク値計算コードは、前記少なくとも１回の中断された実行期間中にプロセッサ利用を含むように、前記与えられた処理タスクについて前記タスク・ワーク値を計算するように動作可能である請求項１４記載のコンピュータ・プログラム・プロダクト。
【請求項２４】
前記与えられた処理タスクが前記上側しきい値より大又は等しい期間に前記中断された実行期間を検出することなく実行し続けたとき、前記タスクに対する前記目標プロセッサ実行レベルを自動的に減少させるように、前記所定のタスク時間間隔に対する上側しきい値を設定する請求項２３記載のコンピュータ・プログラム・プロダクト。
【請求項２５】
各タスクについてフラグ値を記憶すると共に、前記フラグ値は、対応するタスクが実行し始めて実行を未だ完了していないかを示す請求項１４記載のコンピュータ・プログラム・プロダクト。
【請求項２６】
前記与えられた処理タスクのそれぞれの前回の実行についての各タスク・ワーク値は、前記タスク・ワーク値を組み合わせて前記タスクの前記将来実行に対する前記目標プロセッサ実行レベルを計算するとき、対応する所定のタスク時間間隔により正規化される請求項１５記載のコンピュータ・プログラム・プロダクト。
【請求項２７】
複数の処理タスクを実行する際にプロセッサの利用履歴からプロセッサの目標プロセッサ実行レベルを計算する装置において、
所定のタスク時間間隔内で与えられた処理タスクを実行する際にプロセッサ利用を表示するタスク・ワーク値を計算するように動作可能なタスク・ワーク値計算ロジックと、
前記タスク・ワーク値に従って異なる前記目標プロセッサ実行レベルを計算するように動作可能な目標プロセッサ計算ロジックと、
を含む前記装置。
【請求項２８】
前記タスク・ワーク計算ロジックは、前記与えられた処理タスクのそれぞれ複数の前回の実行に対応して複数のタスク・ワーク値を計算し、前記複数のタスク・ワーク値を組み合わせて前記与えられた処理タスクの将来の実行のために前記目標プロセッサ実行レベルを計算する請求項２７記載の装置。
【請求項２９】
前記所定の時間間隔は、前記複数の処理タスクのそれぞれについて独立して設定される請求項２８記載の装置。
【請求項３０】
前記所定のタスク時間間隔は、前記与えられた処理タスクの各実行について独立して設定される請求項２９記載の装置。
【請求項３１】
前記所定のタスク時間間隔は、前記与えられた処理タスクの第１のスケジュールの開始から前記処理タスクの次のスケジュールの開始までの期間であり、前記所定のタスク時間間隔は、前記第１のスケジュールに関連している請求項３０記載の装置。
【請求項３２】
前記与えられた処理タスクの前回の実行に対応する前記複数のタスク・ワーク値は、前記与えられた処理タスクのために指数関数的に減衰する平均ワーク・ダン値を計算するように組み合わされる請求項２８記載の装置。
【請求項３３】
前記所定のタスク時間間隔内でアイドル時間長値を検出すること及び前記タスク・ワーク値と前記アイドル時間長に従って前記与えられた処理タスクについてのタスク実行デッド・ラインを計算することを含む請求項２８記載の装置。
【請求項３４】
前記タスク実行デッド・ラインは、前記与えられた処理タスクの複数の前回の実行のそれぞれについて計算され、複数のタスク実行デッド・ラインは、組み合わされて指数関数的に減衰する平均タスク実行デッド・ライン値を計算する請求項３３記載の装置。
【請求項３５】
前記与えられた処理タスクに対する前記目標プロセッサ実行レベルは、前記指数関数的に減衰する平均ワーク・ダン値及び前記与えられた処理タスクに対応する指数関数的に減衰する平均タスク実行デッド・ライン値に従って計算される請求項３３記載の装置。
【請求項３６】
前記与えられた処理タスクの処理中に少なくとも１回の中断された実行期間を検出するように動作可能な実行中断期間検出ロジックであって、前記少なくとも１回の中断された実行期間は、前記第１のタスクの完了前に処理を前記与えられた処理タスクから、更に異なる処理タスクに切り換えられる期間を表す実行中断期間検出ロジックを更に含み、
前記少なくとも１回の中断された実行期間中にプロセッサ利用を含むように前記与えられた処理タスクのための前記タスク・ワーク値を計算する動作が可能である請求項２８記載の装置。
【請求項３７】
前記与えられた処理タスクが前記上側しきい値より大又は等しい期間に前記中断された実行期間を検出することなく実行し続けたとき、前記タスクに対する前記目標プロセッサ実行レベルを自動的に再計算するように、前記所定のタスク時間間隔に対する前記上側しきい値を設定する請求項３６記載の装置。
【請求項３８】
各タスクについてフラグ値を記憶すると共に、前記フラグ値は、対応するタスクが実行し始めて実行を未だ完了していないかを示す請求項２８記載の装置。
【請求項３９】
前記与えられた処理タスクのそれぞれの前回の実行についての各タスク・ワーク値は、前記タスク・ワーク値を組み合わせて前記タスクの前記将来の実行に対する前記目標プロセッサ実行レベルを計算するとき、対応する所定のタスク時間間隔により正規化される請求項２８記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理システムに関する。特に、本発明は、プロセッサを異なる複数のプロセッサ実行レベルに設定可能にするデータ処理システムにおける実行レベル設定に関する。
【背景技術】
【０００２】
プロセッサ設計の重要な目的は、改良された性能を提供することであり、かつ電力消費を減少させることである。最近のいくつかのプロセッサは、その時点でプログラム・アプリケーション（複数）の必要条件に従って、異なる多数のプロセッサ実行レベルのうちの１レベルにプロセッサを設定する能力を提供している。このようなプロセッサは、プロセッサのクロック周波数及び対応する動作電圧を低下させることにより、エネルギ消費において二次式的な減少を潜在的に発生し得るという利点がある。しかしながら、プロセッサ性能の低下は、ユーザに認知される性能に影響がないか又は殆どないときにのみ受け入れられる。従って、プロセッサ実行レベルにおける低下は、ソフトウェアがその実行デッドラインを下回る結果になってはならないことが重要である。そのデッド・ライン以前に与えられた処理タスクを完了し、次いでアイドリングということは、もっとゆっくりタスクをランさせることよりエネルギ効率が悪く、従って、そのデッド・ラインをもっと正確に合わせることを保証することである。
【０００３】
既知の実行レベル設定技術は、いわゆる間隔ベース・アルゴリズムを含み、その主要な考えは、ワイザー他による「ＣＰＵエネルギを低下させるためのスケジュール（Scheduling for Reduced CPU Energy）」、１９９４年１１月、オペレーティング・システム設計及び実施の第１シンポジウム報告（Proceeding of First Symposium of Operating systems Design and Implementation）に説明されている。このような既知の間隔ベース・アルゴリズムは、プロセッサ利用歴を監視して、固定した短い（１０〜５０ミリ秒）時間ウィンドウ内でアイドル時間対ビジー時間の比を計算することにより、適当な実行レベルの標識を導き出す。典型的には、最近の時間間隔内でグローバル・プロセッサ利用を計算し、これがあるしきい値より高いのであれば、プロセッサ実行レベルを高くし、一方、時間間隔が殆どアイドル時間になっているのであれば、実行レベルを低下させている。このような既知の技術は、規則的なワーク・ロードに対しては合理的にうまく働くが、不規則な（即ち、周期的でない）ワーク・ロードに対して及びインタラクティブ・アプリケーションに対しては、うまく行っていない。他の既知技術は、将来利用に対するガイドとしてプロセッサのグローバル利用の重み付け平均を使用する。しかしながら、これは、プロセッサ利用を大幅に改善し、かつアイドル時間を減少させることになるクロック速度を得るものではないことが示された。（グルンワルト（Grunwald）他による「ダイナミック・クロック計画のための方策（Policies for Dynamic Clock Schedulingを参照）、２０００年１０月、オペレーティング・システム設計及び実施の第４シンポジウム報告（Proceeding of the Fourth Symposium of Operating systems Design and Implementationを参照）に示された。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従って、例えば、不規則なワーク・ロード及びインタラクティブ・ワーク・ロードを含め、種々の範囲のワーク・ロードのために適当なプロセッサ実行レベルを正確に予測可能な実行レベル設定技術に対する必要性が存在する。
【課題を解決するための手段】
【０００５】
本発明は、複数の処理タスクを実行する際にプロセッサの利用履歴から目標プロセッサ実行レベルを計算する方法において、この方法は、
対応するタスク時間間隔内で与えられた処理タスクを実行する際にプロセッサ利用を表示するタスク・ワーク値を計算すること、
タスク・ワーク値に従って異なる目標プロセッサ実行レベルを計算することと、
を備えている。
【０００６】
本発明は、全てのタスクが不明瞭とされる恐れがあり、実行レベルを割り付けるときに競合が観察されるタスク・レベルで、個々の処理タスク（即ち、複数グループの処理タスク）は、しばしば識別可能な利用期間を有していることを認識することである。タスク・レベルにあるプロセッサ利用に注目すると、処理タスクの送出及びこれらに関連して必要とする実行レベルは、実行設定ポリシによって、更によく適合させることが可能とされる。本発明は、グローバル・ワーク・ロードにより指定される任意量によって、プロセッサ実行レベルを間接的に上下に設定するよりも、各処理タスクについて直接的な実行レベルを予測可能にする。
【０００７】
前回の単一時間ウィンドウに対するタスク・ワーク値は、その処理タスクに対する適当な将来実行レベルを予測するために使用可能とされる。しかしながら、好ましい実施例は、将来の実行レベルを予測するために、同一処理タスクの前回の複数実行に対応するタスク・ワーク値を組み合わせる。これは、特定のタスクに関して統計的により正確な実行レベル予測を提供する効果がある。
【０００８】
タスク時間間隔は、各処理タスクの各実行に対して固定値が設定されてもよいことを理解すべきである。しかしながら、実行予測システムは、各処理タスクに対してタスク時間間隔を独立して設定することにより、異なるワーク・ロード形式に対してより適応可能にされる。特に、インタラクティブ処理タスクに対しては、短い期間が適当と云えるのに対し、非インタラクティブ・タスクに対しては、比較的に長い期間がより適していると思われる。適当でない短い時間間隔を選択したときは、複数の実行レベル間で発振を発生させる恐れがある。各処理タスクに対して、タスク時間間隔を独立して設定可能にすると、安定な実行予測を確定する可能性を高くする。更に、与えられたタスクの各実行に対して独立して期間を設定すると、実行予測は、実行時点でワーク・ロードの部分を形成している他のタスクを考慮して、適応可能とされる。これらの共存する他のタスクは、タスク優先使用により与えられたタスク用の総実行時間に影響を与える恐れがある。
【０００９】
このタスク時間間隔は、その範囲内のどこかに与えられた処理タスクの実行を含む限り、柔軟性をもって定義されてもよい。しかしながら、好ましい実施例は、タスク時間間隔について、与えられた処理タスクの最初のスケジュールが開始し、かつ与えられた処理タスクの次の実行前に終了するときは、開始するように定義している。これは、実施するのが簡単であるという利点があり、かつタスク時間間隔が与えられた処理タスクの実行周波数と相関される。これは、この技術を周期的でない処理タスクに対して、より適当かつ適応可能な技術にする。
【００１０】
与えられた処理タスクの前回の複数実行に対するタスク・ワーク値は、異なる多数の方法により組み合わせられて、そのタスクに対する将来実行レベルを予測してもよく、例えば、タスク・ワーク値の平均又は重み付け平均が計算されてもよいことを理解すべきである。これは、最近計算されたタスク・ワーク値が平均に大きな影響を与えるのを可能にするので、タスク・ワークを組み合わせて指数関数的に減衰するワーク・ダン値を計算するために特に好都合である。
【００１１】
複数グループの関連タスクについて実行デッド・ラインを計算できるけれども、これは、プロセッサの実行を更に精密に同調可能にするので、タスク・ベースによる実行デッド・ラインを計算するのに好都合である。タスク・ワーク値及びタスク時間間隔内で検出されたアイドル時間は、タスク実行デッド・ラインを計算するために都合良く使用される。実行デッド・ラインは、タスク時間間隔中に優先する実行レベルを考慮して正規化可能とされるので、これは、タスクの前回実行を完了するために掛かったリアル・タイムを使用するよりも正確な予測が得られる。
【００１２】
タスク・ワーク値についての指数関数的な平均および与えられた処理タスク用の実行デッド・ラインのトラッキングを個別的に保持すると、タスク・ワーク値を測定した間隔長により、実行レベル予測を重み付けすることができるという利点がある。これは、最も長い時間間隔に関連したタスク・ワーク値が予測を支配するのを防止し、従って広範に変化するウィンドウ・サイズを補償する。
【００１３】
タスク・ワーク値は、対応するタスク時間ウィンドウ内に与えられた処理タスクの実行において、プロセッサ利用のみを含み得ることを理解すべきである。しかしながら、好ましい実施例は、与えられた処理タスクが他の異なる処理タスクによって優先使用されるときを検出し、かつワーク・ダン値に優先使用タスク（複数）のためのプロセッサの利用が含まれている。与えられたタスクの連続的な実行において、他の同一タスク（複数）が与えられたタスクに優先する可能性が高いことが期待される。タスク実行デッド・ライン及び実行レベル予測は、３優先使用タスクを考慮すべきであるということになる。
【００１４】
タスク時間ウィンドウは、与えられたタスクの実行時間及び実行周波数に従ってサイズの変更が許容されるが、上側しきい値は、タスク時間ウィンドウに対してセットされることが好ましい。これは、長いランの処理を防止することにより、適切でない実行レベルで実行し続ける優先使用をしないようにする利点がある。実行レベルの再計算は、タスク時間ウィンドウが上側しきい値に到達したときに開始される。
【００１５】
好ましい実施例において、実行レベルの設定方法は、オペレーティング・システムのカーネル内のソフトウェアに実施される。これは、ソフトウェアがより豊富な一組のラン・タイム情報に基づいて決定をすることができ、これが続いて精度の増加をもたらす。
【００１６】
更に他の特徴から見て、本発明は、複数の処理タスクを実行する際にプロセッサの利用履歴から目標プロセッサ実行レベルを計算する方法を提供するものであって、この方法は、
所定のタスク時間間隔内で与えられた処理タスクを実行する際にプロセッサ利用を表示するタスク・ワーク値を計算するステップと、
タスク・ワーク値に従って目標プロセッサ実行レベルを計算するステップと、
を備えている。
【００１７】
更に他の特徴から見て、本発明は、コンピュータを制御して複数の処理タスクを実行する際にプロセッサの利用履歴から、プロセッサの目標プロセッサ実行レベルを計算するコンピュータ・プログラムを搭載したコンピュータ・プログラム・プロダクトを提供するものであって、コンピュータ・プログラムは、
所定のタスク時間間隔内で与えられた処理タスクを実行する際にプロセッサ利用を表示するタスク・ワーク値を計算するように動作可能なタスク・ワーク値計算コードと、
タスク・ワーク値に従って目標プロセッサ実行レベルを計算するように動作可能な目標プロセッサ計算コードと、
を備えている。
【００１８】
以上、本発明の他の目的、特徴及び効果は、添付図面に関連して読む以下の実施例の詳細な説明から明らかとなる。
【発明を実施するための最良の形態】
【００１９】
図１は、どのようにしてデータ処理システムにおいて本技術による電力管理システムを実施できるのかを概要的に示す。データ処理システムは、システム・コール・モジュール１１２、スケジューラ１１４及び通常電力マネジャ１１６を含む標準的なカーネル機能モジュールを有するカーネル１００を備えている。インテリジェント・エネルギ管理システム１２０は、カーネル内に実施され、ポリシ１２２、実行設定制御モジュール１２４及びイベント・トレース・モジュール１２６を備えている。ユーザ処理層１３０は、システム・コール・モジュール１３２、タスク管理モジュール１３４及びアプリケーション特定データ１３６を備えている。ユーザ処理層１３０は、アプリケーション・モニタリング・モジュール１４０を介してカーネル１００に情報を供給する。
【００２０】
カーネル１００は、オペレーティング・システムの他の部分に基本的なサービスを提供するコアである。カーネルは、シェルと対照されてもよく、ユーザ・コマンドと対話するオペレーティング・システムの最外部分である。カーネルのコードは、そのホスト・システム上でメモリのような物理リソースに対して完全なアクセス特権により実行される。カーネルのサービスは、システムの他の部分により又はシステム・コールとして一組のプログラム・インターフェースを通るアプリケーション・プログラムにより要求される。ユーザ処理層及びカーネルの両者は、システム・コール・モジュール１１２、１３２を有する。スケジューラ１１４は、どのプログラムがカーネルの処理時間を共有し、かつ、どのような順序かを判断する。カーネル内のスーパーバイザ（図示なし）は、各処理に対して計画時間にプロセッサの使用を与える。通常電力マネジャ１１６は、節電スリープ・モードとプロセッサ利用のレベルに従った標準覚醒モードとの間でプロセッサを切り換えることにより電源電圧を管理する。
【００２１】
インテリジェント・エネルギ管理マネジャ１２０は、プロセッサ実行目標を計算し、かつ設定する役割を担う。インテリジェント・エネルギ管理マネジャ１２０は、節電のためにスリープ・モードのみに依存するよりも、アプリケーション・ソフトウェアが処理（例えば、タスク）のデッド・ラインを見逃すことなく、中央処理装置（ＣＰＵ）の動作電圧及びプロセッサのクロック周波数を下げるのを可能にする。ＣＰＵが全能力でランしているときは、多くの処理タスクをそれらのデッド・ラインより前に完了して、プロセッサは、次のスケジュール・タスクを開始するまでアイドルとなる。データを生成するタスクに対するタスク・デッドラインの例は、生成したデータが他のタスクにより必要とされた時点である。インタラクティブ・トークに対するデッド・ラインは、ユーザの認識しきい値となる（５０〜１００ｍｓ）。フル実行で行き、次いでアイドリングを実行すると、エネルギ効率は、デッド・ラインがより正確に適応するようにもっとゆっくりとタスクを完了するときより悪くなる。プロセッサの周波数が低くなると、エネルギ節約を達成するために電圧をスケール・ダウンすることができる。コンプリメンタリ金属酸化半導体（ＣＭＯＳ）技術により実施されたプロセッサのために、与えられたワーク・ロードに使用されたエネルギは、電圧の二乗に比例する。ポリシ・コディネータは、互いに異なるラン・タイム状況に適している多数の実行設定アルゴリズムを管理する。与えられた条件に対して最適の実行設定アルゴリズムは、ラン・タイムで選択される。実行設定制御モジュール１２４は、各実行設定アルゴリズムの結果を受け取って、これらの結果を優先順位化により目標プロセッサ実行を反復的に計算する。イベント・トレース・モジュール１２６は、カーネル１１０及びユーザ処理層１３０の両者におけるシステム・イベントを監視し、かつ実行設定制御モジュール１２４及びポリシ・コディネータ１２２に集められた情報を供給する。
【００２２】
ユーザ処理層において、処理作業は、システム・コール・モジュール１３２と、タスク切り換え、タスク生成及びタスク終了イベントを含む処理タスク・イベント管理モジュール１３４を介して、かつアプリケーション特定データを介して監視される。インテリジェント・エネルギ管理マネジャ１２０は、標準カーネル機能モジュールにフックされ、かつプロセッサの速度及び電圧レベルを制御するために使用される一組のカーネル・モジュール及びパッチとして実施される。インテリジェント・エネルギ管理マネジャ１２０を実施する方法は、カーネル１００内の他のモジュールから相対的に自律させる。これは、実行制御機構の指示ホスト・オペレーティング・システムに対する指示を軽減させる効果がある。更に、カーネルを実施すると、ユーザ・アプリケーション・プログラムを変更する必要がないことも意味する。従って、インテリジェント・エネルギ管理マネジャ１２０は、システム・コール・モジュール１１２、モジューラ１２４及びカーネルの通常電力マネジャ１１６と共存するが、これらのサブ・システム内に一定のフックが必要と思われる。インテリジェント・エネルギ管理マネジャ１２０は、実行中のタスク間の通信パタータニングを調べることにより、ＯＳカーネルからタスク・デッド・ライン及びタスク分類情報（例えば、タスクは、インタラクティブ・アプリケーションに関連しているか否か）を導き出すために使用される。更に、どのシステム・コールが各タスクによりアクセスされるのか、また、どのようにしてデータがカーネル内の通信構造間を流れるのかを監視するために使用される。
【００２３】
図２は、本発明による実行設定アルゴリズムの３階層構造層を概要的に示す。与えられたプロセッサ上で、周波数・電圧設定オプションは、連続よりも通常、断続的であることに注意すべきである。従って、目標プロセッサ実行レベルは、固定した一組の所定値から選択される必要がある。従って、目標プロセッサ実行を計算する既知の技術は、単一の実行設定アルゴリズムの使用を必要とするのに対して、本発明の技術は、それぞれが異なるラン・タイム状況に対して適した異なる特徴を有する多数のアルゴリズムを利用する。ラン・タイムで与えられた処理状況に対して最も適用可能なアルゴリズムが選択される。ポリシ・コディネータ・モジュール１２２は、これらの実行設定アルゴリズムを協調させて、標準カーネル１１０におけるフックに接続することにより、多数の実行設定アルゴリズムに対して共有した機能を提供する。多数の実行設定アルゴリズムの結果は、相関され、かつ解析されて目標プロセッサ実行レベルに対するグローバル予測を判断する。種々のアルゴリズムは、決定階層構造（即ち、アルゴリズム・スタック）に編成され、この決定階層構造では、階層構造の上位（高い優先度）レベルでアルゴリズムにより出力された実行レベル・インジケータが階層構造の下位（低い優先度）レベルでアルゴリズムにより出力された実行レベル・インジケータに優先した権限を有する。図２の実施例は、３階層構造レベルを有する。階層構造の最高レベルには、インタラクティブ・アプリケーション実行インジケータ２１０が存在し、中間レベルには、アプリケーション特定実行インジケータ２２０が存在し、また階層構造の最低レベルには、タスク・ベースのプロセッサ利用実行インジケータ２３０が存在する。
【００２４】
インタラクティブ・アプリケーション実行インジケータ２１０の計算は、フロートナ（Flautner）ほか、２００１年６月、モバイル・コンピューティング及びネットワーキングに関する国際会議、「ダイナミック電圧スケール設定」（“Automatic Performance-setting for Dynamic Voltage Scaling”,Proceeding of the International Conference on Mobile Computing and Networking, July 2001）において説明されたものに基づくアルゴリズムによって実行される。インタラクティブ・アプリケーション実行レベルは、ユーザ経験を直接影響する実行期間を見出すことにより、かつ、これらのエピソードが不都合な遅延なしに完了することを保証することにより、良好なインタラクティブ実行の保証を提供するためにシークをする。アルゴリズムは、自動的にインタラクティブ・エピソードように比較的に簡単な技術を使用する。この技術は、ＧＵＩコントローラであるＸサーバからの通信を監視し、かつ結果としてトリガされたタスクの実行をトラッキングすることに依存している。
【００２５】
インタラクティブ・エピソードの開始（多数のタスクを通常、備えている）は、ユーザにより開始され、かつＧＵＩイベント、例えば、マウスのボタン又はキーボード上のキーを押すことにより示される。このイベントの結果として、ＧＵＩコントローラ（この場合はＸサーバ）は、イベントを取り扱う役割を担うタスクにメッセージを送出する。適応システム・コール（種々のバージョンの読み出し、書き込み及び選択）を監視することにより、インテリジェント・エネルギ管理マネジャ１２０は、インタラクティブ・エピソードの開始を自動的に検出することができる。エピソードが開始すると、ＧＵＩコントローラ、及びメッセージの受信者であるタスクの両者は、インタラクティブ・エピソードにあるとしてマークされる。インタラクティブ・エピソード・タスクがマークなしのタスクと通信すると、まだマークされていないタスクもマークされる。この処理中に、インテリジェント・エネルギ・マネジャ１２０は、いくつマークされたタスクをプリエンプトしたかのトラッキングを保持する。プリエンプトされたタスク数がゼロになり、全てのタスクが完了までランしたことを表したときは、ティブト・エピソードの終端に達している。
【００２６】
図３は、インタラクティブ・エピソード中のプロセッサ実行レベルを設定する戦略を示す。インタラクティブ・エピソードの期間は、（約１０-4から約１秒までの）数オーダの大きさにより変動することが知られている。しかしながら、遷移開始遅れ即ち「５ミリ秒のスキップしきい値」が最短インタラクティブ・エピソードをろ波するためにセットされ、これによって要求実行レベル遷移数を減少させる。サブ・ミリ秒のインタラクティブ・エピソードは、通常、キー圧力のエコー又はスクリーンを横切るマウスを移動させること及び小さな長方形を再描画することの結果である。スキップしきい値は、最悪の場合、逆効果となることなく、短いエピソードに実行インジケータをろ波可能にさせるので、５ミリ秒にセットされる。
【００２７】
インタラクティブ・エピソード期間長がスキップしきい値を超えるときは、関連の実行レベル値が総合インタラクティブ実行レベル予測に含まれる。次のインタラクティブ・エピソード用の実行係数は、経過した全インタラクティブ・エピソードに対する計算実行係数の重み付け指数関数的な減衰平均により与えられる。この技術によれば、インタラクティブ・アプリケーション実行設定アルゴリズムは、システムにおいてインタラクティブ・エピソードに必要な実行レベルに対して単一グローバル予測を使用することに注意すべきである。［これは、以上で述べた刊行物に説明された技術と異なり、これによると、タスクがエピソードを開始するに従ってタスク当たりの実行レベル予測を使用していた。］
【００２８】
ユーザの経験による誤実行レベル予測の最悪ケースの影響を抑制するために、インタラクティブ・エピソードがいわゆる「パニックしきい値」に達する前に、終結しないときは、トップの階層構造レイヤが最大実行レベルとなるように指定される。これは、トップ・レベル予測であるので、システムにより強化される。反則しているインタラクティブ・エピソードの終りにおいて、インタラクティブ・アルゴリズムは、エピソードに対して何が正しい実行設定であるべきかを計算して、将来の予測に反映させるように、この値を指数関数的に減衰する平均値に組み込む。付加的な最適化は、実際においてインタラクティブ・エピソード中に実際にパニックしきい値に到着したときは、正しい実行レベルをより高い重み付け（ｋ＝３の代わりにＫ＝１を使用する）により指数関数的減衰平均に組み込むように、移動平均を再スケーリングする。実行予測は、スキップしきい値より長い全てのエピソードについて計算される。
【００２９】
インタラクティブ・エピソードの「デッド・ライン」は、認識された各インタラクティブ・エピソード用の実行レベル・インジケータを得るために使用される。デッド・ラインは、タスクが実行に逆効果とならないように完了しなければならない最終時間である。インタラクティブ・エピソードに対する実行レベル・インジケータは、特定のインタラクティブ・イベントに関連するヒューマン・パーセプションしきい値に従って計算される。例えば、毎秒２０〜３０フレームの速度は、ユーザが一連のイメージを連続するストリームとして知覚するのに十分な早さなので、知覚は、
【００３０】
【数１】
2004164643.tif 000003
【００３１】
インタラクティブ・イメージ・ディスプレイ・エピソードに対して、しきい値を５０ｍｓに設定してもよい。知覚しきい値の正しい値は、ユーザ及び達成したタスクの形式に従属するが、５０ｍｓの固定値は階層構造のインタラクティブ・アルゴリズムに適していることが解った。下記の等式は、知覚しきい値より短いエピソードの実行要求を計算するために使用される。
ただし、全速の等価ワーク（Workfse）は、インタラクティブ・エピソードの開始から測定される。
【００３２】
中間階層構造レベルのアプリケーション特定実行インジケータ２２０は、実行レベル設定機能に注目したアプリケーション・プログラムのカテゴリにより出力される情報を収集により得られる。これらのプログラム・アプリケーションは、これら特定的な実行要求についてインテリジェント・エネルギ管理マネジャ１２０に特定の情報を（システム・コールを介して）提供するようにしていた。オペレーティング・システム及びアプリケーション・プログラムは、プリエンプトに関して、この通信を容易にするために新しいＡＰＩ要素を設けられてもよい。
【００３３】
知覚に基づく実行インジケータ２３０は、最近の利用歴に基づいてプロセッサの将来利用を予測する知覚に基づくアルゴリズムを実施することにより得られる。このアルゴリズムは、個別的な各タスクについて利用予測を導き出して、タスク・ベースによりタスク上で利用歴を計算する期間長（利用歴ウィンドウ）を調整する。最上レイヤのインタラクティブ・アプリケーション・アルゴリズムは、インタラクティブ・タスクを考慮するのに対し、知覚に基づくアルゴリズムは、プロセッサにより実行されるべきタスクの全てのカテゴリを考慮する。インタラクティブ・アプリケーション・アルゴリズムは、高品質のインタラクティブ実行を保証することを目的とする実行レベル・インジケータを計算し、また、これが階層構造の最上レベルに位置するので、知覚に基づくアルゴリズムは、控え目な短い利用歴ウィンドウに制約されるべきでない。このような最低階層構造レベルにおいて長い利用歴ウィンドウを使用する可能性は、適当ならば更に積極的な省電力戦略を選択できるので、効率改善のために許容される。利用歴ウィンドウが短過ぎるときは、これは、２実行レベル予測を固定値間で急速に振動させる原因ともなる。通常、（階層構造的なアルゴリズム・セットよりも）単一の統合アルゴリズムを使用して全てのラン・タイム環境用の実行レベルを設定する短い利用歴ウィンドウを設定することが必要である例えば、統合アルゴリズムのような完結的なプロセッサ集中インタラクティブ・イベントに対処できるようにするためには、利用歴ウィンドウを短く保持する必要がある。
【００３４】
３レイヤ・スタックの各実行設定アルゴリズムは、与えられた期間内に処理ワーク・ダンの測定値を使用する。この実施例において、使用されるワーク・ダン測定値は、その期間に実行された（プロセッサの）全速等価ワーク（Workfse）である。この全速等価ワーク予測は、下記式により計算される。
【００３５】
【数２】
2004164643.tif 000004
【００３６】
ただし、iは、与えられた期間中に実施された異なるnプロセッサ実行レベルのうちの１つであり、ｔiは、実行レベルiにおいて費やした秒による非アイドル時間であり、かつｐiは、ピーク（全速）プロセッサ実行レベルの分数として表されたプロセッサ実行レベルiである。この等式は、タイム・スタンプ・カウンタ（ワーク・カウンタ）がリアル・タイムに測定するシステム上で有効である。ワーク・ダンは、カウント速度が現在のプロセッサ周波数により変動するサイクル・カウンタを使用した他の実施例において異なる計算となる。更に、上式は、ワーク・ロードのラン・タイムがプロセッサ周波数に逆比例するものと暗黙的な仮定をする。この仮定は、ワーク・ダンの合理的な予測を提供する。しかしながら、実行スケーリング中に主としてプロセッサ速度対バス速度比の非線形性のために、この仮定は、常に正確ではない。他の実施例では、ワーク・ダンの計算を精密同調させて、このような要素を考慮に入れることができる。
【００３７】
図４は、プロセッサ上のワーク・ロードの実行及びタスクＡ用の利用歴ウィンドウの計算を概要的に示す。図４の水平軸は、時間を表す。タスクＡは、まず時間Ｓにおいて実行をスタートさせて、多数のタスク当たりのデータ構造を初期化する。これらのデータ構造のうちの４つが存在し、下記情報の４片に対応する。(i)ワーク・カウンタの現在状態、(ii)現在（リアル）タイム、(iii)アイドル・タイム・カウンタの現在状態、及び(iV)ラン・ビットを論理レベル‘１’にセットして、タスクがランし始めたことを示す。ワーク・カウンタ、リアル・タイム・カウンタ及びアイドル・タイム・カウンタは、タスクＡに関連したプロセッサ利用を計算し、続いてタスクＡの実行要求を計算するために使用される。時間ＰＥにおいて、タスクＡは、まだ完了までランしていないが、他のタスク、タスクＢにより優先使用される。優先使用は、スケジューラ１１４が現在ランしているタスクよりも高い優先度を有することを判断したときに発生する。タスクＡを優先使用しているときは、ラン・ビットを‘１’の論理レベルに保持してタスクは、完了するまで未だワークがあることを表示する。時間ＲＥにおいて、再度スケジュールを設定したことにより、タスクＡを再度実行し、ランして完了する時間ＴＣまで実行し続けて、そこで処理時間を自ら停止する。完了時に、タスクＡは、プロセッサに他のタスクを与えるシステム・コールを開始することができる。時間ＴＣでタスクＡを完了すると、ラン・ビットを論理レベル‘０’にリセットする。
【００３８】
時間ＴＣ後に、アイドル期間が存在し、更なるタスクＣの実行及び次のアイドル期間が続く。時間ＲＳで、タスクＡは、第２の時間についての実行を開始する。時間ＲＳで、タスクＡに関連したラン・ビットの‘０’状態は、タスクＡの実行要求の計算を可能にする情報が存在することを示しており、従ってプロセッサ目標実行レベルをタスクＡの切迫した再実行用にセットすることができる。与えられたタスク用の利用歴ウィンドウは、与えられたタスクの第１の実行の開始から与えられたタスクの次の実行の開始までの期間であると定義され、関連のウィンドウ内で与えられたタスクの少なくとも１優先使用イベント（この場合に時点ＲＥでタスクＢにより、タスクＡは優先使用される）を含む必要がある。従って、この場合に、タスクＡ用の利用歴ウィンドウは、時間Ｓから時間ＲＳまでの期間であると定義される。タスクＡに対する目標実行レベルは、下記のように計算される。
【００３９】
【数３】
2004164643.tif 000005
ただし、ｋは、重み付け係数であり、idleは、図４における時間Ｓから時間ＲＳまでの期間内の秒によるアイドル時間であり、またタスクＡに対するデッドラインは（Workfse）＋Idle）であると定義される。この特定例において、図４におけるタスクＢのように優先使用タスクの実行検出は、各タスクの非優先使用スケジュール前のランであるタスク処理は、しばしばタスクＡの実行と高度に相関される。時点ＴＣとＲＳとの間のアイドル時間は、低下した実行レベルでプロセッサをランさせることにより、費やされ得るスラックである。しかしながら、タスクＣは、適用可能なスラックを減少させるので、実行レベル計算における因数にされる。
【００４０】
WorkEststNew及びDeadlineNewに関する上式は、それぞれ指数関数的減衰平均を表す。このような指数関数的減衰平均は、最近予測であれば最近でない予測より影響力を有するようになる。重み付け係数ｋは、指数関数的減衰平均に関連したパラメータである。ｋ＝３の値は、効果的に作用することが判り、またこの小さな値は、各予測が良好な予測であることを表している。ワーク予測器及びデッドライン予測器のトラッキングを個別的に保持することにより、実行予測は、利用歴ウィンドウの長さに従って重み付けされる。これは、大きなウィンドウ・サイズに関連した実行が実行予測より優位とならないことを保証する。このアルゴリズムに対する実行レベル・インジケータPerfperspectives-basedは、２つの指数関数的減衰平均の比により与えられる。即ち、Perfperspectives-based＝WorkEstNew／DeadlineNewこの技術の戦略によれば、与えられたタスクに対するワーク予測WorkEstは、５０ミリ秒と１５０ミリ秒との間のワークロード従属時間間隔上で再計算される。しかしながら、各実行タスクが適当なそれぞれのタスクに基づくWorkEst値に依存するようにタスク毎にWorkEstを計算するので、WorkEstは、実際には５〜１０ミリ秒毎に更新される（タスク・スイッチング・イベントに反映させる）。このアルゴリズムは、既知のインターバル・ベース・アルゴリズムとは異なり、各タスクについて個別的に利用予測を導き出し、更にタスク毎を基本として利用歴ウィンドウのサイズを調整している。既知の統合実行設定アルゴリズムは、指数関数的減衰平均を使用するが、これらは、タスク・ベースの利用歴ウィンドウについてのタスク・ベース平均よりも固定利用歴ウィンドウ（１０〜５０ミリ秒）に対する全実行タスクについてのグローバル平均を計算する。
【００４１】
この技術の見込みベースのアルゴリズムによれば、新しい非インタラクティブＣＰＵ拘束タスクが長大な期間について優先使用されることなく、プロセッサを使用することにより発生する状況を避ける必要がある。これは、タスクが少なくとも１回優先使用されると利用歴ウィンドウを単に定義できるだけなので、タスクに対して実行レベルを採用する際にかなりの遅れを導入する恐れがある。好ましくない実行適応遅れを避けるために、上側しきい値は、ワーク予測を計算する非優先使用の長さについて設定される。特に、タスクが１００ミリ秒間、優先使用されさることなく継続したときは、そのワーク予測をデフォールトにより再計算する。１００ミリ秒の値は、個別的なインタラクティブ・アプリケーション実行インジケータを発生する、より厳格なアプリケーション歴ウィンドウが支配的な階層レイヤ２１０を介してインタラクティブ・アプリケーションに対して保証されることを考慮に入れることにより選択された。更に、１００ミリ秒ウィンドウしきい値により多分に影響されるユーザ・アプリケーションのクラスのみが、例えば、数秒、更に数分間は多分ランする編集のような計算集中バッチ・ジョブであることも考慮された。このような場合に、ラン・タイムの付加的な１００ミリ秒（０.１）秒）は、残念ながらかなりの実行方法となる。
【００４２】
図５は、図２の３層の階層構造実行ポリシ・スタックの実施を概要的に示す。この実施は、実行インジケータ・ポリシ・スタック５１０及びポリシ・イベント・ハンドラ５３０を備え、それぞれ目標実行計算器５４０へ情報を出力している。目標実行計算器５４０は、４つの実行設定アルゴリズム、即ち、最高レベルのインタラクティブ・アルゴリズム、中間レベルのアプリケーション・ベース・アルゴリズム及び２つの下位レベル・アルゴリズムによる結果を収集するために使用される。４つのアルゴリズムは、並行してランすることが可能である。目標実行計算器５４０は、ポリシ・スタック５１０により発生した多重実行インジケータ（この場合は４）から単一のグローバル目標実行レベル導き出す。ポリシ・スタック５１０は、ポリシ・イベント・ハンドラ５３０及び目標実行計算器５４０と共に、ユーザによる要望に従ってスタックの各レベルのポリシ・アルゴリズムを置き換え、又は相互に入れ換えられるように、多重実行設定ポリシ用の柔軟性のある骨組みを提供する。従って、実行ポリシ・スタックは、ユーザ・カスタム化実行設定ポリシを組み込むことができるプラットフォームを提供する。
【００４３】
多重実行設定アルゴリズムのそれぞれは、異なる特定のカテゴリのラン・タイム・イベントに対処するために特殊化される。しかしながら、図５の実施例において異なる４つのアルゴリズムが存在するので、全て出力される異なった実行インジケータ、ソフトウェアは、４つの実行インジケータのうちのいずれがグローバル目標値を設定する際に優先権を取るべきかについて決定する必要がある。更に、各実行設定アルゴリズムが独立してランし、かつ異なる時間に出力を発生することができるとすると、グローバル目標実行レベルを有効に計算することができる時間について決定をする必要がある。更に、多重実行設定アルゴリズムが同一の処理イベント上で全てこれらの決定に基づき、それ以外は、スプリアス目標更新が発生し得る場合に、実行インジケータを如何に組み合わせるかについても考慮する必要がある。
【００４４】
これらの問題に対処するために、ポリシ・スタック５１０のアルゴリズムは、示されているように、３レベルの階層構造に編成され、上位レベルにおけるポリシは、下位の（低い優先）レベルから導き出される実行レベル要求に優先するように権利を与える。従って、レベル２のアルゴリズムは、レベル１のアルゴリズムに優先することができ、続いて、これがレベル０の２つのアルゴリズムに優先することができる。各階層構造レベルは、それ自体、交替する多重実行設定アルゴリズムを備えていることに注意すべきである。異なる実行設定アルゴリズムは、この階層構造において、これらの位置に気付いていず、システムにおけるどのようなイベントについても、これらの実行決定に基づくことができる。与えられたアルゴリズムが実行レベルを要求するときは、その所望実行レベルと共にコマンドをポリシ・スタック５１０に送出する。ポリシ・スタックの各アルゴリズムのために、コマンド５１２、５１６、５２０、５２４及び実行レベル・インジケータ５１４、５１８、５２２、５２６を含むデータ構造を記憶する。レベル１のアルゴリズムに適用するコマンドIGNORE（無視）５２０は、グローバル実行目標の計算において関連する実行レベル・インジケータを無視すべきことを目標実行計算器４４０に対して表示する。両者のレベル０に対して指定されたコマンド・セット５１２、５１６は、目標実行計算器５４０に階層構造において下位から来る実行レベル要求を考慮することなく、対応する実行レベルを設定させる。しかしながら、ＳＥＴコマンドは、より高い階層構造レベルからの実行レベル要求を優先させることはできない。この実施例において、一方のレベル０アルゴリズムは、実行をピーク・レベルの５５％に設定され、他方のレベル０アルゴリズムは、ピーク・レベルの２５％に設定されることを要求していた。目標実行計算器は、オペレータを使用して、これら等しい２つの優先度要求を組み合わせ、この場合、レベル０実行インジケータとして５５％値を優先的に選択する。レベル２では、コマンド‘SET IF GREATER THAN’（より大のときはセット）は、８０％の実行インジケータと共に指定された。‘SET IF GREATER THAN’コマンドは、目標実行計算器５４０が下位の階層構造レベルからの実行インジケータのいずれよりも大きい限り、これがグローバル目標実行レベルを８０％に設定せよということである。この場合に、ｌｖ０実行インジケータは、５５％であり、レベル１実行インジケータは、無視され、従って、グローバル目標をピーク実行の８０％にセットする必要がある。
【００４５】
各アルゴリズムに対する最近に計算された実行レベル・インジケータは、ポリシ・スタック５１０によりメモリに記憶されるので、目標実行計算器５４０は、それぞれ、かつ、あらゆる実行設定アルゴリズムを呼び出すことを必要とせずに、任意の時間で新しいグローバル目標値を計算することができる。新しい実行レベル要求がスタック上のアルゴリズムのうちの１つにより計算されると、目標実行計算器は、ボタン・レベルから更新グローバル目標実行レベルを計算するまで、コマンド実行データ構造の内容を評価する。従って、レベル０でグローバル予測は、５５％にセットされ、レベル１で、これは５５％にとどまり、レベル２でグローバル予測は、８０％に変る。各実行設定アルゴリズムは、任意の時間に（システムにおける処理イベントにより）トリガされて新しいピーク・レベルを計算してもよいが、全ての実行設定アルゴリズムが応答しようとする一組の共通イベントが存在する。これらのイベントは、ポリシ・イベント・ハンドラ５３０により監視されてフラグ付けされ、ポリシ・イベント・ハンドラ５３０は、目標実行計算器５４０にポリシ・イベント情報を供給する。これらのイベントの特殊区分は、リセット・イベント５３２、タスク切り換えイベント５３４及び実行変更イベント５３６を含む。実行変更イベント５３６は、通常、ポリシ・スタック５１０上の実行要求を変更させることはないが、各実行設定アルゴリズムをプロセッサの現在ピーク・レベルに変更することを通知する。これらのイベントの特殊区分５３２、５３４、５３６のために、これらのアルゴリズムのうちの１つが更新した実行レベル・インジケータを発行する度に、グローバル目標レベルを計算することはしない。むしろ、全ての挿入した実行設定アルゴリズムの全てのイベントを呼び出した後に、各イベント通告に対して１回のみ計算を実行するように目標実行レベル計算を協調させる。
【００４６】
複数のデバイス・ドライバ又は複数のデバイスは、個々のデバイスがポリシ・スタック５１０及び／又はポリシ・スタックの個別的な実行設定アルゴリズムに、動作状態における顕著な変化について通知するのを可能にするアプリケーション・プログラム・インターフェースをそのものに備えてもよい。これは、実行設定アルゴリズムが目標実行レベルの再計算をトリガするのを可能にする。例えば、通知は、プロセッサ集中ＣＰＵ拘束タスクが起動するときに、デバイスによりポリシ・スタック５１０に送出可能とされる。このような通知は、任意選択的なものであるが、しかし、受信の際に、これに応答する必要はない。
【００４７】
図６は、本発明によるワーキング・トラッキング・カウンタ６００を概要的に示す。ワーキング・トラッキング・カウンタ６００は、ソフトウェア制御モジュール６２０及びハードウェア制御モジュール６３０を有する増分値レジスタ６１０と、ワーク・カウント値及び時間カウント値レジスタを備えたアキュムレータ・モジュール６４０と、リアル・タイム・クロック６５０及び制御レジスタ６６０とを備えている。この実施例のワーク・トラッキング・カウンタは、このカウンタの増分値を増加させる時間又はその近傍でプロセッサにより実行されている実際のワークに比例していることにおいて、既知のタイム・スタンプ・カウンタ及びＣＰＵサイクル・カウンタと異なる。増分値レジスタ６１０は、各カウンタ・サイクルにおいてプロセッサにより実行したワークを予測するワーク・ダン計算器を備えている。ワーク・ダンは、ソフトウェア制御モジュール６２０を介して及び／又はハードウェア制御モジュール６３０を介して得られる。ソフトウェア制御モジュール６２０は、増分値を現在プロセッサ速度と簡単なワーク・ダン計算を実施する。プロセッサがピーク実行の７０％でランしているときは、増分値は、０．７となり、これに対して、プロセッサがピーク実行の４０％で動作しているとき、増分値は、０.４となる。プロセッサが１カウント・サイクル中にアイドルであることをソフトウェア制御モジュール６２０が検出すると、増分値は、ゼロにセットされる。ワーク・トラッキング・カウンタの他の実施例では、より複雑なソフトウェア・アルゴリズムを使用して精度を高めたワーク・ダン予測を計算する。
【００４８】
表１は、２つの異なるプロセッサ速度間（この場合に高い速度から低い速度）でのピーク・レベル遷移を考慮すると、ＣＰＵ拘束ループ・ピーク・レベル遷移期待ラン・タイムと実際のラン・タイムとの間のパーセントによる矛盾を与える測定データをリストに表示する。その結果は、独立した３つのプロセッサ実行レベル、（表の左端の欄において指定されるように）３００、４００、５００Ｍｈｚにおけるポスト遷移ランに基づいている。表１の最上列は、左端欄における対応するプロセッサ速度に遷移した初期ピーク・レベルをリストに表示する。ＣＰＵ拘束ループ上で、予測測定値と実際測定値との間の差は、雑音から識別可能であり、これに対し、ＭＰＥＧワーク・ロード用では、実行周波数において１００Ｍｈｚ当たり約６％〜７％の誤差を代償にしている。これらのワーク・ロード上の最大誤差は、２０％以下（１９.４％）であると見られ、これは、システムにとって固定可能な数ピーク・レベルのみで許容されると考えられる。しかしながら、システムにおいて選択可能な最小から最大プロセッサ実行レベルの利用可能な範囲は、増加し、また各ピーク・レベルのステップ範囲は、低下するので、プロセッサ速度よりも更に正確なワーク予測器が要求される。
【００４９】
【表１】
2004164643.tif 000006
【００５０】
他の実施例の更に複雑なアルゴリズムは、ワーク・ダンがプロセッサ速度に直接比例するという仮定をするよりも、（メモリ・アクセスのような重要なイベントのトラッキングを保持するカウンタを介して）命令プロファイル並びにワーク・ロードの期待及び実施の減少率を監視することを含むより正確なワーク・ダン予測技術を使用する。更に、他の実施例は、メモリ・システム実行は、ワーク・ダン予測を改善するためにキャッシュ・ヒット率及び実行インジケータを使用する。更に、他の実施例は、バックグラウンドのオペレーティング・システム・タスクを実行する際に使用される処理時間の百分率に対する（有用なワーク・ダンに等価な）プログラミング・アプリケーションを実行する際に使用される処理時間の百分率を監視するためにソフトウェアを使用する。
【００５１】
ハードウェア制御モジュール６３０は、処理が固定した２つのピーク・レベル間で切り換える処理をしているときの遷移期間中であっても、ワーク・ダンを予測可能である。各プロセッサ実行遷移のために、プロセッサが何も命令を発行しない約２０ミリ秒の休止が存在可能である。この休止は、フェーズ・ロック・ループを新しい目標プロセッサ周波数に再同期させるために必要とする時間のためにある。更に、プロセッサ周波数を変更可能となる前に、電圧は、新しい目標周波数に適した値に設定される必要がある。従って、プロセッサが旧目標周波数でランしていると仮定されてもよいが、しかし（電圧が新目標レベルに設定されたので）、エネルギが新目標周波数で消費されているものと仮定される間に、１ミリ秒までの遷移時間が存在する。この周波数は、ピーク・レベルの変化に影響するために中間周波数ステップを介して、いくつかのステップにより上昇されてもよい。プロセッサの周波数がダイナミックに変化しているこの遷移期間において、ハードウェア制御モジュール６３０は、ソフトウェアが認識していないダイナミックな変化を考慮して、増分値レジスタを更新するように動作可能である。この実施例は、ワーク・ダンを再計算するためにソフトウェア制御モジュール６２０、ハードウェア制御モジュール６３０の両者を使用しているけれども、他の実施例は、ワーク・ダンを予測するために、これら２つのモジュールのうちの１つのみを使用するだけでよい。
【００５２】
アキュムレータ・モジュール（複数）６４０は、周期的に増分値レジスタ６１０から増分値を周期的に読み出し、かつ、この増分値をワーク・カウント値レジスタに積算された総和に加算する。ワーク・カウント値レジスタは、クロック・チック毎にワーク・カウンタ値を増加させる。クロック・チックは、リアル・タイム・クロック６５０から導き出される時間信号である。所定の時間間隔によるワーク・ダンを測定するために、アキュムレータ・モジュール（複数）６４０に記憶されたワーク・カウント値を２回、即ち、所定の時間間隔の先頭で１回、及び終端で１回読み出す。これら２値間の差は、所定の時間間隔によるワーク・ダンの指示をする。
【００５３】
更にリアル・タイム・クロック６５０は、レジスタ６４４に記憶された時間カウント値を増加させる速度を制御する。時間カウント値レジスタは、ワーク・カウント値と同一のタイム・ベース上のタイム・ベースで動作するが、しかし、ワーク・ダンよりも経過した時間を測定するために使用される。タイム・カウンタ及びワーク・ダン・カウンタの両者を有することにより、実行設定アルゴリズムを容易にする。タイム・ベース・レジスタ６４６は、多重プラットフォームの両立性及び秒への変換用に設けられている。時間は、正確かつ一貫性を可能とするように、２つのカウンタ６４２、６４４のタイム・ベース（周波数）を指定するために使用され、即ち、時間カウント値レジスタに記憶された積算値が経過した時間表示をミリ秒により提供する。制御レジスタ・モジュール６６０は、２つの制御レジスタ、即ち、各カウンタに対して１レジスタを備えている。カウンタは、適当な制御レジスタを介してエネーブル、ディセーブル又はリセットされる。
【００５４】
図７は、ワーク・ロード特性に従って多数の異なる固定実行レベルを提供可能な装置を概要的に示す。デバイスは、ＣＰＵ７１０，リアル・タイム・クロック７２０、電源制御モジュール７３０及び図６のワーク・トラッキング・カウンタの増分値レジスタ６１０を備えている。電源制御モジュール７３０は、ＣＰＵが現在、複数の固定実行レベルのうちのいずれでランするように設定されているのかを判断して、リアル・タイム・クロック７２０に対して適当なクロック周波数を選択する。電源制御モジュール７３０は、増分値レジスタ６１０に対する現在のプロセッサ周波数上の情報を入力する。従って、増分値は、プロセッサ周波数に比例しており、これがまたプロセッサによる有用なワーク・ダンの予測を提供する。
【００５５】
ポリシ・スタック５１０の多くの実行設定アルゴリズムは、与えられた時間間隔（ウィンドウ）によるプロセッサの利用歴を使用してプロセッサの適当な将来目標速度を予測する。実行設定ポリシの主な目的は、プロセッサ周波数及び電圧レベルを適当な実行レベル適当な目標実行レベルに低下させることにより、実行の開始からタスク・デッド・ラインまでの期間にプロセッサのビジー時間を最大化することである。
【００５６】
目標実行レベルを現実的に予測可能にするために、インテリジェント・エネルギ管理マネジャ１２０は、与えられた時間間隔中にプロセッサにより実行される実際ワークをトラッキングするための概要を提供する。このワーク・ダン概要は、プラットフォーム間で変化し得る特定ハードウェア・カウンタ実施に関係なく、実行変化及びアイドル時間の考慮を可能にする。本発明によれば、時間間隔によるワーク測定値予測を得るために、各実行設定アルゴリズムは「ワーク構造」をデータ構造に割り付ける。各アルゴリズムは、時間間隔の先頭で「ワーク開始機能」及び与えられた時間間隔の終端で「ワーク停止機能」を呼び出すように設定される。ワーク・ダン測定中は、ワーク構造の内容がアイドル時間の比率及びプロセッサのそれぞれの実行レベルにより重み付けされた利用プロセッサ時間の比率を指定するように自動的に更新される。次いで、ワーク構造に記憶された情報を使用して全速等価値（Workfse）を計算し、続いて、これを目標実行レベル予測用に使用する。インテリジェント・エネルギ管理マネジャ１２０におけるソフトウェアに実施されているワーク・ダン概要機能は、実行レベル予測アルゴリズム開発者に、インテリジェント・エネルギ管理マネジャ１２０に対する好都合なインターフェースを提供する。更に、ワーク・ダン概要は、この技術の実行設定システムの一部を異なるハードウェア・アーキテクチャに簡単化する。
【００５７】
他のハードウェア・プラットフォーム間で重要な１つの差は、時間をプラットフォーム上で測定する方法である。特に、いくつかのアーキテクチャがタイム・スタンプ・カウンタを介してサイクル・カウントの低オーバ・ヘッド方法を提供するが、これに対し、他のアーキテクチャは、ユーザに外部的にプログラム可能なタイマ割り込みを提供するだけである。しかしながら、これらのタイム・スタンプ・カウンタは、設けられていても、同じことを測定する必要はない。例えば、第１種のハードウェアのプラットフォームは、現在のインテル［ＲＴＭ］ペンティアム及びＡＲＺ［ＲＴＭ］プロセッサの両者を含む。これらのプロセッサにおいて、タイム・スタンプ・カウンタは、カウント速度がプロセッサの速度に従って変化するようにＣＰＵサイクルをカウントし、また、このカウンタは、プロセッサがスリープ・モードに入ったときに、カウントを停止する。クルーゾ（Crusoe）［ＲＴＭ］プロセッサを含む第２種のハードウェアのプラットフォームは、プロセッサのピーク速度でサイクルを常時カウントし、かつ、プロセッサがスリープ・モードにあるときであっても、ピーク速度でカウントを継続して増加させるタイム・スタンプ・カウンタを実施している。ワーク・ダンの概要は、これら２種の両方について他種のハードウェア・プラットフォーム上でこの目標実行設定技術の実施を容易にする。
【００５８】
この実施例において計算したようにワーク予測Workfseは、ピーク実行の半分でランしている与えられたワーク・ロードは、完全プロセッサ速度であっても完了までランする長さの２倍を取る必要性はないということを考慮していない。このカウンタ直観結果に対する１つの理由は、プロセッサ・コアがスロー・ダウンされても、メモリ・システムは、そうならないことである。その結果、コア対メモリ実行比は、メモリに好ましい改善である。
【００５９】
既知の技術に対して、この実行設定技術を評価するためにシミュレーションを実行した。特に、既知の技術は、トランスメータ・クルーゾ・プロセッサ（Transmeta Crusoe processor）（Ｒ）に組み込まれた「ロング・ラン（LongRun）」（Ｒ）電力マネジャである。このトランスメータ・クルーゾ・プロセッサは、プロセッサ・ファームウェアに組み込まれたトランスメータ・クルーゾ・プロセッサを有する。ロング・ランは、電力管理を効果的にするためにオペレーティング・システムを変更する必要性をなくす他の既知の電力管理を有する。ロング・ランは、クロック速度選択を誘導するためにプロセッサの履歴利用を使用する。これは、利用が高度であれば、プロセッサを速くし、また利用が低度であれば、実行を低下させる。通常の多くのプロセッサと異なり、プロセッサは、ダイナミック二進変換及び最適化を実行する隠れたソフトウェア・レイヤを既に有するので、電力管理ポリシをクルーゾ・プロセッサ上で比較的に容易に実行することができる。このシミュレーションは、どのようにすれば、ソフトウェア階層構造において、このような低レベルで実施されるロング・ランのようなポリシを実行できるかの方法を確立することを意図していた。この技術は、同一プロセッサ上でロングランと共にランさせた。
【００６０】
このシミュレーションは、１００Ｍｈｚ実行レベル・ステップにより３００ＭＨｚから６００ＭＨｚの領域にある多数の固定実行レベルでランするトランスメータ・クルーゾ５６００プロセッサ（Ｒ）を使用した、ソニー・バイオ（Sony Vaio）［ＴＲＭ］  ＰＣＧ−ＣＩＶＮ（Ｒ）ノートブック・コンピュータ上で実行される。このシミュレーションは、リナックス2.4.4-ac18カーネルの変更版をマンドレーク（Mandrake）7.2オペレーティング・システム（Ｒ）を使用した。比較評価において使用されるワーク・ロードは、以下の通りである。プレイエムペグ（Plaympeg）ＳＤＬ  ＭＰＥＧ（Ｒ）プレイヤ・ライブラリ、ＰＤＬファイルをレンダリングするアクロバット・リーダ（Acrobat Reader)(Ｒ）、テキスト編集用のエマックス（Emacs)(Ｒ）、新しい読出し用のネットスケープ・メール及びニューズ4.7（Netscape Mail and News 4.7)(Ｒ）、ウェブ・ブラウジング用のコンカラ1.9.8（Konqueror 1.9.8）、及び３Ｄゲームとしてのエックス・ウェルトリス1.0.0（Xwelltris 1.0.0)(Ｒ）。インタラクティブ・シェル・コマンドに使用されたベンチマークは、約３０分のスパン中にユーザ実行の種々のシェル・オペレーションについての記録であった。クルーゾ・プロセッサのダイナミック変換エンジンを起因とする可能変動を避けるために、大抵のベンチマークは、少なくとも２回ランさせてダイナミック変換キャッシュをウォーム・アップさせ、最後のランを除く全てのランのシミュレーション・データであった。
【００６１】
この技術による実行設定アルゴリズムは、タイマを取り扱う際に、そのホスト・プラットフォームの妨げとならないように設計された。シミュレーションのために、この技術は、リナックス組込み分解能１０ｍｓのタイマが動作する方法を変更することなく、分解能ミリ秒以下のタイマを備えた。これは、スケジューラ及びシステム・コールのように、カーネルのしばしば実行される部分に（タイマ・イベントをチェックする）タイマ・ディスパッチ・ルーチンを相乗りさせることにより達成された。
【００６２】
この技術による実行設定アルゴリズムは、インタラクティブ・エピソードを見付けるために、あるシステム・コールに割り込み可能にさせる、カーネルに対する複数のフックを備えてように設計され、かつ、これがあらゆるタスク・スイッチ上で起動されるので、タイマ・ディスパッチを管理するために、これらのフックに少数の命令を直接的に付加することであった。各フックは、タイム・スタンプ・カウンタの読出し、次のタイマ・イベントのタイム・スタンプに対する比較及び成功によりタイマ・ディスパッチ・ルーチンへの分岐を実施することにより増加された。実際に、この戦略は、ミリ秒以下の精度を有するタイマをもたらすことが判った。
【００６３】
下記の表２は、シミュレーションに関するタイム統計の詳細である。最悪の場合のタイマ分解能は、スケジューラの１０ミリ秒（表２と矛盾しているように見える）時間量により制限された。しかしながら、本技術による実行設定アルゴリズムは、測定の際に挿入され、通常、タイマ・トリガに接近して発生するので、達成された分解能は、適切であると考えられた。これは、タイマの割り込みがランしているオペレーティング・システム及びプログラム・アプリケーションのスリープ特性を変化させないことを意味するので、プロセッサがスリープ・モードにあったときに、システムのソフト・タイマは、ティック動作を停止する利点があることが証明された。使用されるタイマは、高い解像度だが、低いオーバ・ヘッドを有する。
【００６４】
これらタイマの効果的な特徴は、活性モード及び受動モードの両方を有する装置の開発を容易にした。活性モードでは、この技術による実行設定アルゴリズムが制御をしていた。受動モードでは、この技術のインテリジェント・エネルギ・マネジャが実行及び実行変化の観察者として機能しているけれども、組込みロングラン電力マネジャが実行の管理をしていた。
【００６５】
【表２】
2004164643.tif 000007
【００６６】
ロング・ランにより発生した実行変化の監視は、同様にタイマ開始ルーチンに対して達成された。本技術によるインテリジェント・エネルギ管理マネジャ１２０は、マシン特定レジスタを通してプロセッサの実行レベルを周期的に読み出し、かつ、その結果を前の値と比較する。２つの値が相違するときは、その変化がバッファにログされた。この技術によるインテリジェント・エネルギ・マネジャは、カーネル・バッファに重要なイベントのログを保持するトレーシング機構を備えている。このログは、異なるポリシからの実行レベル要求、タスク・プリエンプション、タスクＩＤ（認識子）及びプロセッサの実行レベルを含む。シミュレーションの実行において、同一実行ラン中に、この技術によりロングランと実行設定アルゴリズムとを比較することが可能であった。即ち、この技術のインテリジェント・エネルギ管理マネジャ１２０が制御をしていたとすれば、同一ワーク・ロード上で行うことになっていた決定を出力するように動作可能であったと同時に、ロングランが実行設定を制御していた。このシミュレーション戦略は、既知のロングラン技術とこの技術との間でインタラクティブ・ベンチ・マークの反復不能なラン間の差を客観的にアクセスするために使用された。
【００６７】
測定及び設定技術を使用するオーバ・ヘッドするために、この技術による実行設定アルゴリズムは、ラン・タイムで実行設定アルゴリズム・コードに費やされる時間のトラッキングを保持している複数のマーカにより実行された。本発明のラン・タイム・オーバ・ヘッドは、ペンティアムＩＩ（Ｒ）上でトランスメータ・クルーゾ（Ｒ）プロセッサ上で約０.１％〜０.５％であることが判ったが、オーバ・ヘッドは、１％と４％との間であった。‘ＶＭＷａｒｅ’（Ｒ）及び‘ユーザ・モード・リナックス（ＵＭＬ）のような仮想マシンにおける更なる測定は、この技術による実行設定アルゴリズムのオーバ・ヘッドが従来のプロセッサ・アーキテクチャよりも仮想マシンにおいてかなり高くなり得ることが確認される。しかしながら、このオーバ・ヘッドは、アルゴリズムの最適化によって効果的に減少されてもよい。
【００６８】
ＭＰＥＧ（Motion Picture Expert Group）の映像再生は、テストした全実行設定アルゴリズムに対して困難な挑戦を提起した。実行設定アルゴリズムは、典型的には、システム上の周期的な負荷を課するが、実行要求は、ＭＰＥＧフレーム形式に従って変化する。従って、実行設定アルゴリズムは、将来の実行要求を予測するために過去の（大きく変更可能な）ＭＰＥＧフレーム復号イベントに対応する比較的に長い時間ウインドウを使用するときは、（低反復の）より計算集中フレームに対する実行デッド・ラインを見逃す恐れがある。他方、アルゴリズムが短い間隔のみで見るならば、単一の実行値に収束しないが、しかし、最大設定間で急速に発振する。実行レベルにおける各変化は、遷移遅延を発生させるので、異なる実行レベル間での急速に発振は好ましくない。ロング・ランに対するシミュレーション結果は、ＭＰＥＧベンチ・マークに対するこの発振の振る舞いを確認する。
【００６９】
この技術は、最悪の場合の応答性に連携するように階層構造の最高レベルでインタラクティブ実行設定アルゴリズムにより、ＭＰＥＧワーク・ロードのために、この発振の問題に対処する。従って、階層構造の最低レベルにおいて、より一般的な間隔に基づく予想アルゴリズムは、より長い観点の実行レベル要求を取ることができる。
【００７０】
図８は、種々のＭＰＥＧを再生する「プレーエムペグ（plaympeg）」(Ｒ）ビデオ・プレーヤ（http://www.lokigames.com/development/smpeg.php3）に対するシミュレーション測定結果を詳細に示す表である。ビデオ・プレーヤの間隔変数のうちのいくつかは、実行中にプロセッサ実行レベルをダイナミックに変更する結果として、どのようにプレーヤが影響されるかについての情報を供給するために提示された。これらの図は、表のＭＰＥＧデコード欄に示されている。特に、「アヘッド（Ahead）」変数は、各フレームの復号が発生するデッド・ラインにどのくらい近いかを測定する。このデッド・ラインに対する近さは、各ビデオの再生中に累積秒として表される。プロセッサの最低実行レベルは、どのくらいアヘッド値を減少できるかの下位限界を課すけれども、最大電力効率のために、アヘッド変数値は、可能な限りゼロに近い必要がある。表の右端欄における「正確なオン・タイム・フィールド」は、これらのデッド・ラインに正確に適合する総フレーム数を指定する。正確にオン・タイムとなるフレームが多ければ、それだけ実行設定アルゴリズムが理論上の最適値に近くなる。図８の表の実行統計欄内のデータは、インテリジェント・エネルギ管理マネジャ１２０監視サブ・システムにより収集される。ロング・ランについての情報を収集するために、インテリジェント・エネルギ管理マネジャ１２０を受動モードにより使用してプロセッサ実行レベルを制御することなく、実行変化のトレースを集める。アイドル・フィールドは、カーネルのアイドル・ループ内で費やされる（多分、家事雑用又は糸紡ぎそのもの行う）時間量を指定し、一方、スリープ・フィールドは、プロセッサが実際に低電力スリープ・モードで費やす時間比を指定する。これらの実行測定のそれぞれについて、この技術がロング・ランよりかなりうまく実行することが図８の表から判る。
【００７１】
図９は、各ワーク・ロードのラン中に収集されたプロセッサ実行レベル統計をリストにより示す表である。各実行レベルにおいて時間比は、ワーク・ロードのラン中にアイドルでない総時間比として計算される。表の「平均実行」レベル欄は、各ワーク・ロードの実行中に平均実行レベル（ピーク実行の百分率として）を指定する。全ての場合において、各ワーク・ロードに対する平均実行レベルは、この技術を使用することによりロング・ランより低くなるので、最後の欄は、ロング・ランに関連して達成された平均実行減少を指定する。ロング・ラン・ワーク・ロード及びこの技術のワーク・ロードの両方に対する再生品質は、同一、即ち同一フレーム速度及びドロップなしフレームであった。
【００７２】
その結果は、この技術が必要な実行レベルを既知のロング・ラン技術より正確に予測可能となることを示している。正確さの増加は、ベンチ・マークの実行中にプロセッサの平均実行レベルの１１％〜３５％の減少に帰結する。ワーク・ロードのラン間のワーク量は、同一のままであるので、この技術のインテリジェント・エネルギ管理者がエネーブルされているときに、アイドル時間及びスリープ時間を減少したことを意味する下位平均実行レベルを期待することができる。この例外は、シミュレーション結果により確認された。同様に、これらのデッド・ラインと正確に一致するフレーム数は、この技術のインテリジェント・エネルギ・マネジャをエネーブルしたときに、増加し、かつ、デコードがそのデッド・ラインの前であるときは、時間の累積量が減少する。
【００７３】
更に、中間実行レベル（図９の表の各列において太字により強調されている）は、顕著な減少を示している。一方、殆どのベンチ・マークにおいて、この技術による実行設定アルゴリズムは、実行時間の最大部分に対するピーク以下の単一実行レベル上に落ち着くのに対し（＞８８％）、ロング・ランは、通常、全速度をランするようにプロセッサを設定する。この一般的な規則に対する例外は、「ケーブルのダンス（Danse De Cable）」ワークロードであり、この技術による実行設定アルゴリズムは、２つの最低実行レベルに落ち着き、これらの２レベル間で発振する。この発振行動に対する理由付けは、クルーゾ・プロセッサにおける特殊実行レベルのためである。この技術による実行設定アルゴリズムは、３００ＭＨｚよりやや高いだけの実行レベルを選択するように選択されたので、３００ＭＨｚ値以上及び以下で変動する行レベル予測として、目標実行レベルは、最も近い２つの実行レベルに等化された。既知のロング・ラン技術とこの技術との間の実行において最も顕著な差は、ロング・ランが顕著なプロセッサ活動量を検出したときに、急速に実行レベルを増大させるオーバ・コーションとなるように見えることである。
【００７４】
全てのワーク・ロードに亘って、ロング・ランによる平均プロセッサ実行レベルは、８０％以下に決して低下することはなく、一方、この技術により設定された実行レベルは、「赤の悪夢」ベンチ・マークに対して５２％程度まで低下する。この技術によるアルゴリズムは、ロング・ランより攻撃的であるが、しかし、サーバの品質が妥協的であると見えるときは、速やかに応答する。ロング・ランは、インタラクティブ実行についての情報を有していないので、より短い時間上で保守的に行動するように強いられ、シミュレーション結果は、これが非能率に至ることを示す。
【００７５】
図１０は、「伝説（図１０Ａ）及び「ケーブルのダンス」（図１０Ｂ）」と題する異なる２つの異なるＭＰＥＧ映画の再生に関する結果の２グラフを示す。各グラフは、ロング・ラン及びこの技術の両方に対する４プロセッサ実行レベル（３００、４００、５００、６００ＭＨｚ）のそれぞれにおいて費やされた時間比を示す。各ランの再生品質は、同一であったが、この技術によるアルゴリズムを使用することは、ロング・ラン技術が実行レベルを指定したときに行ったものより、プロセッサが下のピーク実行でかなり長く費やすことを意味することがこれらのグラフから判る。図１０Ａに描いた「伝説」映画の再生に関する結果は、この技術によるアルゴリズムが５００ＭＨｚの実行レベルで確定することを示す。図１０Ｂに示す「ケーブルのダンス」映画に関する結果は、この技術によるアルゴリズムを使用して、プロセッサが２実行レベル、即ち、３００ＭＨｚと４００ＭＨｚとの間で切り換えられることを明らかにしている。これに対し、これらの映画の両方の場合に、ロング・ラン実行設定アルゴリズムは、実行時間の支配的な部分に対して６００ＭＨｚのピーク・プロセッサ速度を選択する。
【００７６】
図１１は、２つの異なる実行設定ポリシの特性への品質評価を提供する。ロング・ランは、速い連続で上下する実行レベルの切り換えを保持しており、一方、この技術により制御されたときに、システムのプロセッサ実行レベルは、目標実行レベルに近い。図１１Ａの２つの表（最上列）は、エネーブルされたロング・ランによりベンチマーク・ラン中のプロセッサの実行レベルを示す。図１１Ｂ及び１１Ｃ（中段及び下段の列）は、エネーブルされたこの技術によるアルゴリズムによることを除き、同一ベンチ・マークついての実行レベル結果を示す。図１１Ｂは、実行中の実際の実行レベルを示し、一方、図１１Ｃは、この技術による実行設定アルゴリズムが任意の実行レベル（同一の最大実行を与える）でランできることをプロセッサに要求することになる実行レベルを反映している。いくつかの場合に、この技術によるアルゴリズムにより計算された所望の実行レベルは、実際には、プロセッサ上の最小達成可能実行レベルであることに注意すべきである。
【００７７】
ここで、インタラクティブ・ワークロード上で２技術の比較についてのシミュレーション結果を考える。インタラクティブ・ベンチマーク・ランを作成する際の困難のために、反復可能なインタラクティブ・ワークロードは、評価するのにマルチメディアよりかなり困難である。この問題を回避するために、経験的測定を簡単なシミュレーション技術と組み合わせた。特に、本来のロング・ラン及びこの技術によるインテリジェント・エネルギ管理マネジャ１２０の制御により、インタラクティブ・ベンチ・マークをランさせたので、プロセッサの実行レベルを実際に変更させることなく、実行したであろう実行設定判断を単に記録したが、しかし、プロセッサの実行レベルを実際に変化させるものではない。
【００７８】
図１２は、インタラクティブ・ワーク・ロードを評価するシミュレーション・ラン中に収集された実行データを示す。図１２Ａは、ロング・ラン技術用に時間（秒による）対百分率実行レベルの図表を示し、この場合に、プロットした結果は、測定中にプロセッサの実際の実行レベルに対応している。図１２Ｂは、量子化した実行レベルのプロットであり、一方、図１２Ｃは、プロセッサの制御にあったならば、この技術の実行設定アルゴリズムが設定することになる時間の関数として、原始実行レベルのプロットである。この技術によるアルゴリズムが実際に制御されているときは、その実行設定判断は、ロング・ランにより行ったものと異なるラン・タイム効果を有することに注意すべきである。このために、図１２Ｂ及び１２Ｃの図表上の時間軸は、近似とみなすべきである。
【００７９】
統計における時間スキュー問題を回避するために、ロング・ランの代わりに、この技術によるシミュレーションの受動実行レベル・トレースは、この技術の使用に起因すると思われる実行時間増大の影響を査定するために後処理された。実行レベル・トレース全体で見るよりも、インタラクティブ・エピソードのみに注目した。この技術のインタラクティブ実行設定アルゴリズムは、ユーザに直接影響する実行の期間長を見出す機能を含む。この技術は、どのアルゴリズムが制御にあるのかに関係のない有効な読み出しが得られ、従って我々の測定に集中するために使用された。インタラクティブ・エピソードに関する実行範囲を切り離したならば、ロング・ラン及びこの技術の両方について、エピソード中に行った全速度等価ワークを計算した。測定中に、ロング・ランは、ＣＰＵ制御の速度にあり、最近の技術が制御にあれば行うことになるランより速くランするので、この技術に対応する結果のエピソード期間長は、長くする必要がある。第１に、この技術のために残りのワークを下記式により計算する。
【００８０】
【数４】
2004164643.tif 000008
【００８１】
次に、この技術のアルゴリズムがその後パニックしきい値に到達するまで、その予測速度でランし続けるものと仮定して、このアルゴリズムは、どの程度インタラクティブ・エピソードの長さを延長する必要があるのかについて計算した。従って、統計は、調整される。この技術を使用した結果は、プロセッサの活性な制御のもとに、この技術によるアルゴリズムによってランしている同様のワーク・ロード（やや異なるインタラクティブ・ロードだが、同一のベンチ・マーク）上で我々が観察したものに近いことが判った。しかしながら、この技術によるアルゴリズムが実際に制御していたときは、実行設定決定数が減少し、かつ、実行レベルがより正確になった。
【００８２】
図１３は、前述の時間スキュー補正技術を使用して収集された統計を示す。図表における６図表のそれぞれは、２スタック列を有する。各図表の左側の列は、ロングランに関連し、一方、右側の列は、この技術に関連する。各列は、コンピュータによりサポートされた４実行レベルのそれぞれにおいて、インタラクティブ・エピソードに費やす時間比を表すようにスタックされる。これらの実行レベル（ボトム・アップによる）は、１００ＭＨｚ増分で３００ＭＨｚから６００ＭＨｚまでである。この技術によるアルゴリズムは、高いレベルからのものであっても、低い実行レベルでロング・ランより多くの時間を費やすことが明らかである。イーマック（Emac)(Ｒ）のようないくつかのベンチ・マーク上では、マシンは、その最低可能実行レベルに留まると同時に、高速にする必要性など殆どなく、インタラクティブ・デッド・ラインは、適合する。スペクトルの他端には、２モードの挙動を示し、即ち、プロセッサがそのピーク・レベルか又はその最小でランするアクロバット・リーダ・ベンチ・マークがある。このベンチ・マーク上であっても。インタラクティブ・エピソードの多くは、プロセッサの最小実行レベルで時間内に完了することができる。しかしながら、複数のページをレンダリングすることになったときに、ピーク実行レベルは、ユーザ知覚しきい値内でそのデッド・ラインを完了するのに十分でない。従って、十分に長いインタラクティブ・エピソードに遭遇すると、この技術によるアルゴリズムは、プロセッサ実行レベルをそのピークに切り換える。これに対して、この技術によるアルゴリズムは、コンカラ（Konqueror）のラン中に、プロセッサの全部で４利用可能実行レベルの利点を取ることができる。これは、プロセッサをその時間の殆どをピーク・レベルで費やすようにさせるロング・ラン戦略と比較される。
【００８３】
総合的に、図８〜１３を参照して以上で詳細に説明したシミュレーション結果は、ソフトウェア階層構造において異なるレベルで実施された２実行設定ポリシが種々のマルチメディア及びインタラクティブ・ワーク・ロード上の振る舞いを示した。プロセッサのファームウェアに実施されているトランスメータ・ロング・ラン電力マネジャ（Transmeta LongRun power manager）は、オペレーティング・システムのカーネルに実施されているこの技術によるアルゴリズムより控え目な選択をさせることが判った。一組のマルチメディア・ベンチ・マーク上で、１１％〜３５％平均ピーク・レベル減少は、既知のロング・ラン技術を使用して達成されたもの以上に、この技術によるアルゴリズムにより達成された。
【００８４】
この技術による実行設定アルゴリズムは、ソフトウェア・スタックにおいてロング・ランより高く実施されているので、より豊富な一組のラン・タイム情報に基づいて決定することができ、これが続いて変換の精度を高める。
【００８５】
ロング・ランのファームウェア・アプローチは、カーネルに実施されたアルゴリズムより精度が劣ることが示されたが、これはその有用性を損なうものではない。ロング・ランは、オペレーティング・システムの懐疑論者であるというきびしい利点を有している。低レベルの実施と高レベルの実施との間のギャップは、ロング・ランのようなベース・ライン実行設定アルゴリズムを提供し、かつ、プロセッサ実行設定の決定を（任意選択的に）改善するためにオペレーティング・システムに対するインターフェースをさらけ出すことにより、解消され得ることが認識される。この技術による実行設定アルゴリズム階層構造は、このような設計をサポートする機構を提供する。スタック上で最低の実行設定ポリシは、プロセッサのファームウェアにおいて実際に実施可能とされる。
【００８６】
ここでは、添付図面を参照して本発明の実施例を詳細に説明したが、本発明は厳密にこれらの実施例に限定されるものではなく、かつ別記する請求項ごとにより定義されているように、本発明の範囲及び精神から逸脱することなく、当該技術分野に習熟する者によって種々の変化及び変更を実施ことができることを理解すべきである。
【図面の簡単な説明】
【００８７】
【図１】どのようにしてデータ処理システムにおいて本技術による電力管理システムを実施できるのかを概要的に示す。
【図２】本発明による実行設定アルゴリズムの３階層構造層を概要的に示す。
【図３】インタラクティブ・エピソード中にプロセッサ実行レベルを設定する戦略を示す。
【図４】プロセッサ上のワーク・ロードの実行及びタスクＡ用の利用歴ウインドウの計算を概要的に示す。
【図５】図２の３層の階層構造実行ポリシ・スタックの実施を概要的に示す。
【図６】本技術によるワーキング・トラッキング・カウンタ６００を概要的に示す。
【図７】ワーク・ロード特性に従って多数の異なる固定実行レベルを提供可能な装置を概要的に示す。
【図８】種々のＭＰＥＧビデオを再生する「プレイ・エム・ペグ（plaympeg）」ビデオ・プレーヤに関するシミュレーション測定結果の詳細を示すテーブルである。
【図９】各ワーク・ロードのランにおける実行レベル統計をリストにより示すテーブルである。
【図１０】Ａは、「伝説（Legendary）（図１０Ａ）と題する異なるＭＰＥＧ映画の再生に関する結果のグラフを示す。Ｂは、「ケーブルのダンス（Dance de Cable）」（図１０Ｂ）」と題する異なるＭＰＥＧ映画の再生に関する結果のグラフを示す。
【図１１】２つの実行設定ポリシの特性を概要的に示す。
【図１２】インタラクティブ・ワーク・ロード上でテストした異なる実行設定アルゴリズムに関するシミュレータ結果を概要的に示す。
【図１３】時間スキュー補正技術を使用して集めた統計を概要的に示す。
【符号の説明】
【００８８】
１００  カーネル
１１０  標準カーネル
１１２  システム・コール・モジュール
１１４  スケジューラ
１１６  通常電力マネジャ
１２０  インテリジェント・エネルギ管理マネジャ
１２２  ポリシ・コディネータ
１２４  実行設定制御モジュール
１２６  イベント・トレース・モジュール
１３０  ユーザ処理層
１３６  アプリケーション特定データ
１４０  アプリケーション・モニタリング・モジュール
【図１】
2004164643.tif 000009
【図２】
2004164643.tif 000010
【図３】
2004164643.tif 000011
【図４】
2004164643.tif 000012
【図５】
2004164643.tif 000013
【図６】
2004164643.tif 000014
【図７】
2004164643.tif 000015
【図８】
2004164643.tif 000016
【図９】
2004164643.tif 000017
【図１０】
2004164643.tif 000018
【図１１】
2004164643.tif 000019
【図１２】
2004164643.tif 000020
【図１３】
2004164643.tif 000021