JP2014509032A - オーバーヘッドを抑えた電力プロフィール情報の取得 - Google Patents

Abstract

【解決手段】 一実施形態に係る方法は、マルチコアプロセッサのコアについて複数の電力状態移行イベントが発生すると、タイマ切れまたは割り込みのトリガが発生しなくても、コアのシステムカウンタの値およびコアの複数の低電力カウンタの値を読み出す段階を備える。読み出された値は、プロセッサのストレージに格納することができる。そして、収集処理が完了した後、ストレージにアクセスして、格納されている値を用いてプロセッサの電力プロフィールを決定するとしてよい。他の実施形態も説明および請求している。
【選択図】 図１

Description

最新のコンピュータシステムでは、多くの異なる構成要素が結合されて、データ処理、アクセス情報およびその他の多くの公知のタスクを実行する。しかし、コンピュータシステムが動作中であっても、多くの構成要素またはその一部は有用な作業を実行する上で必要ないことがある。これらの構成要素は低電力状態に移行して消費電力を抑制することが多い。これらの構成要素またはデバイスは、特定のチップ、プロセッサ、または、電力を消費する任意のその他のハードウェアエンティティであってよい。また、プロセッサまたはシステムオンチップ（ＳｏＣ）等、単一のチップであれば、構成要素のうち１以上を低電力状態に制御することが可能である。

消費電力分析を実行し易くするべく、デバイスの電力状態を時系列に示した情報である電力プロフィールを求めることがある。多くのシステムでは、デバイスの電力状態を決定するためには、プロセッサは、電力プロフィール情報を取得する命令またはその他の処理を実行するべく、低電力状態以外の状態である必要がある。つまり、プロファイリングの対象であるシステムで実行されるプロファイリングアプリケーションは、イベントをスケジューリングすることで動作している（例えば、割り込みまたはタイマ）。イベントが発生すると、オペレーティングシステムはプロファイリングアプリケーションを呼び出して、プロファイリング対象の挙動を説明するために必要な情報を収集する。しかし、この情報を取得するべくプロセッサを強制的に完全オン状態に維持すると、消費電力を低減するという目的が実現できない。つまり、このようにプラットフォームについて電力情報を定期的に収集すると、利用電力が増加すると共に、プラットフォームの電力挙動が混乱してしまう。

本発明の実施形態に係るタイミングシーケンスを示す図である。

本発明の一実施形態に係る電力プロフィール形成を実行するための方法を説明するフローチャートである。

本発明の一実施形態に係る収集方法を説明するためのフローチャートである。

本発明の実施形態に係るデータ収集を停止する方法を説明するためのフローチャートである。

本発明の実施形態に係る収集したデータを処理する方法を説明するためのフローチャートである。

本発明の実施形態に係るプロセッサを示すブロック図である。

本発明の実施形態に係るシステムを示すブロック図である。

さまざまな実施形態によると、電力プロファイリングは、プロセッサまたはその他のデバイスが不要に低電力状態を終了することを要求することなく、実行可能である。このように、電力プロフィール情報は、消費電力を抑制しつつ（例えば、低電力状態またはスリープ状態にあるプロセッサを電力プロフィール情報の収集に利用することなく）、決定することができる。このように、ある実施形態によると、プロセッサの低電力状態またはスリープ状態を終了させることなくプラットフォーム上で電力プロファイリングを実行することができる方法が提供される。一方で、ユーザは、プラットフォームを非常に正確にプロファイリングすることができる。多くの実施形態では、電力状態の移行を追跡するために用いられるイベントおよびハードウェア電力計測機能を組み合わせて、電力プロファイリングアプリケーションに、非常に正確にプラットフォームの電力使用をプロファイリングさせることができる。本明細書ではプロセッサに関する実施形態例を説明するが、本発明の範囲はこれに限定されないものと理解されたい。電力プロファイリングはさらに、システムの他の構成要素、例えば、システムオンチップ（ＳｏＣ）等に適用され得る。具体的には、ＳｏＣは、常時オンになっておりＳｏＣ全体の電力を管理する小型プロセッサであるシステムコントロールユニット（ＳＣＵ）を含むとしてよい。一部の実施形態は、このプロセッサから電力プロファイラを実行するとしてよく、プラットフォームの任意の構成要素を監視することができる。

プロセッサ電力状態移行イベントは、プロセッサが現在の電力状態をいつ変更したかを追跡するためのイベントである。このような電力状態移行イベントは、アクティブ状態からスリープ状態への移行およびスリープ状態からアクティブ状態への移行を含む。尚、本明細書で用いる場合、「スリープ状態」および「低電力状態」という用語は、デバイスの通常動作状態未満の電力状態を意味する同義語として用いられるとしてよい。このような低電力状態では、例えば、プロセッサに関して、一部の構成要素はオン状態を維持して機能を継続する一方、他の構成要素は電源オフ状態になる。プロセッサが低電力状態になると、電力が節約される。プロセッサは、実行中の作業負荷が当該プロセッサのサポートを必要としない旨を検出すると低電力状態になるようプログラミングされているとしてよく、または、自発的に低電力状態になるとしてよい。つまり、一部の実施形態によると、このようなイベントはソフトウェア（例えば、オペレーティングシステム（ＯＳ））またはハードウェア（例えば、プロセッサ自身）によってトリガされるとしてよい。さまざまな実施形態によると、移行イベントが発生すると、プロファイリングアプリケーションまたはその他のプロファイラに通知が行くとしてよい。

