特許 6093036 周期的アクティビティアライメント

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6093036

(24)【登録日】2017年2月17日

(45)【発行日】2017年3月8日

(54)【発明の名称】周期的アクティビティアライメント

(51)【国際特許分類】

   G06F 1/32 20060101AFI20170227BHJP

   G06F 9/48 20060101ALI20170227BHJP

【ＦＩ】

   G06F1/32 Z

   G06F9/46 452F

【請求項の数】25

【全頁数】10

(21)【出願番号】特願2015-550376(P2015-550376)

(86)(22)【出願日】2013年6月26日

(65)【公表番号】特表2016-511856(P2016-511856A)

(43)【公表日】2016年4月21日

(86)【国際出願番号】US2013047778

(87)【国際公開番号】WO2014105177

(87)【国際公開日】20140703

【審査請求日】2015年6月24日

(31)【優先権主張番号】13/730,074

(32)【優先日】2012年12月28日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ゴルバトフ，ユージーン

(72)【発明者】

【氏名】ディーフェンバウ，ポール エス．

(72)【発明者】

【氏名】クロフォード，ジョン エイチ．

(72)【発明者】

【氏名】クマール，アニル ケイ．

(72)【発明者】

【氏名】グレコ，リチャード ジェイ．

【審査官】 白石 圭吾

(56)【参考文献】

【文献】 米国特許出願公開第２０１０／００７７２４３（ＵＳ，Ａ１）

【文献】 特開２０１０−１９１９４５（ＪＰ，Ａ）

【文献】 特表２０１０−５３９７５３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １／３２

Ｇ０６Ｆ ９／４８

(57)【特許請求の範囲】

【請求項1】

プラットフォームであって、
一以上の入出力デバイス及びシステムコントローラを含む複数のデバイスと、
パワーマネジメントユニットであって、
前記プラットフォームに関連するレイテンシー制約を決定するレイテンシーモジュールと、
レイテンシー制約に基づいてアイドルウィンドウを決定するアイドルネスモジュールと、
前記複数のデバイスに、アイドルウィンドウにおいてアクティビティを停止するように命令するアライメントモジュールとを有するパワーマネジメントユニットと
を有し、
タイマーをさらに含み、前記アライメントモジュールは前記タイマーをレイテンシー制約に基づき設定する、
プラットフォーム。

【請求項2】

前記パワーマネジメントユニットは、アイドル状態において前記プラットフォームの一以上のコンポーネントをスリープ状態にするパワーマネジメントロジックをさらに含む、請求項１に記載のプラットフォーム。

【請求項3】

アクティビティは外部通信を含み、アイドルウィンドウはプラットフォーム全体のアイドルウィンドウである、請求項１に記載のプラットフォーム。

【請求項4】

前記アライメントモジュールは前記タイマーの満了に応じてアクティブウィンドウを開始する、請求項１に記載のプラットフォーム。

【請求項5】

前記アライメントモジュールは前記複数のデバイスに、アクティビティを再開するように命令して、アクティブウィンドウを開始する、請求項４に記載のプラットフォーム。

【請求項6】

レイテンシー制約はサービス要求と性能レベル要求のうちの一以上に基づき決定される、請求項１ないし５いずれか一項に記載のプラットフォーム。

【請求項7】

プラットフォームに関連するレイテンシー制約を決定するレイテンシーモジュールと、
レイテンシー制約に基づいてアイドルウィンドウを決定するアイドルネスモジュールと、
前記プラットフォームの複数のデバイスに、アイドルウィンドウにおいてアクティビティを停止するように命令するアライメントモジュールと
を有し、
タイマーをさらに含み、前記アライメントモジュールは前記タイマーをレイテンシー制約に基づき設定する、
装置。

【請求項8】

前記プラットフォームをアイドルウィンドウにおいてスリープ状態にするパワーマネジメントロジックをさらに含む、請求項７に記載の装置。

【請求項9】

