JP5095718B2 - プラットフォームおよびプロセッサの電力管理 - Google Patents

Description

本発明は、概してコンピューティングシステムに関する。より具体的には、プラットフォームの管理方法およびシステムに関する。

添付の図面に本発明の実施形態を例示的に示すが、これらに限定はされない。図面における同じ参照番号は、類似の要素を示す。

一部の実施形態における、コンピューティングシステムの図である。

一部の実施形態における、ホストを起動する際にタスクを同期するルーチンのフロー図である。

一部の実施形態における、受信したネットワークデバイスのアイドル通知に基づいた、ホストモード開始のルーチンを示すフロー図である。

例えば、ラップトップ、タブレット、携帯電話および携帯インターネットデバイス（ＭＩＤ）などの携帯プラットフォームコンピューティングデバイスは、１つ以上の通信インターフェースを介してユビキタスなネットワーク接続性を提供する。これらのプラットフォームの利用モデルの多くは、通信活動によって推進されている。通信デバイスそのものは、プラットフォームの電力のごく一部を消費するに過ぎないが、プラットフォーム電力全体に対する通信利用の影響は、送受信するネットワークトラフィックの非決定的な性質によって多大なものになり得るため、プラットフォームを必要以上に高い電力消費ステートでアクティブにし続ける場合がある。

一般的に、ネットワーク活動は、送信メッセージを作成するべくホストを起動する、タイマーの期限切れに基づいたアプリケーションによって開始される。従来、プラットフォームコンポーネントが、例えばプロセッサは最低のＣステート（つまりＣ５以上）のディープスリープステートおよび類似の低レベルプラットフォーム電力ステートなどにある場合、非タイムクリティカルなパケットの送信活動は、プラットフォーム全体が低電力ステートに到達あるいは留まることを阻むため、多大な電力量がかかる。さらに悪いことに、一般的にアプリケーションは、プラットフォームあるいは他のアプリケーションの動作を認識することなく、各自のタイマーに基づいて無関係に動作する。この結果、異なるアプリケーションから発行されるタスクを処理するべくプラットフォームがランダムに起動し、プラットフォームが低電力ステートに到達し留まることを阻む。

ここに説明する一部の実施形態では、プラットフォーム活動およびアプリケーション同士と同期し、プラットフォームのより長いアイドル期間を作成する、ネットワークキープアライブおよび周期的かつ非タイムクリティカルなネットワークアクセスを必要とするアプリケーションのインターフェースおよびメカニズムを示す。例えば、プラットフォームを最小回数のみ起動しつつ、アプリケーションの「鼓動」を維持するには、最も厳しいタイミング要件が許容する範囲内で、非タイムクリティカルなネットワーク活動を同期してよい。

プラットフォームがいわゆる「Ｔｉｃｋｌｅｓｓ ＯＳ」の使用へと移行する中、送信ネットワーク活動を制御し、長いアイドル状態の恩恵を十分に享受するべく、プラットフォーム活動と調整することが望ましい。これにより、プラットフォームコンポーネントがより深いスリープステートへ到達させ、バッテリーの寿命を延ばしてよい。

図１は、一部の実施形態におけるコンピューティングシステムを示す。この図は、プラットフォームの電力管理を実装するアーキテクチャを図示する。システムは、ハードドライブ１２２、マウス１２４、キーボード１２６およびネットワークインターフェースデバイス１２８を含む、周辺デバイスを有するプラットフォーム１０２を備える。プラットフォーム１０２は、図のように結合された、少なくとも１つのプロセッサ１１０およびプラットフォーム制御ハブ１０５を含む。また、この実施形態では、プロセッサ１１０の一部である、電力管理ユニット（ＰＭＵ）１１２を含む。（ＰＭＵは、別個の処理ユニットとして別個のチップ、あるいはプラットフォームの適切なあらゆるチップに実装されてよい。一部の実施形態では、プロセッサ内の別個のコントローラとして、あるいはＰＣＨ１０５などの別のチップに実装されてよい。）プロセッサおよび／またはＰＭＵは、オペレーティングシステム（ＯＳ）１４０とアプリケーション１３１とを実行する。ここでの実施形態では、ＯＳ（例えば、ユーザスペースドライバ、パッチ、またはその等価物）は、ＯＳアプリケーションインターフェース１４２およびＯＳプラットフォームインターフェース１４４を実装し、アプリケーション側およびプラットフォーム側で実行されるタスクをそれぞれ識別する。ＯＳメッセージングレジスタ１４１は、効率のよいパフォーマンス調整のためのタスク情報（例えば、タスクキュー、タイマーなど）を格納するよう設定される。