プロセッサの電力状態移行イベントの一例は、Ｌｉｎｕｘ（登録商標）オペレーティングシステム、つまり、電力開始トレースポイント（Ｃ状態エントリトレースポイントとも呼ばれる）に見られる。Ｃ状態エントリトレースポイントは、オペレーティングシステムがプロセッサをスリープ状態に移行させるためにプログラミングする用意をしている場合に実行される。これらのトレースポイントは、カーネル計測メカニズムであり、開発者がカーネルの機能を理解し易いように、カーネルソースコードフロー内のポイントに配置するとしてよい。言い換えると、トレースポイントは、カーネルソースコードにおけるｐｒｉｎｔｆ関数呼び出しと同様である。

トレースポイントによれば、デバイスドライバがトレースポイントに動的に接続される機能が得られる。デバイスドライバがトレースポイントに接続（例えば、登録）されている場合、オペレーティングシステムは、当該トレースポイントを含むカーネルソースコードが実行されると、デバイスドライバ内の関数を呼び出す。言い換えると、Ｃ状態エントリトレースポイントは、プロセッサがスリープ状態に移行する用意をしている場合、電力プロファイリングアプリケーションに通知するために利用され得る。尚、Ｌｉｎｕｘ（登録商標）ＯＳについての実施形態に基づいて説明しているが、本発明の範囲はこれに限定されず、実施形態は他のＯＳで利用し得るものと理解されたい。つまり、より一般的には、実施形態では、例えば、ＯＳで実施されるものとして、電力状態移行時に特定の電力状態情報を収集する。

プロセッサは、所定の低電力状態に移行すると、通常は動作を停止する。言い換えると、命令は実行しない。プロセッサは、低電力状態に移行するようにプログラミングされると、要求されたスリープ状態から逸脱することを選択するとしてよい。言い換えると、オペレーティングシステムがスリープ状態１に移行するようハードウェアをプログラミングする一方、ハードウェアは現在のプラットフォーム動作の情報に基づいてスリープ状態２に移行することを選択するとしてよい。代表的なプロセッサは、Ｉｎｔｅｌ（登録商標）命令セットアーキテクチャ（ＩＳＡ）に基づいたプロセッサであって、複数の低電力状態を可能とするプロセッサを含む。例えば、アドバンスドコンフィグレーションアンドパワーインターフェース（ＡＣＰＩ）規格、例えば、Ｒｅｖ．３．０ｂ（２００６年１０月１０日に公開）に応じたプロセッサ、プロセッサコアに対して複数の低電力状態、いわゆるＣ状態を実現するプロセッサを含む。

一部の実施形態によると、プロセッサは、電力プロフィール情報について、ハードウェアサポートを提供するとしてよい。例えば、マルチコアプロセッサにおいて、各コアは低電力状態レジデンシカウンタ（例えば、Ｃ状態レジデンシカウンタ）を含むとしてよい。低電力状態レジデンシカウンタは、ハードウェアが特定の低電力状態に留まっている時間（例えば、プロセッササイクル）をカウントする単調増加カウンタである。例えば、プロセッサは、特定の低電力状態、例えば、Ｃ３およびＣ６のＣ状態についてのみ、Ｃ状態レジデンシカウンタを提供するとしてよい。このハードウェア監視計測機能によって、ハードウェアの低電力挙動を正確に監視することができる。また、ハードウェアはシステムタイムカウンタを提供するとしてよい。例えば、プロセッサは、コア単位で、タイムスタンプカウンタ（ＴＳＣ）を提供するとしてよい。一部の実施形態では、これらのカウンタは、ハードウェアがアクティブ状態または低電力状態に留まっている場合は、常時カウントしている単調増加カウンタである。

上述したように、従来のプロファイリングアプリケーションは、イベント（例えば、割り込みまたはタイマー）をスケジューリングして、プロファイリングアプリケーションが特定の情報を収集できるようにする。しかしこれでは、電力プロファイリングソフトウェアによって、スリープ状態のプロセッサがスリープ状態を終了させることになってしまう。プロセッサがスリープ状態を終了させると、プロセッサは通常消費電力モードで動作を継続する。言い換えると、イベントをスケジューリングする従来のプロファイリングアプリケーションのために、プロファイリングアプリケーションが実行されていないプラットフォームと比較すると、プラットフォームが消費する電力が増加する（そして、低電力性能情報が混乱してしまう）。実施形態ではプロセッサ電力状態移行イベントをトリガイベントとして利用してプラットフォームに関する電力情報を収集するので、タイマまたは割り込みは回避され、実施形態でデータを取得するのは、プロセッサがアクティブ状態で実行されている場合のみである。このようにして、プロファイリングアプリケーションが、プラットフォームをプロファイリングするために用いられる電力を最小限に抑え、プラットフォームの低電力挙動の混乱を回避する。