アクティビティは外部通信を含み、アイドルウィンドウはプラットフォーム全体のアイドルウィンドウである、請求項７に記載の装置。

【請求項10】

前記アライメントモジュールは前記タイマーの満了に応じてアクティブウィンドウを開始する、請求項７に記載の装置。

【請求項11】

前記アライメントモジュールは前記複数のデバイスに、アクティビティを再開するように命令して、アクティブウィンドウを開始する、請求項１０に記載の装置。

【請求項12】

レイテンシー制約はサービス要求と性能レベル要求のうちの一以上に基づき決定される、請求項７ないし１１いずれか一項に記載の装置。

【請求項13】

プラットフォームに関連するレイテンシー制約を決定するステップと、
レイテンシー制約に基づいてアイドルウィンドウを決定するステップと、
前記プラットフォームの複数のデバイスに、アイドルウィンドウにおいてアクティビティを停止するように命令するステップと
を有し、
レイテンシー制約に基づいてタイマーを設定するステップをさらに含む、
方法。

【請求項14】

前記プラットフォームの一以上のコンポーネントをアイドルウィンドウにおいてスリープ状態にするステップをさらに含む、請求項１３に記載の方法。

【請求項15】

アクティビティは外部通信を含み、アイドルウィンドウはプラットフォーム全体のアイドルウィンドウである、請求項１４に記載の方法。

【請求項16】

前記タイマーの満了に応じてアクティブウィンドウを開始するステップをさらに含む、請求項１３に記載の方法。

【請求項17】

アクティブウィンドウを開始するステップは、前記複数のデバイスにアクティビティを再開するように命令するステップを含む、請求項１６に記載の方法。

【請求項18】

レイテンシー制約はサービス要求と性能レベル要求のうちの一以上に基づき決定される、請求項１３ないし１７いずれか一項に記載の方法。

【請求項19】

プラットフォームに、
前記プラットフォームに関連するレイテンシー制約を決定するステップと、
レイテンシー制約に基づいてアイドルウィンドウを決定するステップと、
前記プラットフォームの複数のデバイスに、アイドルウィンドウにおいてアクティビティを停止するように命令するステップと、
を実行させ、
さらに、前記プラットフォームに、レイテンシー制約に基づきタイマーを設定させる、コンピュータプログラム。

【請求項20】

前記プラットフォームに、前記プラットフォームの一以上のコンポーネントをアイドルウィンドウにおいてスリープ状態にさせる、請求項１９に記載のコンピュータプログラム。

【請求項21】

アクティビティは外部通信を含み、アイドルウィンドウはプラットフォーム全体のアイドルウィンドウである、請求項２０に記載のコンピュータプログラム。

【請求項22】

前記プラットフォームに、前記タイマーの満了に応じてアクティブウィンドウを開始させる、請求項１９に記載のコンピュータプログラム。

【請求項23】

前記プラットフォームに、前記複数のデバイスにアクティビティを再開し、アクティブウィンドウを開始するように命令させる、請求項２２に記載のコンピュータプログラム。

【請求項24】

レイテンシー制約はサービス要求と性能レベル要求のうちの一以上に基づき決定される、請求項１９ないし２３いずれか一項に記載のコンピュータプログラム。

【請求項25】

請求項１９ないし２４いずれか一項に記載のコンピュータプログラムを格納した非一時的コンピュータ読み取り可能記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

実施形態は概して計算プラットフォームにおけるパワーマネジメントに関する。より具体的には、実施形態は計算プラットフォームにおけるパワー効率を改善する周期的アクティビティアライメントに関する。

【背景技術】

【0002】

計算プラットフォームはパワー消費を低減するためにアイドル時間中にさまざまなスリープ状態に入ることがある。しかし、セミアクティブワークロードにおいては、プロセッサ／グラフィックスのコア、メインメモリ、システムインターコネクトなどプラットフォームの主要要素が少しでもアクティブになるので、スリープ状態に入ることは、実際にはディスエーブルされることがある。したがって、従来のプラットフォームでは、一般的なセミアクティブワークロードを処理する時、エネルギー効率が急激に低下することがある。