アプリケーション１３１は、ユーザの関与を必ずしも伴わない（周期的またはその他の）ネットワークネットワーク活動を有する、インスタントメッセージング（ＩＭ）、インターネットウィジェット、電子メールおよびその他のアプリケーションを表す。一般的にこれらのアプリケーションは、接続のタイムアウトを防ぐべく周期的にキープアライブメッセージを送信し、例えば電子メールの受信トレイのステータス、ウィジェットなどのための天気情報、為替情報などの最新の情報を入手する。

ＰＭＵ１１２は、プラットフォームの管理およびその活動ステートの管理などを含む、多種多様な機能を実行してよい。一部の実施形態では、プラットフォーム活動ステートは、プロセッサの活動ステートとは独立している。例えば、Ｃ０を最も活動的なステートとし、より低活動なステート（例えば、Ｃ１からＣ７）によって異なるレベルの低減された活動、つまり低減された電力消費を定義する、「Ｃ」ステート（ＡＣＰＩ規格）と呼ばれる状態にプロセッサがあってよい。同時に、プラットフォームは、例えば高活動ステートから低いレベルのスリープステートにわたる、独自の電力ステートにあってよい。一部のスキームでは、Ｓ０が最も高いプラットフォーム活動ステートであって、より低いプラットフォーム活動ステートはＳ３、Ｓ４およびＳ５で漸次示す。一部の実施形態では、プラットフォームがＳ０ステートにある場合、プロセッサが例えば低いＣステートなどのスリープ状態にあっても、ネットワーク通信およびその他のプラットフォーム活動が発生してよい。

ＯＳアプリケーションインターフェース１４２は、アプリケーションをＯＳサービスにレジスタさせ、送信ネットワークリクエスト（例えば、トランスミッション）を同期する。このＯＳレベルの機能によって、「ジッタ」要件が範囲内であることを条件に、次の静寂期間内に実行されるべきタスクのプルインが可能となり、それらをより迅速に実行できる。これにより、プラットフォームはより静寂になり、より長いアイドル状態が可能となる。

ＯＳプラットフォームインターフェース１４４は、プラットフォームとＯＳとのインターフェースである。このインターフェースを介して、プラットフォームはＯＳに期待される静寂期間を知らせる。例えば、ネットワークインターフェース（通信）デバイス１２８は、ＰＣＨ１０５を介してＯＳプラットフォームインターフェースへ期待されるアイドル期間を知らせ、通信デバイスで受信トラフィックを保留する。この期間は、経験則あるいはその他の手段で推定してよい。同様に、その他の周辺デバイスはＰＣＨを介してそれらの静寂期間をインターフェースへ指示し、ＰＣＨがこのインターフェースを介してＯＳへ知らせてよい。

一部の実施形態では、非クリティカルな送信メッセージの期限を有する、あるいは周期的なネットワーク活動に関わるアプリケーションは、ＯＳアプリケーションインターフェースにレジスタし、アプリケーションタスクとプラットフォーム活動とを調整してよい。提供される情報は、例えば、メッセージ頻度および許容ジッタを含むタイミング要件を含んでよい。

ここでの実施形態では、プロセッサが低い活動ステートにある場合でも、ＰＭＵ１１２は、実行するべきアプリケーションおよび／またはプラットフォームタスクの処理を調整するプラットフォーム管理ルーチン１１４を実行してよい。図２および後に述べる図３は、プラットフォーム管理スキームの一部として実行されてよい、異なるルーチン機能を示す。一部の実施形態では、これらはＰＭＵ１１２のプラットフォーム管理ルーチン１１４の一部として実行されてよい。