一実施形態によると、電力プロフィール情報を収集するためにデバイスドライバを用いることができる。しかし、他の実施形態では、他の特権レベルソフトウェアまたはユーザレベルソフトウェアがこの情報を取得するとしてよい。デバイスドライバは、プロセッサが低電力状態に移行する用意をしている場合に通知されるプロセッサ電力状態移行イベントを利用する。この実施形態では、デバイスドライバは、例えば、収集関数等の関数を、ＯＳ電力状態移行コードに登録する。例えば、一実施形態において、このコードは、Ｌｉｎｕｘ（登録商標）のＣ状態エントリトレースポイントであってよく、この登録によって、Ｃ状態エントリトレースポイントは、オペレーティングシステムがプロセッサをスリープ状態に移行させると判断する度に、登録された関数を呼び出す。

ＯＳがＣ状態エントリトレースポイントを実行すると、デバイスドライバの収集関数が、一実施形態によると、システムクロックおよびプロセッサのスリープ状態レジデンシカウンタを読み出して、アクセスした情報を保存する。例えば、第１の情報収集は、第１のＣ状態エントリトレースポイントにおいて発生し、サンプルＡを取得するとしてよい。この次にＣ状態エントリトレースポイントが実行されると、デバイスドライバの関数は、同じ情報をサンプルＢについて収集する。この処理は、データ収集段階において継続して行われる。性能コストは最小限に抑えられるとしてよい。これは、一回のＣ状態エントリトレースポイントにおいて読み出されるレジスタは一握りのみのためである。

図１は、本発明の実施形態に係るタイミングシーケンスを示す図である。ｔ０において、Ｃ状態エントリトレースポイントが実行され、サンプルＡが収集される。この後、プロセッサはスリープ状態になる。尚、このスリープ状態は、オペレーティングシステムがプログラミングした状態とは異なる状態であるとしてよい。ｔ１において、ハードウェアがスリープ状態を終了して、通常の動作に戻り、消費電力も通常に戻るイベントが発生する。スリープ状態を終了させる当該イベント（例えば、割り込みまたはタイマ切れ）は、電力プロファイラがスケジューリングしたものではなかった。ｔ２において、Ｃ状態エントリトレースポイントが再度実行され、サンプルＢを収集する。尚、データの収集は、トレースポイントにトリガされる代わりに、ＯＳまたはプラットフォームロジックの別の通知メカニズムに応じて実施されるとしてもよい。

データの収集が終了した後、収集されたデータを、例えば、プロファイリングアプリケーションによって処理することができる。サンプルＢのシステムクロック値とサンプルＡのシステムクロック値との間の差分を算出する。この差分は、２つの電力状態移行イベントの間に実際に経過した時間に対応するとしてよい。また、サンプルＡとサンプルＢとの間のレジデンシカウンタの差分も算出して、第１の電力状態移行イベントについての低電力状態（およびその長さまたは期間、さまざまな実施形態によると、サイクル単位で計測するとしてもよいし、時間で計測するとしてもよい）を決定することができる。

例えば、Ｃ３状態について１つのレジデンシカウンタ、そして、Ｃ６状態について１つのレジデンシカウンタの２つのレジデンシカウンタがあると仮定する。また、サンプルＡおよびサンプルＢにおいて、表１に示す値が収集されたと仮定する。

このデータからは、電力プロファイラは、どのスリープ状態に移行したか（この場合には、Ｃ３カウンタが変化していないのでＣ６状態）、スリープ状態で動作した時間（Ｃ６状態において３００カウント）、および、通常電力レベルでの動作時間（２００カウント、総時間−スリープ時間に等しい）を正確に決定することができる。

上述したように、さまざまなシステムに実施形態を組み込むことが可能であり、複数の異なる構成要素を用いて実施形態を実施し得る。一部の実施形態によると、一連の性能分析ツールの一部として方法を実施し得る。より具体的に説明すると、システムの構成要素における電力状態移行に関する情報を取得して当該データを処理することができるツールの電力プロファイラに実施形態を組み込むとしてよい。そして、このデータを用いることで、ユーザ、コンパイラ、オペレーティングシステムまたはその他の同様のエンティティ等、所定のエンティティによる分析を実行できるようにするとしてよい。本明細書で説明した実施形態は、マルチコアプロセッサ等のプロセッサで発生する電力移行に関する実施形態である。しかし、この特定の実施例で説明しているが、本発明の範囲はこれに限定されるものではなく、他の実施形態では、システムの他の構成要素、例えば、チップセット、メモリ、周辺機器等もまた、本発明の実施形態に係る電力監視方式によって有益な効果が得られると理解されたい。

図２を参照すると、本発明の実施形態に係る電力プロファイリング方法の概要を示すフローチャートが図示されている。図２に示すように、方法１０は、性能分析部、より具体的には、性能分析部の電力プロファイラで実行され得るが、電力プロファイラのデバイスドライバを初期化することから開始されるとしてよい（ブロック２０）。このようなデバイスドライバの初期化によって、当該デバイスドライバに対応付けられている低レベル機能、例えば、さまざまなプロセッサレジスタ等の特権リソースにアクセスする機能がイネーブルされるとしてよい。続いて、ブロック３０に進み、例えば、このドライバの収集関数を登録して、電力状態移行イベントの際に呼び出すことができるようにするとしてよい。一例を挙げると、電力状態移行イベントを処理するＯＳモジュールをアップデートして、この収集関数を登録することができる。Ｌｉｎｕｘ（登録商標）のＯＳについての特定の一実施形態において、この収集関数は、電力移行に関する計測処理を実行するトレースポイントに登録することができる。