【図面の簡単な説明】

【0003】

添付した図面を参照して、以下の明細書と特許請求の範囲とを読めば、当業者には、本発明の実施形態のいろいろな有利性が明らかとなるであろう。

【図1】一実施形態によるパワーマネジメントユニットの一例を示すブロック図である。

【図2】一実施形態による計算プラットフォームにおけるパワーマネジメント方法の一例を示すフローチャートである。

【図3A】実施形態によるアイドルウィンドウの例を示すタイムラインである。

【図3B】実施形態によるアイドルウィンドウの例を示すタイムラインである。

【図4】一実施形態によるプラットフォームの一例を示すブロック図である。

【発明を実施するための形態】

【0004】

図１は、パワーマネジメントユニット（ＰＭＵ）１０（１０ａ−１０ｄ）を示す。これは計算プラットフォームにおけるエネルギー効率をより高くするのに用い得る。計算プラットフォームは、例えば、計算機能を有するモバイルデバイス（例えば、パーソナルデジタルアシスタント（ＰＤＡ）、ラップトップ、スマートタブレット）、通信機能を有するモバイルデバイス（例えば、無線スマートフォン）、画像化機能を有するモバイルデバイス、メディア再生機能を有するモバイルデバイス（例えば、スマートテレビジョン（ＴＶ））、またはこれら機能の組み合わせて有するモバイルデバイス（例えば、モバイルインターネットデバイス（ＭＩＤ））などである。図示したＰＭＵ１０は、サーバ、デスクトップコンピュータ、ワークステーションなどの固定プラットフォームで用いることもできる。

【0005】

図示した例では、サービス品質（ＱｏＳ）モジュール１０ａ（例えば、レイテンシーモジュール）は、プラットフォームに関連するレイテンシー制約を決定する。レイテンシー制約は、サービス要求（例えば、ＱｏＳ要求、サービスレベルアグリーメント（ＳＬＡ）要求）、性能レベル要求（Ａｄｖａｎｃｅｄ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｐｏｗｅｒ Ｉｎｔｅｒｆａｃｅ（ＡＣＰＩ）性能状態要求（例えば、ＡＣＰＩ Ｓｐｅｃｉｆｉｃａｔｉｏｎ，Ｒｅｖ．５．０ａ，Ｄｅｃｅｍｂｅｒ６，２０１１））などに基づいて決定できる。レイテンシー関連要求は、例えば、プラットフォームにおいて実行されている一以上のアプリケーション及び／またはオペレーティングシステム（ＯＳ）に関連するプラットフォームエージェント１２によりされる。後でもっと詳しく説明するが、レイテンシー制約により、プラットフォームのワークロードにより許容される最大レイテンシーが決まる。例えば、ワークロードがｘミリ秒以内に終わることをサーバワークロードのＳＬＡが規定していたり、ＡＣＰＩ性能状態（Ｐ状態）が（例えば、ルックアップテーブルを介して）最大レイテンシーを伴っていたりすることなどがある。要求は、ＰＭＵ１０に直接発行しても、例えば、一以上のレジスタ値、コンフィギュレーション設定などを変更することにより、ＰＭＵ１０に間接的に発行してもよい。

【0006】