図２は、プロセッサがスリープモードにある場合に、タスクアプリケーションおよびプラットフォームタスク処理を調整する、ＰＭプログラム１１４のようなプラットフォーム管理プログラムにより実行あるいは開始されてよい、ルーチン２０１を示す。まず２０２において、アプリケーションタイマーおよびプラットフォームアイドル期間（例えば、推定されたアイドル状態）の情報で、ＯＳアプリケーションおよびＯＳプラットフォームインターフェース（あるいは等価物）が初期化あるいは更新される。プラットフォーム情報に関して、プラットフォームは、様々な要素に基づいて、到来するアイドル状態の期間を想定してよい。例えば、想定されたアイドル状態は、周辺デバイスからの情報に基づいてよい。例えば、通信デバイスが次の５０〜１００ｍｓ間データをバッファするなど、しばらくの間活動がないことを周辺デバイスが示す場合、ＰＣＨおよび／またはＰＭＵが到来するアイドル期間を検知してよい。また、アイドル期間は、経験則のアイドル期間など、適応的推定方法を用いて想定してよい。例えば、指数フィルタを適用し、アイドル状態の過去の履歴に基づいて到来するアイドル状態を推定してよい。

次に２０４において、ルーチンはプラットフォーム活動の有無を判断する。例えば、ユーザが１つ以上の周辺デバイスを介してプラットフォームとのインターフェースを試みている場合には、これがここで認識される。プラットフォームがアクティブでない場合、ルーチンは２０６へ進み、いずれかのアプリケーションタイマーが期限切れでないかを判断する。いずれのタイマーも期限切れではなく、アプリケーションタスクにサービスの必要がないことが示される場合、ルーチンは２０４にループバックする。これ以外の場合、つまり１つ以上のアプリケーションタイマーの期限が切れている場合、ルーチンは２０８へ進む。ここでは、ホストが起動し、期限の切れたタイマーに対応するタスクを処理する。ルーチンは次に２２０へ進み、例えば、キープアライブメッセージを有し、周期的に通信する必要のあるアプリケーションなど、その他のアプリケーションおよび／またはアプリケーションタイマーを確認する。

２２２において、ルーチンはいずれかのアプリケーションタイマーの期限が間もなく（例えば、想定されたプラットフォームアイドル期間内に）切れるかを確認する。その場合には、ルーチンは２２４でタスクを処理した後に２２６へ進み、サービスされるべき非タイムクリティカルタスクを有するアプリケーションのアプリケーションキューを確認する。２２２において、キープアライブアプリケーションのタイマーが期限切れに近い場合は、ルーチンは２２６に直接進む。

２２８において、ルーチンは非クリティカルアプリケーションキューが空白であるか、あるいは処理するべきタスクを有するかを確認する。タスクが存在する場合、それらは２３０で処理（またはサービス）され、その結果、アイドル期間をさらに延長する。その後、ルーチンは２３２へ進み、ホストをスリープ状態へ戻した後に２０４へループバックする。２２８においてキューが空白である場合、ルーチンは２３２へ進み、説明のとおり動作する。

２０４へ戻るが、ここでプラットフォーム活動が存在する場合、ルーチンは２１０へ進み、ホスト（プロセッサ）を起動する。ルーチンは、ここから２１２へ進みＯＳへ通知した後、２１４へ進み、周期的なプルメッセージを有するアプリケーションのタイマーを確認する。ＯＳが通知を受け、例えばインタラプトのようなイベントあるいは受信パケットによって起動されてアクティブとなった場合、送信活動の要件を有するこれらのアプリケーションを確認し、これらのタイマーの期限切れが近いかを確認する。

２１６において、いずれかのタイマーが間もなく期限切れとなることが判断された場合、それらは２１８において処理され、ルーチンは２２０へ進む。間もなく期限切れとなるタイマーが無い場合は、ルーチンは２２０に直接進む。この後は上述のとおりに進む。ＯＳは、これらのアプリケーションに送信を実行するよう通知する。その後、アプリケーションが次の静寂期間中にプラットフォームを起動しないようにタイマーがリセットされる。（プラットフォームが到来する静寂期間を検知する場合と同様に、ＰＭＵあるいはＰＣＨがＯＳに予期される静寂期間を通知してもよい。この場合、ＯＳは、アイドル期間中に期限切れし得る送信リクエストをプルインし、送信を開始してもよい。）