さらに図２を参照しつつ説明すると、続いて、収集関数によって取得される電力状態移行情報を格納するためのバッファを割り当てるとしてよい（ブロック４０）。一例を挙げると、このバッファはプロセッサのキャッシュメモリ、例えば、最終レベルキャッシュに設定されるとしてよい。したがって、この時点において、電力プロファイラは、電力状態移行イベントの発生に応じて、収集処理を実行して電力状態移行情報を取得するように構成されている。

したがって、電力状態移行イベントについて収集処理を行うブロック５０に進む。取得した対応する情報をバッファに格納するとしてよい。さまざまな実施形態によると、収集処理は、低電力モードの開始に対応する電力状態移行イベントに対して実行されるとしてよい。これは、さまざまな処理がＯＳによって実行されて、プロセッサが低電力モードに入る準備をして、低電力モードへの移行を可能にするためである。しかし、これに代えて、他の実施形態によると、この情報は、低電力モードを終了する際に取得されるとしてもよい。いずれのイベントにしても、従来の電力プロファイラのようにシステム動作中のランダムなタイミング（例えば、割り込みまたはタイマに応じて）ではなく、プロファイリングウィンドウにおいて（特定の方向の、つまり、低電力モード開始時または低電力モード終了時の）どの電力状態移行イベントにおいても情報を画定的に収集し得ることに留意されたい。この収集処理は、プロファイリングウィンドウに対応する期間にわたって（所定の方向の）多くの連続した電力状態移行イベントについて実行され得る。プロファイリングウィンドウは、さまざまな実施形態によると、バラツキが大きい。例えば、収集処理は、一秒と短くてもよいが、通常は作業負荷がシステムを駆動している限り（通常は数分であるが、まれに数時間に及ぶ）において、実行される。

このように、複数の連続した電力状態移行イベントで得られる情報は、収集ウィンドウにおいて収集され得る。本発明の範囲はこれに限定されないが、さまざまな実施形態によると、この移行イベントに関して収集される情報は、タイムスタンプカウンタ等のシステムレベルカウンタを含むさまざまなカウンタの値、および、プロセッサ内で利用可能な複数の異なる低電力状態に対応付けられている１以上のカウンタの値を含むとしてよい。例えば、Ｃ状態はそれぞれ、機械固有レジスタ（ＭＳＲ）が対応付けられており、当該レジスタを用いて所与の低電力モードの期間をカウントすることができるとしてよい。各収集処理の後、収集処理が完了したか否かを判断するとしてよい（ダイヤモンド６０）。例えば、さまざまな実施形態によると、電力プロファイラは、所定の時間にわたって、または、所定数の電力状態イベントについて等、データを収集するように構成されるとしてよい。収集が完了していなければ、ブロック５０に戻る。

収集が完了していれば、ブロック７０に進み、収集処理で取得した電力状態移行情報を処理してユーザに報告するとしてよい。尚、図２の実施形態では比較的概略的なレベルで説明したが、複数の異なる実施形態において詳細な内容および変形例はさまざまなものが実施可能であると理解されたい。

図３を参照すると、本発明の一実施形態に係る収集方法を説明するためのフローチャートが図示されている。上述したように、一部の実施形態によると、当該収集方法は、ＭＳＲ、システムカウンタ等の特権リソースに存在する情報にアクセス可能なドライバに対する関数呼び出しによって実施されるとしてよい。しかし、他の実施形態によると、収集処理はユーザモードで実行され得ると理解されたい。図３において、方法１００は、ブロック１１０でシステムクロックを読み出すことによって開始されるとしてよい。さまざまな実施形態によると、システムクロックは、低電力状態に入るコアに存在するタイムスタンプカウンタに対応するとしてよい。このため、プロセッサはコア単位で電力管理を行うように制御され得るので、収集処理はコアの粒度で実行され得ると理解されたい。しかし、他の実施形態によると、プロセッサは、パッケージレベルでのみ電力管理を実現するので、このような実施形態では、情報はパッケージ単位で取得されるとしてよい。さらに別の実施例によると、コアレベルおよびパッケージレベルの電力状態情報の組み合わせを取得することもできる。

さらに図３を参照すると、読み出したシステムクロック値は、バッファに格納されるとしてよい（ブロック１２０）。より具体的には、収集処理毎に、バッファのエントリが割り当てられ、このシステムクロック値を、利用可能な各低電力状態に対応付けられている単調カウンタの値と共に格納するために用いることができる。