ＰＭＵ１０は、レイテンシー制約に基づいてアイドルネスウィンドウを決定するアイドルモジュール１０ｂも含む。一例では、アイドルウィンドウはレイテンシー許容度と予測アイドルネスの関数である（例えば、アイドルウィンドウ＝予測アイドルネス＋レイテンシー許容度）。ＰＭＵ１０は、複数のデバイス１４に、アイドルウィンドウ中に一以上のアクティビティ（例えば、外部通信）をやめるように指示するアライメントモジュール１０ｃも含む。デバイス１４は、例えば、入出力（ＩＯ）デバイス、プロセッサ、システムコントローラなどを含み、そのデバイス１４のうちの一または複数が割り込み、ＤＭＡ（ダイレクトメモリアクセス）要求、ファブリックアクセス要求などを発行した時に、プラットフォームがスリープ状態に入るのを防ぐ。それゆえ、ＰＭＵ１０は、プラットフォームのすべてのデバイスのアライメントを強制し、プラットフォーム全体にわたるアイドルウィンドウを生成する。一例では、ＰＭＵ１０がタイマー１６を用いていつアイドルウィンドウが閉じたか／終了したか決定し、アライメントモジュール１０ｃがタイマー１６の満了に応じてアクティブウィンドウを開始する。図示したＰＭＵ１０は、アイドルウィンドウ中にプラットフォームをスリープ状態にするパワーマネジメント（ＰＭ）ロジック１０ｄも含む。特に注目すべきなのは、デバイス１４に通信／アクティビティを強制的にやめさせることにより、アライメントモジュール１０ｃは、単にアイドルウィンドウを延長するのではなく、自然に生じる（又は生じない）プラットフォーム全体にわたるアイドルウィンドウを生成できる。さらに、ＰＭロジック１０ｄにより選択されるスリープ状態は、図示したアプローチを用いて、より深く、より頻繁で、より長く続き、エネルギー効率が非常によくなり、バッテリーが長持ちし、性能が向上する。

【0007】

図２は計算プラットフォームにおけるパワーマネジメント方法２０を示す図である。方法２０は、例えば、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、ファームウェア、フラッシュメモリなど機械又はコンピュータ読み取り可能記憶媒体に記憶された一組の論理命令として、例えば、プログラマブルロジックアレイ（ＰＬＡ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、コンプレックスプログラマブルロジックデバイス（ＣＰＬＤ）などの構成可能ロジックで、例えば、特定目的集積回路（ＡＳＩＣ）、相補的金属酸化物半導体（ＣＭＯＳ）又はトランジスタトランジスタロジック（ＴＴＬ）技術などの回路技術を用いた固定機能ロジックハードウェアで、又はこれらの任意の組み合わせで実装可能である。例えば、方法２０に示した動作を実行するコンピュータプログラムコードは、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語やＣプログラミング言語や同様のプログラミング言語などの従来の手続型プログラミング言語や同様のプログラミング言語を含む１つ以上のプログラミング言語の任意の組み合わせで記述できる。

【0008】

図示した処理ブロック２２は、プラットフォームに関連するレイテンシー制約を決定する。前述の通り、レイテンシー制約はサービス要求、性能レベル要求などに基づいて決定でき、プラットフォームの最大レイテンシー及び／または上で実行されるワークロードを確定し得る。ブロック２４が、レイテンシー制約に基づいてアイドルウィンドウを決定し、ブロック２６が、プラットフォームの複数のデバイスにアイドルウィンドウ中は一以上のアクティビティを停止するように命令する。アクティビティの停止には、ＤＭＡ要求や割り込みなどのデータのバッファリングをして、ＩＯアクティビティが生じないようにすること、デバイススリープ状態に入ることなどが含まれる。したがって、例示のアプローチにより、プラットフォーム中のすべてのデバイス／コントローラ／ブロックを強制的にアライメントし、システム全体としてのアイドルウィンドウを生成する。かかるアプローチにより、アイドルウィンドウが自然に生じるのを待つだけの従来のソリューションに対する大きな優位性が得られる。

【0009】

アイドルウィンドウ中に遅延する要求に関して、パワーマネジメントユニットの観点から、ＩＯ要求により（例えば、デバイスからの）アップストリーム又は（例えば、ＯＳ／ソフトウェアからの）ダウンストリームが始まる。両者はアイドルウィンドウ中に遅延し得るが、それぞれのレイテンシー許容度は別々の最適化として分けて処理できる。例えば、ＩＯデバイスがメインメモリにアクセスするレイテンシー制約は、ソフトウェアが割り込みを受けるレイテンシー制約よりも非常に厳しい。