図３は、周辺あるいはネットワークデバイスから集められ予期されたアイドル状態に基づき、ホストの主要コンポーネント、具体的にはプロセッサを活動ステートにさせるルーチン３０１を示す。このルーチンの基本概念は、通信デバイス（例えば、周辺デバイスあるいはネットワークインターフェースデバイス）がホストに推定された到来するアイドル期間を知らせ、この情報に基づいて、どの省電モードとなるか、また場合によってはその他のプラットフォーム活動を行なうかについて、ホストが「情報に基づいた」判断を下すことにある。

まず３０２において、プラットフォーム管理体は通信（ネットワークインターフェース）デバイスからアイドル通知を受信する。例えば、アイドル通知は、参照によってその内容が本願に組み込まれた、２００８年９月１７日出願の米国特許出願１２／２８３，９３１「ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮ ＯＦ ＭＵＬＴＩＰＬＥ ＩＮＣＯＭＩＮＧ ＮＥＴＷＯＲＫ ＣＯＭＭＵＮＩＣＡＴＩＮ ＳＴＲＥＡＭＳ」に開示のネットワークインターフェースカード（ＮＩＣ）などのネットワークエージェントから送信されてよい。

３０４においては、通信デバイスから通知されたアイドル期間より頻繁なプラットフォーム活動の有無を確認する。これが無い場合は、３０８において通知された期間Ｔ（ｎ）をホストのブレイクイーブン期間Ｔ（ｂ）と比較する。理想的には、期待されたアイドル状態が十分な長さであれば、ホストは、キャッシュがフラッシュされてより多くの電力を省くことが可能なより深いスリープステート（例えば、ＣＰＵＣ５、Ｃ６あるいはＣ７）に入ることが可能となる。従って、ブレイクイーブン期間は、このようなステートへ入ることに関するコスト（待ち時間、電力など）に応じる。通知された期間がこのブレイクイーブン期間よりも短い場合は、このようなより深いステートへ入るに値しない可能性がある。

従って、通知された期間がブレイクイーブン期間よりも短いと３１０においてルーチンが判断した場合、ルーチンは３１２へ進み、ホストを現在のステートに留まらせるか、あるいは無活動状態が比較的浅いステートに置く。一方で、通知された期間がブレイクイーブン期間よりも長い場合、ルーチンは３１４へ進み、例えば、キャッシュがフラッシュされて消費電力が顕著に少ない、無活動状態がより深いステートにホストを置く。

３０４へ戻るが、通知されたアイドル状態を中断あるいは干渉する、他のプラットフォーム活動が発生し得るとルーチンが判断した場合、ルーチンは３１４へ進み、プラットフォーム活動に基づいて判断を下す。

このアプローチの利点としては、従来のアプローチでは、ＣＰＵのスケジューリングロジックは、キャッシュが空の場合にのみ、ＣＰＵをディープステート（例えば、Ｃ５またはＣ６）に入らせるという点がある。さらに、ＣＰＵがキャッシュを完全にシュリンクするまでには何度も試みる必要がある場合がある。このため、ＣＰＵが必要以上に長期間、浅い省電ステートにあることが多い。しかしながら、図３のルーチンによると、ホスト（ＣＰＵまたはプロセッサ）は一度の実行でキャッシュをシュリンクすることができ、到来するアイドル期間が、例えばＣ５あるいはＣ６のブレイクイーブン時間よりも長い場合には、即時に省電ステートへ入ることができる。これを行なうことにより、ホストは顕著な省電を達成することができる。