このため、図３からさらに分かるように、プロセッサで利用可能なスリープ状態毎に（ダイヤモンド１３０での決定に応じて）、その低電力状態についての対応するレジデンシカウンタの読出処理を含むループを実行する（ブロック１４０）。当該読出処理は、当該低電力状態のＭＳＲを読み出すことによって実行されるとしてよい。その後、カウンタ値をバッファ内のエントリに書き込む（ブロック１５０）。このように、利用可能な低電力状態についてカウンタを全て読み出すと、方法１００は終了するとしてよい。したがって、電力状態移行イベントについての収集処理が完了し、取得された情報はバッファのエントリに格納される。尚、図３の実施形態ではこの特定の情報について関連付けて説明しているが、本発明の範囲はこれに限定されるものではなく、他の実施形態では、追加で情報を取得するとしてもよいし、別の情報を取得してもよいものと理解されたい。例えば、一実施形態によると、追加で取得する情報には、ＯＳが要求した低電力状態（ハードウェアが実際に利用している低電力状態でない場合もある）が含まれるとしてよい。

図３を参照しつつ説明したような収集処理は、何度も実行するとしてよい。所望の量のデータを収集すると、電力プロファイラは、さまざまな処理を実行して、収集したデータにさらに処理を実行する準備をすると共にデータ収集を終了させるとしてよい。図４を参照すると、本発明の実施形態に係るデータ収集を終了させる方法を説明するためのフローチャートが図示されている。図４に図示しているように、方法２００は、デバイスドライバをアンロードする処理においてさまざまな処理を実行するとしてよい（ブロック２１０）。概して、ドライバは、アンロード処理の前に、データをフラッシュして（例えば、ディスクに書き込んで）、バッファを空にして、収集関数の登録を解除する。これらのステップ（ドライバをアンロードするステップを除く）は、収集処理が終了する度に実行され得る。ドライバは、「ｉｎｓｍｏｄ」コマンドまたは「ｒｍｍｏｄ」コマンドを用いて手動で挿入および削除が可能であり（Ｌｉｎｕｘ（登録商標）のＯＳの場合）、または、ドライバは、ブート期間に自動的にロードして決して削除されないとしてもよい。また、一部のＯＳでは、デバイスドライバを、特定のユーザモードのシステム呼び出しでロードして、アンロードすることができる。このような実施例では、（１）ドライバをロードして、（２）時間が経過すると、収集処理を実行して、（３）所望に応じてステップ（２）を繰り返し、（４）ドライバをアンロードするという順序になる。また、一部の実施例によると、収集したデータは、収集処理を制御するユーザレベルコードに戻して、ユーザレベルコードによってファイルに保存されることに留意されたい。言い換えると、ドライバは、実際にはファイルへの書き込みを実行せず、バッファをユーザレベルコードに渡して、収集処理中にユーザレベルコードがデータをファイルに書き込む。Ｌｉｎｕｘ（登録商標）のＯＳであれば、この種類のデバイスドライバは「キャラクタ」ドライバと呼ばれる。

図から分かるように、当該方法は、バッファがファイルに書き込まれるブロック２１５で開始される。例えば、バッファは、上述したように、プロセッサのキャッシュ内の一時ストレージに位置しているとしてよく、ファイルシステムに転送することができ、例えば、後でアクセスするべくデータファイル２２０としてシステムメモリに格納されるとしてよい。続いて、ブロック２２５に進み、バッファを解放して、ＯＳのリソースプールに戻すとしてよい。最後に、ブロック２３０に進み、収集関数の登録を解除するとしてよい。つまり、収集関数を登録していたＯＳトレースポイントまたは他のカーネル（または、他の位置）は登録を解除するので、当該関数は電力状態移行イベントにおいて呼び出されることがなくなる。この時点において、デバイスドライバはアンロードされるとしてよい。

このように、この時点において、所望の電力状態情報が取得されており、さらに処理することで、システムの分析ツール等のユーザまたはその他のエンティティによる分析が可能となる。図５を参照すると、本発明の実施形態に係る収集したデータを処理する方法を説明するためのフローチャートが図示されている。図５に図示されているように、方法２５０は、データファイル２２０を処理することによって開始されるとしてよい（ブロック２６０）。一実施形態によると、この処理は、データとプロセッサがアクティブ状態に戻った理由の説明（例えば、タイマまたは割り込み、または、アクティブ状態へ戻るきっかけとなったイベントに至るソースコードコールスタックの説明）とを対応付ける処理を含むとしてよい。この時点において、データは、例えば、電力プロファイラのユーティリティによって処理すべき形式になっている。

さらに図５を参照して説明すると、ブロック２６５に進んで、第１の電力状態移行イベントの収集処理に対応する第１のサンプルをデータファイルから読み出すとしてよい。そして、ダイヤモンド２７０での判断に応じて、ファイル内の追加サンプル毎にループを実行するとしてよい。特に、このループでは、ブロック２７５において、現在サンプルと過去サンプルとの間の経過時間を算出することができる（ブロック２７５）。また、ブロック２８０において、現在サンプルのレジデンシカウントのそれぞれと、過去サンプルのレジデンシカウントとの差分も算出するとしてよい。ブロック２９０において、算出結果をテーブルに格納するとしてよい。このため、互いに隣接する一対のサンプル毎について、低電力状態の前回の開始タイミングと低電力状態の今回の開始タイミングとの間に経過した時間（システムクロック数で表される差分によって決まる）を決定することができる。さらに、対応するレジデンシカウントの差分に基づき、前回の低電力移行での移行先である所与の低電力状態を、この低電力状態の期間の長さを決定するとともに、決定することができる。このように、一対のサンプル毎に、２つの電力状態イベントの間の経過時間を、前回の低電力移行の期間および種類と共に、決定することができる。このため、これらの値は、他のレジデンシカウンタの差分（全てゼロに等しいとしてよい）と共にテーブルエントリに格納されるとしてよい。このため、このループはデータファイル内の追加サンプル毎に実行される。