【0010】

ブロック２６はタイマー１６（図１参照）などのタイマーの設定も含むが、これについてはすでに説明した。例示のブロック２８において、プラットフォームデバイスからの任意の未処理要求を処理し、プラットフォーム及び／又はプロセッサをＡＣＰＩ低パワー状態などのスリープ状態にする。アイドルウィンドウが閉じられたか／過ぎたかの判断はブロック３０において行い得る。アイドルウィンドウが閉じられたか／過ぎたと判断されたとき、例示のブロック３２において、アクティブウィンドウが始まり、プラットフォーム／プロセッサはスリープ状態から出る。アクティブウィンドウの開始には、アクティビティを再開するようにデバイスに指示することが含まれる。データ及び／または処理する命令、トランザクション、メッセージ、ＤＭＡ要求、割り込みを有する任意のデバイスは、プラットフォームに適当な信号を発行して、問題となっているアクティビティを行い得る。

【0011】

また、方法２０の一部は条件が変化するまで、比較的長い時間にわたり反復し得る。さらに、方法２０は、プラットフォームの利用がある閾値（例えば、２０％、低コアＣ６利用率など）より高くなったと判断したとき、ディスエーブルされる。例えば、プラットフォーム利用率があるパーセンテージより高いとき、プラットフォーム全体にわたるアイドルウィンドウの強制的な生成は生産的ではないと考えられる。同様に、比較的多くのコアが深いスリープ状態には入っていないと判断したとき、例示のアプローチはバイパスしてもよい。

【0012】

図３Ａはタイムライン３４を示し、プラットフォームデバイスに一以上のアクティビティを停止するように命令することにより、アイドルウィンドウ３６（Δ_ｔＩ）が生成される。例示の例では、レイテンシー制約ウィンドウ（Δ_ｔＬ）が決定され、レイテンシー制約ウィンドウの初めをマークするタイマーアーミング（ｔｉｍｅｒ ａｒｍｉｎｇ）４０が行われる。アイドルウィンドウ３６においてプラットフォーム及び／又はプロセッサをスリープ状態にする前に、プラットフォームデバイスからの一以上のペンディング要求４２が処理される。タイマー満了４４となり、アイドルウィンドウ３６の終わりをマークする。プラットフォーム／プロセッサはスリープ状態から出て、レイテンシー制約ウィンドウ間に生じるアクティブウィンドウにおいて情報を処理する。

【0013】

図３Ｂは他のタイムライン３５を示し、プラットフォームデバイスに一以上のアクティビティを停止するように命令することにより、アイドルウィンドウ（Δ_ｔＩ）が生成される。例示では、最終的ＩＯ要求の後、アイドルウィンドウ中のある時点ｔ_０において、ＩＯ要求がアクノレッジされるが、対応するＩＯ転送は遅延される。ＩＯ要求はアイドルウィンドウ中に生じるからである。また、時刻ｔ_０において、タイマーアーミング３７を行い、レイテンシー制約ウィンドウ（Δ_ｔＬ）の初めをマークする。その後、タイマー満了３９が生じ、アイドルウィンドウの終わりをマークする。それゆえ、例示のアプローチにより、アイドルウィンドウはレイテンシー許容度をすべて使える。簡単に言えば、アイドルウィンドウはレイテンシー制約ウィンドウより長くても短くてもよい。アイドルウィンドウがレイテンシー制約ウィンドウより長ければ、まだレイテンシー許容度がある。かかるシナリオでは、システムは、最初のアクセスが試みられるまで、カウントを開始しない。

【0014】