当然のことながら、デバイスからＰＭＵあるいはホストへのアイドル通知情報の伝達には、様々なメカニズムを用いてよい。例えば、ＰＣＩｅ拡張子を用いることができる。ＰＣＩｅの拡張子は、例えばプラットフォームインターフェーススキームに定義されたレジュームレイテンシー情報要件をデバイスが転送できるよう、考案されてよい。インターフェースの将来的なバージョンに「アイドル期間」を保持するフィールドを別途追加してよい。また、拡張子は、ＰＣＨとの活動を調整する無線ＮＩＣなどのネットワークデバイスを含むデバイスにおける利用のために定義されてよい。メモリおよび／またはＩ／Ｏトリガを用いてもよい。より暫定的なアプローチではあるものの、このアイドル情報をメモリ／ＩＯマップレジスタを用いて通信デバイスとホストとの間で伝達してよい。また、ＮＩＣの機能に基づいたインテリジェントなホスト推定を採用してもよい。ネットワークデバイスは、関連パラメータ（例えば、バッファサイズあるいは目的としたバッファ時間）でトラフィックの規制（例えば、Ｓｍａｒｔ−ＦＩＦＯ）を行なう、レジストリエントリ情報プラットフォームを設定してよい。ホストあるいはＰＭＵは、デバイスがイネーブルとなった際にこの情報を読み取ることができる。ＮＩＣデバイスの動きに変化があった場合、ＰＭＵあるいはホストがそのポリシーをしかるべく更新するようにインタラプトが生成されてよい。このＮＩＣからの情報により、ホスト（あるいはＰＭＵ）は、ネットワークデバイスからのインタラプトパターンを観察し、到来するアイドル期間を推定する。この知識により、ホストは上述した適切な省電のための行動をとることができる。

以上の説明では、数多くの具体的な詳細を述べた。しかしながら、本発明の実施形態はこれらの具体的な詳細を用いることなく実施可能であることが理解されるべきである。また別の場合には、説明の理解の妨げとならぬよう、公知の回路、構造およびテクニックは詳細に述べていない。この点を考慮して、「１つの実施形態」、「ある実施形態」、「例示的な実施形態」、「様々な実施形態」などは本発明の実施形態を示し、説明された実施形態が特定の機能、構造、あるいは特性を含んでいても、他の全ての実施形態が必ずしも特定の機能、構造、あるいは特性を含むとは限らない。さらには、一部の実施形態は、他の実施形態で説明した機能の一部あるいは全てを含んでも含まなくてもよい。

以上の説明および以下の請求の範囲では、次の用語は以下のように解釈される。「結合された」および「接続された」またこれらの派生語が用いられてよい。これらの用語は互いの類義語であることを意図されていないことが理解されるべきである。むしろ、特定の実施形態では、「接続された」は２つ以上の要素が互いに物理的あるいは電気的に直接に接触していることを示す。「結合された」は２つ以上の要素が互いに協働あるいは相互作用するが、物理的あるいは電気的に直接に接触していても接触していなくてもよいことを示す。

本発明は説明された実施形態に限定されず、添付の請求の範囲の趣旨および範疇において、変更および修正して実施されてよい。例えば、当然のことながら、本発明はあらゆる種類のＩＣチップへの用途が適用されてよい。これらのＩＣチップの例には、プロセッサ、コントローラ、チップセットコンポーネント、ＰＬＡ、メモリチップ、ネットワークチップおよび類似が含まれるがこれらに限定されない。

また、当然のことながら、一部の図面では信号導体線が線で表現されている。線のうちのいくつかは、構成要素的な信号パスを示すべく太く、構成要素的な信号パスの番号を示すべく番号ラベルを有し、および／また主要情報の流れ方向を示すべく１つ以上の端部に矢印を有する。しかしながら、これは限定的に解釈されるべきではない。むしろ、このような追加の詳細は、回路のより容易な理解を促進するべく、１つ以上の例示的な実施形態に関して用いられている。追加情報の有無にかかわらず、表現されたあらゆる信号線は、実際には複数の方向へ移動する１つ以上の信号を備えてよく、例えば、差動ペア、光ファイバ線、および／またはシングルエンド線で実装された、デジタルあるいはアナログ線などのあらゆる適切な種類の信号スキームで実装されてよい。

当然のことながら、例示的なサイズ、モデル、値、範囲を示したが、本発明はこれらに限定されない。時間の経過とともに製造技術（例えば、フォトリソグラフィー）が成熟し、より小さいサイズのデバイスが製造可能となることが予期される。さらに、本発明を不明瞭にせぬよう、図示および説明の簡略化を目的に、ＩＣチップおよびその他のコンポーネントへの公知の電源／アース接続が図中に表示されている場合とそうでない場合がある。またさらに、本発明を不明瞭にすることを防ぎ、またブロック図の取り決めの実装について、当業者の視界内に十分にあり得る詳細は、本発明が実装されるプラットフォームに大きく依存するという事実を鑑みて、取り決めはブロック図の形で示されていてよい。本発明の例示的な実施形態を説明するべく特定の詳細（例えば、回路）を示したが、当業者にとっては当然のことながら、本発明はこれらの特定の詳細を用いずとも、あるいはこれらの変形を用いても、実装可能であることは明らかである。従って、説明は制限的なものではなく解説的なものとして捉えられるべきである。