この処理が完了すると、ブロック２９５に進み、結果をユーザに出力するとしてよい。例えば、この出力は、収集処理の間の動作を説明するタイムラインとしてもよいし、または、ある状態を利用した頻度を説明するヒストグラムとして表示することもできる。幾つかの例によると、出力は、プリントアウトされるとしてもよいし、または、プラットフォームのディスプレイのユーザが見ることが可能なディスプレイであってよい。さらに、テーブルに格納されている結果はまた、他の分析ツールおよび制御ツール、例えば、コンパイラ、ＯＳまたはその他のツールで利用されるべく、機械可読媒体形式で利用可能であるとしてよい。一例を挙げると、テーブル内の情報は、人間が読み出し可能な形式で、および／または、コンピュータが読み出し可能な形式で、ＯＳエンティティに供給されるとしてよい。この情報は、ＯＳ開発者および／または動作しているＯＳ自体によって、電力管理に関する判断処理についての性能を改善するべく、利用されるとしてよい。例えば、開発者は、受信した情報に基づいて、ＯＳの電力管理コードを更新するとしてよい。

このような一例によると（上述したように）、プロセッサハードウェアは、ＯＳが要求した低電力状態とは異なる低電力状態に入ることを選択することが可能である。テーブルから利用可能な情報、つまり、所与の間隔で開始された特定の低電力状態の期間および種類に基づき、ＯＳエンティティは、自身が発行した低電力状態移行要求は受け入れられず、プロセッサが選択した別の低電力状態が優先されたと決定することができる。この情報に基づき、ＯＳエンティティは、電力管理アルゴリズムおよび／または電力管理ヒューリスティックスを修正して、例えば、今後新しいＯＳがリリースされる場合には、別の電力管理判断がなされるようにしてもよい。さらに、この情報がコンピュータ可読形式で、プラットフォームで実行される現在のＯＳのインスタンス化に供給される実施形態では、ＯＳのインスタンス化は、リアルタイムで、制御アルゴリズムを更新するとしてよく、その後実行する際にはこの情報に基づいてより良い判断を行うとしてよい。図５の実施形態ではこの特定の実施形態を図示しているが、本発明の範囲はこれに限定されるものではないと理解されたい。

図６を参照すると、本発明の実施形態に係るプロセッサのブロック図が図示されている。図６に図示しているように、プロセッサ４００は、複数のコア４１０_ａ−４１０_ｎを含むマルチコアプロセッサであってよい。一実施形態によると、各コアは、例えば、フロントエンドユニットと、アウトオブオーダロジックと、実行ユニットと、リタイヤメントロジック等のバックエンドユニットとを含むパイプラインを持つとしてよい。さらに、上述したように、各コアは、機械固有レジスタ、性能モニタ等のレジスタとして実現され得るさまざまなカウンタを含むとしてよい。図６の実施形態によると、これらのカウンタはタイムスタンプカウンタ４１２を含む。カウンタ４１２は、プロセッサの公称周波数で、例えば、マシンサイクルとして、カウントするとしてよく、一部の実施形態によると、コア（または、電力がプロセッサに供給されている限りにおいて、プロセッサ）の電力状態および複数の低電力カウンタ４１４_０−ｘに関係なく常にカウントしているとしてよい。各低電力カウンタは、コアが所与の低電力状態にあるサイクルをカウントする。

さまざまなコアが、インターコネクト４１５を介して、さまざまな構成要素を含む非コア部４２０に結合されているとしてよい。図示されているように、非コア部４２０は、最終レベルキャッシュである共有キャッシュ４３０を含むとしてよい。また、非コア部は、集積化メモリコントローラ４４０、さまざまなインターフェース４５０、および、電力制御ユニット４５５を含むとしてよい。一部の実施形態では、電力制御ユニット４５５を用いて、ＯＳには関係なく、低電力状態を開始および終了するとしてよい。図示されているように、プロセッサ４００は、例えば、メモリバスを介して、システムメモリ４６０と通信するとしてよい。また、インターフェース４５０によって、さまざまなチップ外構成要素、例えば、周辺機器、大容量ストレージ等に接続を行うことができる。図６の実施形態ではこの特定の実施例で図示しているが、本発明の範囲はこれに限定されない。