ここで図４を参照して、モバイルプラットフォーム４６を示す。プラットフォーム４６は、（例えば、サーバ、ワークステーション、デスクトップコンピュータ、ＰＤＡ、ノートブックコンピュータ、スマートタブレットなどの）計算機能を有するデバイス、（例えば、無線スマートフォンなどの）通信機能を有するデバイス、画像取得機能を有するデバイス、メディア再生機能を有するデバイス（例えば、スマートＴＶ）、又は（例えば、ＭＩＤなどの）上記機能の任意の組合せを有するデバイスの一部であってもよい。例示では、プラットフォーム４６は、プロセッサ４８、システムメモリ５０、ネットワークコントローラ５２、オーディオＩＯデバイス５４、固体ディスク（ＳＳＤ）５６、及びＩＯモジュール５８を含む。プロセッサ４８は、集積メモリコントローラ（ＩＭＣ）６０、パワーマネジメントユニット（ＰＭＵ）６２、及び一以上のプロセッサコア６４を有するコア領域を含む。あるいは、プロセッサ４８とＩＯモジュール５８は、場合によっては、システムオンチップ（ＳｏＣ）として、半導体ダイに実装してもよい。また、プラットフォーム４６は、その他の、専用グラフィックスコンポーネント（図示せず）などのコンポーネントを含んでいてもよい。

【0015】

図示したＩＯモジュール５８は、チップセットのうちサウスブリッジやサウスコンプレックスと呼ばれることもあるが、ホストコントローラとして機能し、ネットワークコントローラ５２と通信する。ネットワークコントローラ５２は、幅広い目的のため、オフプラットフォームの通信機能を提供する。この目的には、携帯電話（例えば、ワイドバンドコード分割多重アクセスＷ−ＣＤＭＡ（ユニバーサルモバイルテレコミュニケーションシステムＵＭＴＳ）、ＣＤＭＡ−２０００（ＩＳ−８５６／ＩＳ−２０００）など）、ＷｉＦｉ（ワイヤレスフィデリティ、例えば、ＩＥＥＥ８０２．１１−２００７、ワイヤレスローカルエリアネットワークＬＡＮメディアアクセスコントロール（ＭＡＣ）及び物理レイヤ（ＰＨＹ）仕様）４Ｇ ＬＴＥ（第４世代ロングタームエボリューション）、ブルートゥース（例えば、ＩＥＥＥ８０２．１５．１−２００５、ワイヤレスパーソナルエリアネットワーク）、ＷｉＭａｘ（例えば、ＩＥＥＥ８０２．１６−２００４、ＬＡＮ／ＭＡＮブロードバンドワイヤレスＬＡＮ）、グローバルポジショニングシステム（ＧＰＳ）、スプレッドスペクトラム（例えば、９００ＭＨｚ）、及びその他のラジオ周波数（ＲＦ）テレフォニー目的を含む。また、ＩＯモジュール５８は、かかる機能をサポートする一以上のワイヤレスハードウェア回路ブロックも含む。

【0016】

システムメモリ５０は、例えばダブルデータレート（ＤＤＲ）シンクロナスダイナミックランダムアクセスメモリ（ＳＤＲＡＭ、例えばＤＤＲ３ ＳＤＲＡＭ ＪＥＤＥＣ標準ＪＥＳＤ７９−３Ｃ、２００８年４月）モジュールを含む。システムメモリ５０のモジュールは、例えば、シングルインラインメモリモジュール（ＳＩＭＭ）、デュアルインラインメモリモジュール（ＤＩＭＭ）、スモールアウトラインＤＩＭＭ（ＳＯＤＩＭＭ）などに組み込まれている。ＳＳＤ５６は、一又は複数のＮＡＮＤ（否定ＡＮＤ）チップを含み、大容量データ記憶及び／又は大量の並列処理を提供する。シリアルＡＴＡ（ＳＡＴＡ、例えば、ＳＡＴＡ Ｒｅｖ．３．０ Ｓｐｅｃｉｆｉｃａｔｉｏｎ，Ｍａｙ２７，２００９，ＳＡＴＡ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ／ＳＡＴＡ−ＩＯ）バス、又はＰＣＩエクスプレスグラフィックス（ＰＥＧ、例えば、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔｓ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）Ｅｘｐｒｅｓｓ×１６Ｇｒａｐｈｉｃｓ １５０Ｗ−ＡＴＸ Ｓｐｅｃｉｆｉｃａｔｉｏｎ１．０，ＰＣＩ Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐ）バスなどの標準的バスでＩＯモジュール５８に接続された、別のＡＳＩＣコントローラとして実装されたＮＡＮＤコントローラを含むソリューションもある。また、ＵＳＢ（ユニバーサルシリアルバス、例えば、ＵＳＢ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ３．０，ＵＳＢ Ｉｍｐｌｅｍｅｎｔｅｒｓ Ｆｏｒｕｍ）フラッシュ記憶デバイスとしてＳＳＤ５６を用いることもできる。

