システムのコンポーネントにおいて電力状態移行イベントが発生すると呼び出される電力プロファイラを登録する段階と、前記電力状態移行イベントに関する情報を格納するバッファを割り当てる段階と、前記電力状態移行イベントが発生すると、システムカウンタ値および前記コンポーネントの1以上の低電力状態のそれぞれについてのカウンタ値を読み出して、前記システムカウンタ値および1以上の前記カウンタ値を前記バッファに書き込む段階とを備える方法。割り込みまたはタイマ切れが発生しなくても、前記システムカウンタ値および前記1以上のカウンタ値を読み出す段階をさらに備える請求項1に記載の方法。オペレーティングシステムOSから前記電力プロファイラのデバイスドライバの収集関数へと制御を移行して、前記システムカウンタ値および前記1以上のカウンタ値を読み出す段階をさらに備える請求項2に記載の方法。前記収集関数への呼び出しを前記OSのトレースポイントに挿入する段階をさらに備える請求項3に記載の方法。前記システムカウンタ値および前記1以上のカウンタ値を複数の電力状態移行イベントのそれぞれについて読み出して、前記複数の電力状態移行イベントのそれぞれについて、前記システムカウンタ値および前記1以上のカウンタ値を前記バッファに書き込む段階をさらに備える請求項1または2に記載の方法。第1の電力状態移行イベントと第2の電力状態移行イベントとの間の経過時間を、前記第1の電力状態移行イベントおよび前記第2の電力状態移行イベントにおいて読み出した前記システムカウンタ値に基づいて決定し、前記第1の電力状態移行イベントの後に開始された低電力状態の期間および種類を、前記第1の電力状態移行イベントおよび前記第2の電力状態移行イベントにおいて読み出された複数の前記カウンタ値に基づいて決定する段階をさらに備える請求項5に記載の方法。前記第1の電力状態移行イベントおよび前記第2の電力状態移行イベントにおいて読み出された前記システムカウンタ値の差分を決定する段階をさらに備える請求項6に記載の方法。前記低電力状態の期間および種類を含む情報を、前記第1の電力状態移行イベントを要求したオペレーティングシステムに供給する段階をさらに備える請求項6または7に記載の方法。前記オペレーティングシステムの挙動を修正する段階をさらに備え、前記オペレーティングシステムの要求では、前記第1の電力状態移行イベントは別の種類であり、前記コンポーネントは、前記要求を無効にして、前記低電力状態の種類に対応する別の低電力状態に移行する請求項8に記載の方法。前記経過時間、ならびに、前記低電力状態の期間および種類をテーブルに記録する段階をさらに備える請求項6から9のいずれか一項に記載の方法。コンピュータに、マルチコアプロセッサのコアについて第1の方向の複数の電力状態移行イベントのそれぞれが発生すると、タイマ切れまたは割り込みのトリガが発生しなくても、前記コアのシステムカウンタの値および前記コアの複数の低電力カウンタのそれぞれの値を読み出す手順と、前記複数の電力状態移行イベントのそれぞれについて、前記システムカウンタの値および前記複数の低電力カウンタのそれぞれの値を前記マルチコアプロセッサのストレージに格納する手順と、前記複数の電力状態移行イベントの後、前記ストレージにアクセスして、格納されている前記システムカウンタの値および格納されている前記複数の低電力カウンタのそれぞれの値を用いて、前記マルチコアプロセッサの電力プロフィールを決定する手順とを実行させるためのプログラム。前記コンピュータにさらに、第1の電力状態移行イベントと第2の電力状態移行イベントとの間の経過時間を、前記第1の電力状態移行イベントおよび前記第2の電力状態移行イベントにおいて読み出された前記システムカウンタの値に基づいて決定し、前記第1の電力状態移行イベントの後で開始された低電力状態の期間および種類を、前記第1の電力状態移行イベントおよび前記第2の電力状態移行イベントにおいて読み出された前記複数の低電力カウンタのそれぞれの値に基づいて、決定する手順を実行させる請求項11に記載のプログラム。前記コンピュータにさらに、前記経過時間ならびに前記低電力状態の期間および種類をテーブルに記録して、前記低電力状態の期間および種類を含む情報を、前記第1の電力状態移行イベントを要求したオペレーティングシステムに提供する手順を実行させる請求項12に記載のプログラム。前記コンピュータにさらに、前記複数の電力状態移行イベントのそれぞれが発生すると、前記システムカウンタの値および前記複数の低電力カウンタのそれぞれの値を読み出すべく、通知メカニズムから電力プロファイラの関数を呼び出す手順を実行させる請求項13に記載のプログラム。前記コンピュータにさらに、前記システムカウンタの値および前記複数の低電力カウンタのそれぞれの値を格納するバッファを前記コンピュータが割り当てる手順を実行させる請求項14に記載のプログラム。前記コンピュータにさらに、前記システムカウンタの値および前記複数の低電力カウンタのそれぞれの値を読み出すべく、オペレーティングシステムから電力プロファイラのデバイスドライバの収集関数へと制御を移行する手順を実行させる請求項11または12に記載のプログラム。それぞれがフロントエンドロジック、アウトオブオーダロジックおよびバックエンドロジックを含む複数のコアと、サイクルのカウントを格納するタイムスタンプカウンタと、それぞれが一のコアが対応する低電力状態であるサイクルをカウントする複数の低電力状態カウンタとを有するマルチコアプロセッサと、前記マルチコアプロセッサの1以上の低電力状態のそれぞれについて前記タイムスタンプカウンタおよび前記複数の低電力状態カウンタを読み出して、前記タイムスタンプカウンタの値および前記複数の低電力状態カウンタの値をバッファに書き込む電力プロファイラとを備えるシステム。前記電力プロファイラは、第1の方向の連続した複数の電力状態移行イベントについて、前記タイムスタンプカウンタおよび前記複数の低電力状態カウンタを読み出す請求項17に記載のシステム。前記電力プロファイラは、タイマ切れまたは割り込みのトリガが発生しなくても、前記タイムスタンプカウンタおよび前記複数の低電力状態カウンタを読み出す請求項18に記載のシステム。前記電力プロファイラは、オペレーティングシステムの通知メカニズムによって呼び出される収集関数を含み、前記通知メカニズムは、前記1以上の低電力状態のそれぞれに移行する電力状態移行イベントにおいて実行される請求項17から19のいずれか一項に記載のシステム。さまざまな実施形態によると、電力プロファイリングは、プロセッサまたはその他のデバイスが不要に低電力状態を終了することを要求することなく、実行可能である。このように、電力プロフィール情報は、消費電力を抑制しつつ例えば、低電力状態またはスリープ状態にあるプロセッサを電力プロフィール情報の収集に利用することなく、決定することができる。このように、ある実施形態によると、プロセッサの低電力状態またはスリープ状態を終了させることなくプラットフォーム上で電力プロファイリングを実行することができる方法が提供される。一方で、ユーザは、プラットフォームを非常に正確にプロファイリングすることができる。多くの実施形態では、電力状態の移行を追跡するために用いられるイベントおよびハードウェア電力計測機能を組み合わせて、電力プロファイリングアプリケーションに、非常に正確にプラットフォームの電力使用をプロファイリングさせることができる。本明細書ではプロセッサに関する実施形態例を説明するが、本発明の範囲はこれに限定されないものと理解されたい。電力プロファイリングはさらに、システムの他の構成要素、例えば、システムオンチップSoC等に適用され得る。具体的には、SoCは、常時オンになっておりSoC全体の電力を管理する小型プロセッサであるシステムコントロールユニットSCUを含むとしてよい。一部の実施形態は、このプロセッサから電力プロファイラを実行するとしてよく、プラットフォームの任意の構成要素を監視することができる。プロセッサ電力状態移行イベントは、プロセッサが現在の電力状態をいつ変更したかを追跡するためのイベントである。このような電力状態移行イベントは、アクティブ状態からスリープ状態への移行およびスリープ状態からアクティブ状態への移行を含む。尚、本明細書で用いる場合、スリープ状態および低電力状態という用語は、デバイスの通常動作状態未満の電力状態を意味する同義語として用いられるとしてよい。このような低電力状態では、例えば、プロセッサに関して、一部の構成要素はオン状態を維持して機能を継続する一方、他の構成要素は電源オフ状態になる。プロセッサが低電力状態になると、電力が節約される。プロセッサは、実行中の作業負荷が当該プロセッサのサポートを必要としない旨を検出すると低電力状態になるようプログラミングされているとしてよく、または、自発的に低電力状態になるとしてよい。つまり、一部の実施形態によると、このようなイベントはソフトウェア例えば、オペレーティングシステムOSまたはハードウェア例えば、プロセッサ自身によってトリガされるとしてよい。さまざまな実施形態によると、移行イベントが発生すると、プロファイリングアプリケーションまたはその他のプロファイラに通知が行くとしてよい。プロセッサの電力状態移行イベントの一例は、Linux登録商標オペレーティングシステム、つまり、電力開始トレースポイントC状態エントリトレースポイントとも呼ばれるに見られる。C状態エントリトレースポイントは、オペレーティングシステムがプロセッサをスリープ状態に移行させるためにプログラミングする用意をしている場合に実行される。これらのトレースポイントは、カーネル計測メカニズムであり、開発者がカーネルの機能を理解し易いように、カーネルソースコードフロー内のポイントに配置するとしてよい。言い換えると、トレースポイントは、カーネルソースコードにおけるprintf関数呼び出しと同様である。トレースポイントによれば、デバイスドライバがトレースポイントに動的に接続される機能が得られる。デバイスドライバがトレースポイントに接続例えば、登録されている場合、オペレーティングシステムは、当該トレースポイントを含むカーネルソースコードが実行されると、デバイスドライバ内の関数を呼び出す。言い換えると、C状態エントリトレースポイントは、プロセッサがスリープ状態に移行する用意をしている場合、電力プロファイリングアプリケーションに通知するために利用され得る。尚、Linux登録商標OSについての実施形態に基づいて説明しているが、本発明の範囲はこれに限定されず、実施形態は他のOSで利用し得るものと理解されたい。つまり、より一般的には、実施形態では、例えば、OSで実施されるものとして、電力状態移行時に特定の電力状態情報を収集する。プロセッサは、所定の低電力状態に移行すると、通常は動作を停止する。言い換えると、命令は実行しない。プロセッサは、低電力状態に移行するようにプログラミングされると、要求されたスリープ状態から逸脱することを選択するとしてよい。言い換えると、オペレーティングシステムがスリープ状態1に移行するようハードウェアをプログラミングする一方、ハードウェアは現在のプラットフォーム動作の情報に基づいてスリープ状態2に移行することを選択するとしてよい。代表的なプロセッサは、Intel登録商標命令セットアーキテクチャISAに基づいたプロセッサであって、複数の低電力状態を可能とするプロセッサを含む。例えば、アドバンスドコンフィグレーションアンドパワーインターフェースACPI規格、例えば、Rev.3.0b2006年10月10日に公開に応じたプロセッサ、プロセッサコアに対して複数の低電力状態、いわゆるC状態を実現するプロセッサを含む。一部の実施形態によると、プロセッサは、電力プロフィール情報について、ハードウェアサポートを提供するとしてよい。例えば、マルチコアプロセッサにおいて、各コアは低電力状態レジデンシカウンタ例えば、C状態レジデンシカウンタを含むとしてよい。低電力状態レジデンシカウンタは、ハードウェアが特定の低電力状態に留まっている時間例えば、プロセッササイクルをカウントする単調増加カウンタである。例えば、プロセッサは、特定の低電力状態、例えば、C3およびC6のC状態についてのみ、C状態レジデンシカウンタを提供するとしてよい。このハードウェア監視計測機能によって、ハードウェアの低電力挙動を正確に監視することができる。また、ハードウェアはシステムタイムカウンタを提供するとしてよい。例えば、プロセッサは、コア単位で、タイムスタンプカウンタTSCを提供するとしてよい。一部の実施形態では、これらのカウンタは、ハードウェアがアクティブ状態または低電力状態に留まっている場合は、常時カウントしている単調増加カウンタである。上述したように、従来のプロファイリングアプリケーションは、イベント例えば、割り込みまたはタイマーをスケジューリングして、プロファイリングアプリケーションが特定の情報を収集できるようにする。しかしこれでは、電力プロファイリングソフトウェアによって、スリープ状態のプロセッサがスリープ状態を終了させることになってしまう。プロセッサがスリープ状態を終了させると、プロセッサは通常消費電力モードで動作を継続する。言い換えると、イベントをスケジューリングする従来のプロファイリングアプリケーションのために、プロファイリングアプリケーションが実行されていないプラットフォームと比較すると、プラットフォームが消費する電力が増加するそして、低電力性能情報が混乱してしまう。実施形態ではプロセッサ電力状態移行イベントをトリガイベントとして利用してプラットフォームに関する電力情報を収集するので、タイマまたは割り込みは回避され、実施形態でデータを取得するのは、プロセッサがアクティブ状態で実行されている場合のみである。このようにして、プロファイリングアプリケーションが、プラットフォームをプロファイリングするために用いられる電力を最小限に抑え、プラットフォームの低電力挙動の混乱を回避する。一実施形態によると、電力プロフィール情報を収集するためにデバイスドライバを用いることができる。しかし、他の実施形態では、他の特権レベルソフトウェアまたはユーザレベルソフトウェアがこの情報を取得するとしてよい。デバイスドライバは、プロセッサが低電力状態に移行する用意をしている場合に通知されるプロセッサ電力状態移行イベントを利用する。この実施形態では、デバイスドライバは、例えば、収集関数等の関数を、OS電力状態移行コードに登録する。例えば、一実施形態において、このコードは、Linux登録商標のC状態エントリトレースポイントであってよく、この登録によって、C状態エントリトレースポイントは、オペレーティングシステムがプロセッサをスリープ状態に移行させると判断する度に、登録された関数を呼び出す。OSがC状態エントリトレースポイントを実行すると、デバイスドライバの収集関数が、一実施形態によると、システムクロックおよびプロセッサのスリープ状態レジデンシカウンタを読み出して、アクセスした情報を保存する。例えば、第1の情報収集は、第1のC状態エントリトレースポイントにおいて発生し、サンプルAを取得するとしてよい。この次にC状態エントリトレースポイントが実行されると、デバイスドライバの関数は、同じ情報をサンプルBについて収集する。この処理は、データ収集段階において継続して行われる。性能コストは最小限に抑えられるとしてよい。これは、一回のC状態エントリトレースポイントにおいて読み出されるレジスタは一握りのみのためである。図1は、本発明の実施形態に係るタイミングシーケンスを示す図である。t0において、C状態エントリトレースポイントが実行され、サンプルAが収集される。この後、プロセッサはスリープ状態になる。尚、このスリープ状態は、オペレーティングシステムがプログラミングした状態とは異なる状態であるとしてよい。t1において、ハードウェアがスリープ状態を終了して、通常の動作に戻り、消費電力も通常に戻るイベントが発生する。スリープ状態を終了させる当該イベント例えば、割り込みまたはタイマ切れは、電力プロファイラがスケジューリングしたものではなかった。t2において、C状態エントリトレースポイントが再度実行され、サンプルBを収集する。尚、データの収集は、トレースポイントにトリガされる代わりに、OSまたはプラットフォームロジックの別の通知メカニズムに応じて実施されるとしてもよい。データの収集が終了した後、収集されたデータを、例えば、プロファイリングアプリケーションによって処理することができる。サンプルBのシステムクロック値とサンプルAのシステムクロック値との間の差分を算出する。この差分は、2つの電力状態移行イベントの間に実際に経過した時間に対応するとしてよい。また、サンプルAとサンプルBとの間のレジデンシカウンタの差分も算出して、第1の電力状態移行イベントについての低電力状態およびその長さまたは期間、さまざまな実施形態によると、サイクル単位で計測するとしてもよいし、時間で計測するとしてもよいを決定することができる。例えば、C3状態について1つのレジデンシカウンタ、そして、C6状態について1つのレジデンシカウンタの2つのレジデンシカウンタがあると仮定する。また、サンプルAおよびサンプルBにおいて、表1に示す値が収集されたと仮定する。このデータからは、電力プロファイラは、どのスリープ状態に移行したかこの場合には、C3カウンタが変化していないのでC6状態、スリープ状態で動作した時間C6状態において300カウント、および、通常電力レベルでの動作時間200カウント、総時間-スリープ時間に等しいを正確に決定することができる。上述したように、さまざまなシステムに実施形態を組み込むことが可能であり、複数の異なる構成要素を用いて実施形態を実施し得る。一部の実施形態によると、一連の性能分析ツールの一部として方法を実施し得る。より具体的に説明すると、システムの構成要素における電力状態移行に関する情報を取得して当該データを処理することができるツールの電力プロファイラに実施形態を組み込むとしてよい。そして、このデータを用いることで、ユーザ、コンパイラ、オペレーティングシステムまたはその他の同様のエンティティ等、所定のエンティティによる分析を実行できるようにするとしてよい。本明細書で説明した実施形態は、マルチコアプロセッサ等のプロセッサで発生する電力移行に関する実施形態である。しかし、この特定の実施例で説明しているが、本発明の範囲はこれに限定されるものではなく、他の実施形態では、システムの他の構成要素、例えば、チップセット、メモリ、周辺機器等もまた、本発明の実施形態に係る電力監視方式によって有益な効果が得られると理解されたい。図2を参照すると、本発明の実施形態に係る電力プロファイリング方法の概要を示すフローチャートが図示されている。図2に示すように、方法10は、性能分析部、より具体的には、性能分析部の電力プロファイラで実行され得るが、電力プロファイラのデバイスドライバを初期化することから開始されるとしてよいブロック20。このようなデバイスドライバの初期化によって、当該デバイスドライバに対応付けられている低レベル機能、例えば、さまざまなプロセッサレジスタ等の特権リソースにアクセスする機能がイネーブルされるとしてよい。続いて、ブロック30に進み、例えば、このドライバの収集関数を登録して、電力状態移行イベントの際に呼び出すことができるようにするとしてよい。一例を挙げると、電力状態移行イベントを処理するOSモジュールをアップデートして、この収集関数を登録することができる。Linux登録商標のOSについての特定の一実施形態において、この収集関数は、電力移行に関する計測処理を実行するトレースポイントに登録することができる。さらに図2を参照しつつ説明すると、続いて、収集関数によって取得される電力状態移行情報を格納するためのバッファを割り当てるとしてよいブロック40。一例を挙げると、このバッファはプロセッサのキャッシュメモリ、例えば、最終レベルキャッシュに設定されるとしてよい。したがって、この時点において、電力プロファイラは、電力状態移行イベントの発生に応じて、収集処理を実行して電力状態移行情報を取得するように構成されている。したがって、電力状態移行イベントについて収集処理を行うブロック50に進む。取得した対応する情報をバッファに格納するとしてよい。さまざまな実施形態によると、収集処理は、低電力モードの開始に対応する電力状態移行イベントに対して実行されるとしてよい。これは、さまざまな処理がOSによって実行されて、プロセッサが低電力モードに入る準備をして、低電力モードへの移行を可能にするためである。しかし、これに代えて、他の実施形態によると、この情報は、低電力モードを終了する際に取得されるとしてもよい。いずれのイベントにしても、従来の電力プロファイラのようにシステム動作中のランダムなタイミング例えば、割り込みまたはタイマに応じてではなく、プロファイリングウィンドウにおいて特定の方向の、つまり、低電力モード開始時または低電力モード終了時のどの電力状態移行イベントにおいても情報を画定的に収集し得ることに留意されたい。この収集処理は、プロファイリングウィンドウに対応する期間にわたって所定の方向の多くの連続した電力状態移行イベントについて実行され得る。プロファイリングウィンドウは、さまざまな実施形態によると、バラツキが大きい。例えば、収集処理は、一秒と短くてもよいが、通常は作業負荷がシステムを駆動している限り通常は数分であるが、まれに数時間に及ぶにおいて、実行される。このように、複数の連続した電力状態移行イベントで得られる情報は、収集ウィンドウにおいて収集され得る。本発明の範囲はこれに限定されないが、さまざまな実施形態によると、この移行イベントに関して収集される情報は、タイムスタンプカウンタ等のシステムレベルカウンタを含むさまざまなカウンタの値、および、プロセッサ内で利用可能な複数の異なる低電力状態に対応付けられている1以上のカウンタの値を含むとしてよい。例えば、C状態はそれぞれ、機械固有レジスタMSRが対応付けられており、当該レジスタを用いて所与の低電力モードの期間をカウントすることができるとしてよい。各収集処理の後、収集処理が完了したか否かを判断するとしてよいダイヤモンド60。例えば、さまざまな実施形態によると、電力プロファイラは、所定の時間にわたって、または、所定数の電力状態イベントについて等、データを収集するように構成されるとしてよい。収集が完了していなければ、ブロック50に戻る。収集が完了していれば、ブロック70に進み、収集処理で取得した電力状態移行情報を処理してユーザに報告するとしてよい。尚、図2の実施形態では比較的概略的なレベルで説明したが、複数の異なる実施形態において詳細な内容および変形例はさまざまなものが実施可能であると理解されたい。図3を参照すると、本発明の一実施形態に係る収集方法を説明するためのフローチャートが図示されている。上述したように、一部の実施形態によると、当該収集方法は、MSR、システムカウンタ等の特権リソースに存在する情報にアクセス可能なドライバに対する関数呼び出しによって実施されるとしてよい。しかし、他の実施形態によると、収集処理はユーザモードで実行され得ると理解されたい。図3において、方法100は、ブロック110でシステムクロックを読み出すことによって開始されるとしてよい。さまざまな実施形態によると、システムクロックは、低電力状態に入るコアに存在するタイムスタンプカウンタに対応するとしてよい。このため、プロセッサはコア単位で電力管理を行うように制御され得るので、収集処理はコアの粒度で実行され得ると理解されたい。しかし、他の実施形態によると、プロセッサは、パッケージレベルでのみ電力管理を実現するので、このような実施形態では、情報はパッケージ単位で取得されるとしてよい。さらに別の実施例によると、コアレベルおよびパッケージレベルの電力状態情報の組み合わせを取得することもできる。さらに図3を参照すると、読み出したシステムクロック値は、バッファに格納されるとしてよいブロック120。より具体的には、収集処理毎に、バッファのエントリが割り当てられ、このシステムクロック値を、利用可能な各低電力状態に対応付けられている単調カウンタの値と共に格納するために用いることができる。このため、図3からさらに分かるように、プロセッサで利用可能なスリープ状態毎にダイヤモンド130での決定に応じて、その低電力状態についての対応するレジデンシカウンタの読出処理を含むループを実行するブロック140。当該読出処理は、当該低電力状態のMSRを読み出すことによって実行されるとしてよい。その後、カウンタ値をバッファ内のエントリに書き込むブロック150。このように、利用可能な低電力状態についてカウンタを全て読み出すと、方法100は終了するとしてよい。したがって、電力状態移行イベントについての収集処理が完了し、取得された情報はバッファのエントリに格納される。尚、図3の実施形態ではこの特定の情報について関連付けて説明しているが、本発明の範囲はこれに限定されるものではなく、他の実施形態では、追加で情報を取得するとしてもよいし、別の情報を取得してもよいものと理解されたい。例えば、一実施形態によると、追加で取得する情報には、OSが要求した低電力状態ハードウェアが実際に利用している低電力状態でない場合もあるが含まれるとしてよい。図3を参照しつつ説明したような収集処理は、何度も実行するとしてよい。所望の量のデータを収集すると、電力プロファイラは、さまざまな処理を実行して、収集したデータにさらに処理を実行する準備をすると共にデータ収集を終了させるとしてよい。図4を参照すると、本発明の実施形態に係るデータ収集を終了させる方法を説明するためのフローチャートが図示されている。図4に図示しているように、方法200は、デバイスドライバをアンロードする処理においてさまざまな処理を実行するとしてよいブロック210。概して、ドライバは、アンロード処理の前に、データをフラッシュして例えば、ディスクに書き込んで、バッファを空にして、収集関数の登録を解除する。これらのステップドライバをアンロードするステップを除くは、収集処理が終了する度に実行され得る。ドライバは、insmodコマンドまたはrmmodコマンドを用いて手動で挿入および削除が可能でありLinux登録商標のOSの場合、または、ドライバは、ブート期間に自動的にロードして決して削除されないとしてもよい。また、一部のOSでは、デバイスドライバを、特定のユーザモードのシステム呼び出しでロードして、アンロードすることができる。このような実施例では、1ドライバをロードして、2時間が経過すると、収集処理を実行して、3所望に応じてステップ2を繰り返し、4ドライバをアンロードするという順序になる。また、一部の実施例によると、収集したデータは、収集処理を制御するユーザレベルコードに戻して、ユーザレベルコードによってファイルに保存されることに留意されたい。言い換えると、ドライバは、実際にはファイルへの書き込みを実行せず、バッファをユーザレベルコードに渡して、収集処理中にユーザレベルコードがデータをファイルに書き込む。Linux登録商標のOSであれば、この種類のデバイスドライバはキャラクタドライバと呼ばれる。図から分かるように、当該方法は、バッファがファイルに書き込まれるブロック215で開始される。例えば、バッファは、上述したように、プロセッサのキャッシュ内の一時ストレージに位置しているとしてよく、ファイルシステムに転送することができ、例えば、後でアクセスするべくデータファイル220としてシステムメモリに格納されるとしてよい。続いて、ブロック225に進み、バッファを解放して、OSのリソースプールに戻すとしてよい。最後に、ブロック230に進み、収集関数の登録を解除するとしてよい。つまり、収集関数を登録していたOSトレースポイントまたは他のカーネルまたは、他の位置は登録を解除するので、当該関数は電力状態移行イベントにおいて呼び出されることがなくなる。この時点において、デバイスドライバはアンロードされるとしてよい。このように、この時点において、所望の電力状態情報が取得されており、さらに処理することで、システムの分析ツール等のユーザまたはその他のエンティティによる分析が可能となる。図5を参照すると、本発明の実施形態に係る収集したデータを処理する方法を説明するためのフローチャートが図示されている。図5に図示されているように、方法250は、データファイル220を処理することによって開始されるとしてよいブロック260。一実施形態によると、この処理は、データとプロセッサがアクティブ状態に戻った理由の説明例えば、タイマまたは割り込み、または、アクティブ状態へ戻るきっかけとなったイベントに至るソースコードコールスタックの説明とを対応付ける処理を含むとしてよい。この時点において、データは、例えば、電力プロファイラのユーティリティによって処理すべき形式になっている。さらに図5を参照して説明すると、ブロック265に進んで、第1の電力状態移行イベントの収集処理に対応する第1のサンプルをデータファイルから読み出すとしてよい。そして、ダイヤモンド270での判断に応じて、ファイル内の追加サンプル毎にループを実行するとしてよい。特に、このループでは、ブロック275において、現在サンプルと過去サンプルとの間の経過時間を算出することができるブロック275。また、ブロック280において、現在サンプルのレジデンシカウントのそれぞれと、過去サンプルのレジデンシカウントとの差分も算出するとしてよい。ブロック290において、算出結果をテーブルに格納するとしてよい。このため、互いに隣接する一対のサンプル毎について、低電力状態の前回の開始タイミングと低電力状態の今回の開始タイミングとの間に経過した時間システムクロック数で表される差分によって決まるを決定することができる。さらに、対応するレジデンシカウントの差分に基づき、前回の低電力移行での移行先である所与の低電力状態を、この低電力状態の期間の長さを決定するとともに、決定することができる。このように、一対のサンプル毎に、2つの電力状態イベントの間の経過時間を、前回の低電力移行の期間および種類と共に、決定することができる。このため、これらの値は、他のレジデンシカウンタの差分全てゼロに等しいとしてよいと共にテーブルエントリに格納されるとしてよい。このため、このループはデータファイル内の追加サンプル毎に実行される。この処理が完了すると、ブロック295に進み、結果をユーザに出力するとしてよい。例えば、この出力は、収集処理の間の動作を説明するタイムラインとしてもよいし、または、ある状態を利用した頻度を説明するヒストグラムとして表示することもできる。幾つかの例によると、出力は、プリントアウトされるとしてもよいし、または、プラットフォームのディスプレイのユーザが見ることが可能なディスプレイであってよい。さらに、テーブルに格納されている結果はまた、他の分析ツールおよび制御ツール、例えば、コンパイラ、OSまたはその他のツールで利用されるべく、機械可読媒体形式で利用可能であるとしてよい。一例を挙げると、テーブル内の情報は、人間が読み出し可能な形式で、および/または、コンピュータが読み出し可能な形式で、OSエンティティに供給されるとしてよい。この情報は、OS開発者および/または動作しているOS自体によって、電力管理に関する判断処理についての性能を改善するべく、利用されるとしてよい。例えば、開発者は、受信した情報に基づいて、OSの電力管理コードを更新するとしてよい。このような一例によると上述したように、プロセッサハードウェアは、OSが要求した低電力状態とは異なる低電力状態に入ることを選択することが可能である。テーブルから利用可能な情報、つまり、所与の間隔で開始された特定の低電力状態の期間および種類に基づき、OSエンティティは、自身が発行した低電力状態移行要求は受け入れられず、プロセッサが選択した別の低電力状態が優先されたと決定することができる。この情報に基づき、OSエンティティは、電力管理アルゴリズムおよび/または電力管理ヒューリスティックスを修正して、例えば、今後新しいOSがリリースされる場合には、別の電力管理判断がなされるようにしてもよい。さらに、この情報がコンピュータ可読形式で、プラットフォームで実行される現在のOSのインスタンス化に供給される実施形態では、OSのインスタンス化は、リアルタイムで、制御アルゴリズムを更新するとしてよく、その後実行する際にはこの情報に基づいてより良い判断を行うとしてよい。図5の実施形態ではこの特定の実施形態を図示しているが、本発明の範囲はこれに限定されるものではないと理解されたい。図6を参照すると、本発明の実施形態に係るプロセッサのブロック図が図示されている。図6に図示しているように、プロセッサ400は、複数のコア410a-410nを含むマルチコアプロセッサであってよい。一実施形態によると、各コアは、例えば、フロントエンドユニットと、アウトオブオーダロジックと、実行ユニットと、リタイヤメントロジック等のバックエンドユニットとを含むパイプラインを持つとしてよい。さらに、上述したように、各コアは、機械固有レジスタ、性能モニタ等のレジスタとして実現され得るさまざまなカウンタを含むとしてよい。図6の実施形態によると、これらのカウンタはタイムスタンプカウンタ412を含む。カウンタ412は、プロセッサの公称周波数で、例えば、マシンサイクルとして、カウントするとしてよく、一部の実施形態によると、コアまたは、電力がプロセッサに供給されている限りにおいて、プロセッサの電力状態および複数の低電力カウンタ4140-xに関係なく常にカウントしているとしてよい。各低電力カウンタは、コアが所与の低電力状態にあるサイクルをカウントする。さまざまなコアが、インターコネクト415を介して、さまざまな構成要素を含む非コア部420に結合されているとしてよい。図示されているように、非コア部420は、最終レベルキャッシュである共有キャッシュ430を含むとしてよい。また、非コア部は、集積化メモリコントローラ440、さまざまなインターフェース450、および、電力制御ユニット455を含むとしてよい。一部の実施形態では、電力制御ユニット455を用いて、OSには関係なく、低電力状態を開始および終了するとしてよい。図示されているように、プロセッサ400は、例えば、メモリバスを介して、システムメモリ460と通信するとしてよい。また、インターフェース450によって、さまざまなチップ外構成要素、例えば、周辺機器、大容量ストレージ等に接続を行うことができる。図6の実施形態ではこの特定の実施例で図示しているが、本発明の範囲はこれに限定されない。実施形態は多くの異なる種類のシステムで実現され得る。図7を参照すると、本発明の実施形態に係るシステムを示すブロック図が図示されている。図7に示すように、マルチプロセッサシステム500は、ポイントツーポイントインターコネクトシステムであり、ポイントツーポイントインターコネクト550を介して結合されている第1のプロセッサ570および第2のプロセッサ580を含む。図7に示すように、プロセッサ570および580はそれぞれ、マルチコアプロセッサであってよく、第1および第2のプロセッサコアつまり、プロセッサコア574aおよび574b、ならびに、プロセッサコア584aおよび584bを含むが、プロセッサにははるかに多くのコアが存在するとしてもよい。各コアは、上述したように、さまざまなレジデンシカウンタおよびシステムカウンタを含むとしてよい。さらに図7を参照しつつ説明すると、第1のプロセッサ570はさらに、メモリコントローラハブMCH572ならびにポイントツーポイントP-Pインターフェース576および578を含む。同様に、第2のプロセッサ580は、MCH582ならびにP-Pインターフェース586および588を含む。図7に示すように、MCH572および582によって、プロセッサが対応するメモリ、つまり、メモリ532およびメモリ534に結合されている。メモリ532および534は、対応するプロセッサにローカルに接続されているメインメモリ例えば、ダイナミックランダムアクセスメモリDRAMの一部であってよい。第1のプロセッサ570および第2のプロセッサ580は、P-Pインターコネクト552および554を介して、チップセット590に結合されるとしてよい。図7に示すように、チップセット590は、P-Pインターフェース594および598を含む。さらに、チップセット590は、チップセット590と高性能グラフィクスエンジン538とをP-Pインターコネクト539を介して結合するインターフェース592を含む。一方、チップセット590は、インターフェース596を介して第1のバス516に結合されるとしてよい。図7に示すように、さまざまな入出力I/Oデバイス514は、バスブリッジ518と共に、第1のバス516に結合されているとしてよい。バスブリッジ518は、第1のバス516を第2のバス520に結合する。第2のバス520には、例えば、本発明の実施形態に応じた電力プロファイリング処理を実行するべく、さまざまなデバイスが結合されているとしてよい。例えば、キーボード/マウス522、通信デバイス526、および、コード530を含む、ディスクドライブまたはその他の大容量ストレージデバイス等のデータストレージユニット528が結合されているとしてよい。さらに、第2のバス520には音声I/O524が結合されているとしてよい。実施形態は、コードで実現するとしてよく、命令を格納しており、当該命令を実行するようシステムをプログラミングするために用いられる格納媒体に格納するとしてよい。格納媒体は、これらに限定されないが、フロッピー登録商標ディスク、光ディスク、光ディスク、ソリッドステートドライブSSD、コンパクトディスクリードオンリーメモリCD-ROM、コンパクトディスクリライタブルCD-RWおよび光磁気ディスクを含むディスク、リードオンリーメモリROM等の半導体デバイス、ダイナミックランダムアクセスメモリDRAM等のランダムアクセスメモリRAM、スタティックランダムアクセスメモリSRAM、消去可能プログラム可能リードオンリーメモリEPROM、フラッシュメモリ、電気的消去可能プログラム可能リードオンリーメモリEEPROM、磁気カードまたは光カード、または、電子命令の格納に適した任意のその他の種類の媒体等の任意の種類の非一時的格納媒体を含むとしてよい。本発明を限られた数の実施形態に基づいて説明したが、当業者であれば、開示内容から数多くの変形例および変更例に想到するであろう。添付した特許請求の範囲はこのような変形例および変更例をすべて、本発明の真の意図および範囲に含むものとする。