実施形態は多くの異なる種類のシステムで実現され得る。図７を参照すると、本発明の実施形態に係るシステムを示すブロック図が図示されている。図７に示すように、マルチプロセッサシステム５００は、ポイント・ツー・ポイントインターコネクトシステムであり、ポイント・ツー・ポイントインターコネクト５５０を介して結合されている第１のプロセッサ５７０および第２のプロセッサ５８０を含む。図７に示すように、プロセッサ５７０および５８０はそれぞれ、マルチコアプロセッサであってよく、第１および第２のプロセッサコア（つまり、プロセッサコア５７４ａおよび５７４ｂ、ならびに、プロセッサコア５８４ａおよび５８４ｂ）を含むが、プロセッサにははるかに多くのコアが存在するとしてもよい。各コアは、上述したように、さまざまなレジデンシカウンタおよびシステムカウンタを含むとしてよい。

さらに図７を参照しつつ説明すると、第１のプロセッサ５７０はさらに、メモリコントローラハブ（ＭＣＨ）５７２ならびにポイント・ツー・ポイント（Ｐ−Ｐ）インターフェース５７６および５７８を含む。同様に、第２のプロセッサ５８０は、ＭＣＨ５８２ならびにＰ−Ｐインターフェース５８６および５８８を含む。図７に示すように、ＭＣＨ５７２および５８２によって、プロセッサが対応するメモリ、つまり、メモリ５３２およびメモリ５３４に結合されている。メモリ５３２および５３４は、対応するプロセッサにローカルに接続されているメインメモリ（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ））の一部であってよい。第１のプロセッサ５７０および第２のプロセッサ５８０は、Ｐ−Ｐインターコネクト５５２および５５４を介して、チップセット５９０に結合されるとしてよい。図７に示すように、チップセット５９０は、Ｐ−Ｐインターフェース５９４および５９８を含む。

さらに、チップセット５９０は、チップセット５９０と高性能グラフィクスエンジン５３８とをＰ−Ｐインターコネクト５３９を介して結合するインターフェース５９２を含む。一方、チップセット５９０は、インターフェース５９６を介して第１のバス５１６に結合されるとしてよい。図７に示すように、さまざまな入出力（Ｉ／Ｏ）デバイス５１４は、バスブリッジ５１８と共に、第１のバス５１６に結合されているとしてよい。バスブリッジ５１８は、第１のバス５１６を第２のバス５２０に結合する。第２のバス５２０には、例えば、本発明の実施形態に応じた電力プロファイリング処理を実行するべく、さまざまなデバイスが結合されているとしてよい。例えば、キーボード／マウス５２２、通信デバイス５２６、および、コード５３０を含む、ディスクドライブまたはその他の大容量ストレージデバイス等のデータストレージユニット５２８が結合されているとしてよい。さらに、第２のバス５２０には音声Ｉ／Ｏ５２４が結合されているとしてよい。

実施形態は、コードで実現するとしてよく、命令を格納しており、当該命令を実行するようシステムをプログラミングするために用いられる格納媒体に格納するとしてよい。格納媒体は、これらに限定されないが、フロッピー（登録商標）ディスク、光ディスク、光ディスク、ソリッドステートドライブ（ＳＳＤ）、コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスクリライタブル（ＣＤ−ＲＷ）および光磁気ディスクを含むディスク、リードオンリーメモリ（ＲＯＭ）等の半導体デバイス、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）等のランダムアクセスメモリ（ＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、消去可能プログラム可能リードオンリーメモリ（ＥＰＲＯＭ）、フラッシュメモリ、電気的消去可能プログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、磁気カードまたは光カード、または、電子命令の格納に適した任意のその他の種類の媒体等の任意の種類の非一時的格納媒体を含むとしてよい。

本発明を限られた数の実施形態に基づいて説明したが、当業者であれば、開示内容から数多くの変形例および変更例に想到するであろう。添付した特許請求の範囲はこのような変形例および変更例をすべて、本発明の真の意図および範囲に含むものとする。

Claims (20)

1. システムのコンポーネントにおいて電力状態移行イベントが発生すると呼び出される電力プロファイラを登録する段階と、
   前記電力状態移行イベントに関する情報を格納するバッファを割り当てる段階と、
   前記電力状態移行イベントが発生すると、システムカウンタ値および前記コンポーネントの１以上の低電力状態のそれぞれについてのカウンタ値を読み出して、前記システムカウンタ値および１以上の前記カウンタ値を前記バッファに書き込む段階と
   を備える方法。