【0017】

それゆえ、プロセッサ４８のコア６４、システムメモリ５０、ネットワークコントローラ５２、ＩＯモジュール５８、オーディオＩＯデバイス５４及びＳＳＤ５６は、プラットフォーム４６のデバイスと考えられ、ＰＭＵ６２の機能は概して、既に述べたＰＭＵ１０（図１）の機能と同様である。したがって、ＰＭＵ６２は、プラットフォーム４６に関連するレイテンシー制約を決定し、そのレイテンシー制約に基づいてアイドルウィンドウを決定し、アイドルウィンドウ中では一以上のアクティビティを停止するよう、コア６４、システムメモリ５０、ネットワークコントローラ５２、オーディオＩＯデバイス５４、ＳＳＤ５６及び／またはＩＯモジュール５８に命令する。さらに、ＰＭＵ６２はアイドルウィンドウ中にプラットフォーム４６及び／またはプロセッサ４８をスリープ状態にする。このスリープ状態は従来のソリューションのものよりも深く、頻繁であり、長く続く。プラットフォームデバイス自体は、場合によってはより深いスリープ状態に入ってもよい。

【0018】

このように、ここに説明の技術によりクライアントシステムとサーバシステムの両方に大きな利益が提供できる。例えば、より大きなエネルギー効率とバッテリー寿命でウェブブラウジングやテレビ会議などのセミアクティブワークロードを、モバイルプラットフォームで実行できる。サーバでは、コア数が増えても、プラットフォームアイドル状態に入る機会は保たれる。例えば、１２コア（すなわち、１ソケットあたり２４スレッド）を有するデュアルプロセッササーバシステムでは、アクティビティの長い「ドリブル（ｄｒｉｂｂｌｅｓ）」をアクティビティの短いバーストとそれに続く準決定性アイドルウィンドウ／時間に変換することにより、パッケージＣ状態とプラットフォームアイドル状態（例えば、ＡＣＰＩ）を用い得る。さらに、ＱｏＳ制約とＰＬＡコミットメントが、ＯＳとアプリケーションにトランスパレントに、満たされ得る。実際、エネルギー効率の節約は、ここに説明した技術によるセミアクティブワークロードの場合、２、３倍大きい。

【0019】

それゆえ、実施形態には、プラットフォームに関連するレイテンシー制約を決定するステップと、そのレイテンシー制約に基づいてアイドルウィンドウを決定するステップとを有する方法が含まれる。また、プラットフォームの複数のデバイスは、アイドルウィンドウ中に一以上のアクティビティを停止するように命令される。また、実施形態には、プロセッサにより実行されると、プラットフォームに、それに関連するレイテンシー制約を決定させる一組の命令を有する非一時的コンピュータ読み取り可能記憶媒体が含まれる。この命令は、実行されると、そのプラットフォームに、レイテンシー制約に基づいてアイドルウィンドウを決定させ、プラットフォームの複数のデバイスに一以上のアクティビティを停止するよう命令させる。

【0020】