Claims (14)

1. 低活動ステートにあってよいプロセッサと、
   前記プロセッサによりサービスが提供されるタスクを持つコンポーネントを有するプラットフォームを管理するＰＭＵ（プラットフォーム管理ユニット）と
   を備え、
   前記プラットフォームは、前記プロセッサの前記低活動ステートとは無関係に低活動ステートにあってよく、前記ＰＭＵは、周期的なプルメッセージまたはキープアライブメッセージを有する非タイムクリティカルなタスクのタイマーの期限が所定の時間内に切れる場合、前記非タイムクリティカルなタスクが、前記プロセッサを起動させる他のタスクと共にサービスされるように、前記非タイムクリティカルなタスクの実行タイミングを調整することで、前記プロセッサのアイドル期間を延長する、
   電子デバイス。
2. 前記非タイムクリティカルなタスクは、送信されるネットワーク通信を含む、請求項１に記載の電子デバイス。
3. 前記プロセッサを起動させる前記他のタスクは、タイマーで開始されたアプリケーションタスクを含む、請求項１または請求項２に記載の電子デバイス。
4. 前記ＰＭＵは、前記プロセッサの一部である、請求項１に記載の電子デバイス。
5. 前記ＰＭＵは、前記プロセッサとは別のハブブロックの一部である、請求項１に記載の電子デバイス。
6. 前記プラットフォームのコンポーネントは、周辺コンポーネントとネットワークインターフェースコンポーネントとを含む、請求項１から請求項５のいずれか１つに記載の電子デバイス。
7. プロセッサの低活動ステートにおいて、サービスされるべきプラットフォーム活動の有無を判断する段階と、
   サービスされるべき活動がない場合には、アプリケーションタスクがサービスを必要とするかを確認する段階と、
   アプリケーションタスクがサービスを必要とする場合には、前記プロセッサを起動して前記アプリケーションタスクにサービスを提供し、周期的なプルメッセージまたはキープアライブメッセージを有する非タイムクリティカルなタスクのタイマーの期限が所定の時間内に切れる場合、前記非タイムクリティカルなタスクの実行タイミングを調整することで、前記プロセッサが起動している間に、前記非タイムクリティカルなタスクにサービスを提供する段階とを備える方法。
8. 前記非タイムクリティカルなタスクにサービスを提供する段階は、前記所定の時間内に前記非タイムクリティカルなタスクのタイマーの期限が切れるかを確認する段階を含む、請求項７に記載の方法。
9. 前記非タイムクリティカルなタスクにサービスを提供する段階は、前記非タイムクリティカルなタスクがサービスを待っているかを確認する段階を含む、請求項８に記載の方法。
10. 前記プロセッサを、再び前記低活動ステートに戻す段階をさらに含む、請求項７から請求項９のいずれか１つに記載の方法。
11. 前記非タイムクリティカルなタスクがサービスされた後に前記プロセッサを再びスリープに戻す段階をさらに含む、請求項１０に記載の方法。
12. 前記プロセッサによってサービスが提供されるタスクを受信する段階と、
    前記タスクを少なくともブレイクイーブン期間の間待機させておけるかを確認する段階と、
    前記タスクを前記ブレイクイーブン期間の間待機させておける場合は、前記プロセッサを前記ブレイクイーブン期間に関連したスリープステートとし、前記タスクのサービスを遅延する段階と
    をさらに備える請求項７から請求項１１のいずれか１つに記載の方法。
13. 前記ブレイクイーブン期間の前にサービスを必要とするその他のタスクがあるかどうかを確認し、その他のタスクが前記ブレイクイーブン期間の前にサービスを必要とする場合は、前記プロセッサを前記スリープステートに置かない段階を含む、
    請求項１２に記載の方法。
14. 前記スリープステートは、前記プロセッサに関連したキャッシュのフラッシュを伴う、請求項１２または請求項１３に記載の方法。

Images