2. 割り込みまたはタイマ切れが発生しなくても、前記システムカウンタ値および前記１以上のカウンタ値を読み出す段階をさらに備える請求項１に記載の方法。
3. オペレーティングシステム（ＯＳ）から前記電力プロファイラのデバイスドライバの収集関数へと制御を移行して、前記システムカウンタ値および前記１以上のカウンタ値を読み出す段階をさらに備える請求項２に記載の方法。
4. 前記収集関数への呼び出しを前記ＯＳのトレースポイントに挿入する段階をさらに備える請求項３に記載の方法。
5. 前記システムカウンタ値および前記１以上のカウンタ値を複数の電力状態移行イベントのそれぞれについて読み出して、前記複数の電力状態移行イベントのそれぞれについて、前記システムカウンタ値および前記１以上のカウンタ値を前記バッファに書き込む段階をさらに備える請求項１または２に記載の方法。
6. 第１の電力状態移行イベントと第２の電力状態移行イベントとの間の経過時間を、前記第１の電力状態移行イベントおよび前記第２の電力状態移行イベントにおいて読み出した前記システムカウンタ値に基づいて決定し、前記第１の電力状態移行イベントの後に開始された低電力状態の期間および種類を、前記第１の電力状態移行イベントおよび前記第２の電力状態移行イベントにおいて読み出された複数の前記カウンタ値に基づいて決定する段階をさらに備える請求項５に記載の方法。
7. 前記第１の電力状態移行イベントおよび前記第２の電力状態移行イベントにおいて読み出された前記システムカウンタ値の差分を決定する段階をさらに備える請求項６に記載の方法。
8. 前記低電力状態の期間および種類を含む情報を、前記第１の電力状態移行イベントを要求したオペレーティングシステムに供給する段階をさらに備える請求項６または７に記載の方法。
9. 前記オペレーティングシステムの挙動を修正する段階をさらに備え、
   前記オペレーティングシステムの要求では、前記第１の電力状態移行イベントは別の種類であり、前記コンポーネントは、前記要求を無効にして、前記低電力状態の種類に対応する別の低電力状態に移行する請求項８に記載の方法。
10. 前記経過時間、ならびに、前記低電力状態の期間および種類をテーブルに記録する段階をさらに備える請求項６から９のいずれか一項に記載の方法。
11. コンピュータに、
    マルチコアプロセッサのコアについて第１の方向の複数の電力状態移行イベントのそれぞれが発生すると、タイマ切れまたは割り込みのトリガが発生しなくても、前記コアのシステムカウンタの値および前記コアの複数の低電力カウンタのそれぞれの値を読み出す手順と、
    前記複数の電力状態移行イベントのそれぞれについて、前記システムカウンタの値および前記複数の低電力カウンタのそれぞれの値を前記マルチコアプロセッサのストレージに格納する手順と、
    前記複数の電力状態移行イベントの後、前記ストレージにアクセスして、格納されている前記システムカウンタの値および格納されている前記複数の低電力カウンタのそれぞれの値を用いて、前記マルチコアプロセッサの電力プロフィールを決定する手順と
    を実行させるためのプログラム。
12. 前記コンピュータにさらに、第１の電力状態移行イベントと第２の電力状態移行イベントとの間の経過時間を、前記第１の電力状態移行イベントおよび前記第２の電力状態移行イベントにおいて読み出された前記システムカウンタの値に基づいて決定し、前記第１の電力状態移行イベントの後で開始された低電力状態の期間および種類を、前記第１の電力状態移行イベントおよび前記第２の電力状態移行イベントにおいて読み出された前記複数の低電力カウンタのそれぞれの値に基づいて、決定する手順を実行させる請求項１１に記載のプログラム。
13. 前記コンピュータにさらに、前記経過時間ならびに前記低電力状態の期間および種類をテーブルに記録して、前記低電力状態の期間および種類を含む情報を、前記第１の電力状態移行イベントを要求したオペレーティングシステムに提供する手順を実行させる請求項１２に記載のプログラム。
14. 前記コンピュータにさらに、前記複数の電力状態移行イベントのそれぞれが発生すると、前記システムカウンタの値および前記複数の低電力カウンタのそれぞれの値を読み出すべく、通知メカニズムから電力プロファイラの関数を呼び出す手順を実行させる請求項１３に記載のプログラム。
15. 前記コンピュータにさらに、前記システムカウンタの値および前記複数の低電力カウンタのそれぞれの値を格納するバッファを前記コンピュータが割り当てる手順を実行させる請求項１４に記載のプログラム。
16. 前記コンピュータにさらに、前記システムカウンタの値および前記複数の低電力カウンタのそれぞれの値を読み出すべく、オペレーティングシステムから電力プロファイラのデバイスドライバの収集関数へと制御を移行する手順を実行させる請求項１１または１２に記載のプログラム。
17. それぞれがフロントエンドロジック、アウトオブオーダロジックおよびバックエンドロジックを含む複数のコアと、サイクルのカウントを格納するタイムスタンプカウンタと、それぞれが一のコアが対応する低電力状態であるサイクルをカウントする複数の低電力状態カウンタとを有するマルチコアプロセッサと、
    前記マルチコアプロセッサの１以上の低電力状態のそれぞれについて前記タイムスタンプカウンタおよび前記複数の低電力状態カウンタを読み出して、前記タイムスタンプカウンタの値および前記複数の低電力状態カウンタの値をバッファに書き込む電力プロファイラと
    を備えるシステム。
18. 前記電力プロファイラは、第１の方向の連続した複数の電力状態移行イベントについて、前記タイムスタンプカウンタおよび前記複数の低電力状態カウンタを読み出す請求項１７に記載のシステム。
19. 前記電力プロファイラは、タイマ切れまたは割り込みのトリガが発生しなくても、前記タイムスタンプカウンタおよび前記複数の低電力状態カウンタを読み出す請求項１８に記載のシステム。
20. 前記電力プロファイラは、オペレーティングシステムの通知メカニズムによって呼び出される収集関数を含み、
    前記通知メカニズムは、前記１以上の低電力状態のそれぞれに移行する電力状態移行イベントにおいて実行される請求項１７から１９のいずれか一項に記載のシステム。

Images