実施形態には、プラットフォームに関連するレイテンシー制約を決定するレイテンシーモジュールと、レイテンシー制約に基づきアイドルウィンドウを決定するアイドルネスモジュールとを有する装置が含まれる。また該装置は、プラットフォームの複数のデバイスに、アイドルウィンドウ中に一以上のアクティビティを停止するよう命令するアライメントモジュールを有する。

【0021】

また、実施形態には、複数のデバイスを有するプラットフォームが含まれる。その複数のデバイスには、一以上の入出力（ＩＯ）デバイスとシステムコントローラが含まれる。また、プラットフォームは、プラットフォームに関連するレイテンシー制約を決定するレイテンシーモジュールと、レイテンシー制約に基づいてアイドルウィンドウを決定するアイドルネスモジュールと、複数のデバイスに、アイドルウィンドウ中に一以上のアクティビティを停止するように命令するアライメントモジュールとを有するパワーマネジメントユニットを含み得る。

【0022】

本発明の実施形態は、すべてのタイプの半導体集積回路（ＩＣ）チップで利用できる。これらのＩＣチップの例としては、プロセッサ、コントローラ、チップセットコンポーネント、ＰＬＡ、メモリチップ、ネットワークチップ、ＳｏＣ、ＳＳＤ／ＮＡＮＤコントローラＡＳＩＣなどがあるが、これらに限定されない。また、いくつかの図面では、線で信号導線を表した。いくつかの線は異なり、より多くの構成信号経路を示し、複数のラベルを有し、複数の構成信号経路を示し、及び／又は１つ以上の端に矢印を有し、主な情報フロー方向を示す。しかし、これは、限定と解釈してはならない。むしろ、かかる付加的詳細は、１つ以上の実施形態と共に、回路の理解を促進するために用いられている。表示したどの信号線も、追加的情報を有していようがいまいが、複数の方向に進む１つ以上の信号を有していてもよく、例えば、差動ペアと実装されたデジタル又はアナログライン、光ファイバライン、及び／又は単一終端ラインなどの所望のタイプの信号方式で実装してもよい。

【0023】

例示したサイズ／モデル／値／範囲は所与のものであってもよいが、本発明の実施形態はこれに限定されない。（フォトリソグラフィなどの）生産技術が時間とともに成熟してくるので、小さいサイズのデバイスを生産できると期待される。また、ＩＣチップその他のコンポーネントへの周知のパワー／グラウンド接続は、図示と説明とを簡単にするため、及び本発明の実施形態の態様を分かりにくくしないように、図示したものもあれば図示していないものもある。さらに、構成をブロック図の形式で示したが、それは本発明の実施形態を分かりにくくしないようにするため、またかかるブロック図構成の実装に関する具体的事項は実施形態を実装するプラットフォームに大きく依存すること、すなわちかかる具体的事項は当業者の管轄事項であることを考慮したものである。本発明の実施形態を説明するために、（例えば、回路などの）具体的な詳細事項を記載した場合、当業者には言うまでもなく、こうした具体的な詳細事項が無くても、又はそれを変更しても、本発明の実施形態を実施できる。よって、上記の説明は、限定ではなく例示と考えるべきである。

【0024】

「結合した」との用語は、ここでは問題となるコンポーネント間の、直接的又は間接的な任意のタイプの関係を言い、電気的結合、機械的結合、流体的結合、光学的結合、光磁気的結合、電気機械的結合その他の結合に当てはまる。また、「第１の」、「第２の」等の用語は、ここでは、説明を容易にするためにだけに使われており、特に断らなければ時間的な意味は無い。

【0025】

当業者には言うまでもなく、本発明の実施形態の幅広い手法は、いろいろな形式で実施できる。それゆえ、本発明の実施形態をその具体的な例に関連して説明したが、当業者には図面、明細書、及び特許請求の範囲を研究すればその他の修正が明らかであるから、本発明の実施形態の範囲は具体例に限定されない。

【図1】

【図2】

【図3A】

【図3B】

【図4】