JP2015520429A - 効率的な消費電力管理のための動的インタラプト再コンフィグレーション - Google Patents

Abstract

インタラプトの動的な再コンフィグレーションを通じて効率的な消費電力管理を促進するための方法、装置、および、システムである。インタラプトベクトルは、マルチコアプロセッサの中の種々のプロセスに対してマップされ、プロセッサコア上のワークロードがモニタされる。所与のプロセッサに対するインタラプトワークロードが閾値以下に低下したことを検出した場合に、インタラプトベクトルは、プロセッサコアに現在マップされているインタラプトベクトルを少なくとも一つの他のプロセッサコアに再マッピングすることによって、インタラプトベクトルが動的に再コンフィグレーションされる。再コンフィグレーションの後では、プロセッサコアにマップされたインタラプトベクトルが存在しないようにである。そして、コアを、より深いアイドル状態の中に置くことができる。類似のオペレーションを追加のプロセッサコアに対して適用することができ、インタラプトベクトルをより少ないプロセッサコア上に納めることをもたらす。アイドル状態から出てくるコアの検出に応じて、ベクトルの一部をこれらのコアに対して再マップすることにより、インタラプトベクトルの再コンフィグレーションが実行されて、アクティブなコアに渡るベクトルの割り当てが再びバランスされる。

Description

本発明は、一般的にコンピュータシステムに関する。より特定的には、限定するものではなく、マルチコアプロセッサにおける消費電力の削減に関する。

インタラプトは、デバイスからのＣＰＵ（中央処理ユニット、つまりプロセッサ）に対するハードウェア信号であり、デバイスがアテンション（ａｔｔｅｎｔｉｏｎ）を必要としていることをＣＰＵに知らせ、かつ、ＣＰＵは現在の処理を停止してデバイスに応答すべきことをシグナルしている。ＣＰＵがインタラプトの優先度より低い優先度のタスクを実行している場合に、ＣＰＵは現行のスレッド（ｔｈｒｅａｄ）をサスペンドする。ＣＰＵは、次に、インタラプト信号を送付したデバイスに対するインタラプトハンドラを呼び出す。インタラプトハンドラは、デバイスに対してサービスし、インタラプトハンドラが戻ってくると、ＣＰＵは、そのインタラプトが発生した以前に行っていた処理を再開する。

古いバス技術におけるインタラプトは、「レガシー（”ｌｅｇａｃｙ））」または「ラインベース（”ｌｉｎｅ−ｂａｓｅｄ”）」インタラプトとして参照される。こうした技術を用いて、インタラプトは、バスの主ラインから分離して配線された一つまたはそれ以上の外部ピンを使用してシグナルされる。「アウトバンド（”ｏｕｔ ｏｆ ｂａｎｄ”）」として知られているプロセスである。ＰＣＩｅ（ペリフェラルコンポーネントインターコネクトエクスプレス）といった、より新しい技術では、インバンド（ｉｎ−ｂａｎｄ）メカニズムを通じてレガシーインタラプトをエミュレートすることによって、ソフトウェアのコンパチビリティを維持している。これらのエミュレートされたインタラプトは、ホストオペレーティングシステムによってレガシーインタラプトとして扱われる。ＰＣＩ規格によって定義されるラインベースインタラプトは、たった４つのラインに限定されており、複数のデバイスがしばしば共有されているために、レイテンシ（ｌａｎｔｅｎｃｙ）の増加を生じている。

ＰＣＩ２．２規格は、従来のラインベースインタラプトの代替として、ＭＳＩ（メッセージシグナルインタラプト）を導入した。インタラプトをトリガするために専用のピンを使用する代わりに、ＭＳＩは、特定のアドレスに対して所定の値を書き込むことによって、デバイスがインタラプトをトリガできるようにする。メッセージ宛て先アドレスおよびメッセージデータは、ＭＳＩ「ベクトル（”ｖｅｃｔｏｒ”）」として参照される。ＰＣＩ３．０は、ＭＳＩ−Ｘと呼ばれる、ＭＳＩの拡張形式を定義しており、ＭＳＩの制限された機能を取り扱っている。例えば、ＭＳＩにはアダプタ機能ごとに３２個のＭＳＩメッセージという制限があるが、ＭＳＩ−Ｘは、メッセージの数を２０４８個まで増加している。別の例として、ＭＳＩは、全てのメッセージが同一のグループのプロセッサを対象とするように、一つのＭＳＩメッセージアドレス値しか提供しない。ＭＳＩ−Ｘは、唯一のアドレスとそれぞれのメッセージに対するデータペアを提供することによって、この問題を克服している。

アドバンストプログラマブルインタラプトコントローラ（ＡＰＩＣ）が、１９９７年にインテル（登録商標）によって導入された。ＡＰＩＣは、本来は対称型マルチプロセッサ（ＳＭＰ）アーキテクチャを使用しているシステムにおいてインタラプトを管理することを目的としていた。マイクロソフト（登録商標）は、ＳＭＰシステム上でのＡＰＩＣの利益を観察して、オペレーティングシステムの中にユニプロセッサ（ｕｎｉ−ｐｒｏｃｅｓｓｏｒ）上でのＡＰＩＣに対するサポートをデザインした。今日、ＡＰＩＣは、実質的に全てのｘ８６ベースのコンピュータにおいて採用されている。ＣＰＵの内部、及び/又は、ＩＯチップの外部におけるコンポーネントのいずれかとしてである。

消費電力管理は、コンピュータを含む、電子デバイスの機能であり、アイドル時間（ｉｎａｃｉｔｉｖｉｔｙ）が存在するときに、電源オフ（”ｔｕｒｎ ｏｆｆ”）し、または、デバイスに係る所定の又は全ての領域をある低消費電力状態に置くように、試みる。マイクロプロセッサによって消費されるエネルギーを管理することは、バッテリーの寿命を延ばし、冷却のリクエストを削減し、電気的ノイズを削減し、かつ、オペレーション費用を削減する。モバイルコンピューティングが、よりユビキタス（ｕｂｉｑｕｉｔｏｕｓ）になってきているので、モバイル電子機器においては消費電力管理がより重要になってきている。ラップトップ、携帯電話、および、パーソナルデジタルアシスタント、といったものである。消費電力管理は、また、サーバ展開（例えば、サーバファームおよびデータセンタ）にも有利であり、デスクトップコンピュータに対しても同様である。

マイクロプロセッサおよびコンピュータシステムに対する消費電力管理の規格は、アドバンストコンフィグレーションアンドパワーインターフェイス（ＡＣＰＩ）であって、ヒューレットパッカード（登録商標）、インテル、マイクロソフト、フェニックス（登録商標）、および、東芝（登録商標）によって共同開発されたオープンインダストリー規格である。ＡＣＰＩは、ＯＳ指向のコンフィグレーション、消費電力管理、および、モバイル、デスクトップ、そしてサーバプラットフォームの温度管理、ができるようにする業界規格インターフェイスを確立している。１９９６年に最初に発行されたときに、ＡＣＰＩは、既存の、消費電力管理ＢＩＯＳコード、アドバンストパワーマメネジメント（ＡＰＭ）アプリケーションプログラミングインターフェイス（ＡＰＩｓ）、ＰＮＰＢＩＯＳ ＡＰＩｓ、および、マルチプロセッサ仕様（ＭＰＳ）テーブル、の集まりを、上手く定義された消費電力およびコンフィグレーションインターフェイス仕様へと発展させた。ＡＣＰＩ仕様書は、新たな消費電力管理技術が、一緒に動作し続けることを保証しながら、オペレーティングシステムおよびハードウェアにおいて独立して発展することを可能にしている。

インタラプトの動的な再コンフィグレーションを通じて効率的な消費電力管理を促進するための方法、装置、および、システムである。

インタラプトベクトルは、マルチコアプロセッサの中の種々のプロセスに対してマップされ、プロセッサコア上のワークロードがモニタされる。所与のプロセッサに対するインタラプトワークロードが閾値以下に低下したことを検出した場合に、インタラプトベクトルは、プロセッサコアに現在マップされているインタラプトベクトルを少なくとも一つの他のプロセッサコアに再マッピングすることによって、インタラプトベクトルが動的に再コンフィグレーションされる。再コンフィグレーションの後では、プロセッサコアにマップされたインタラプトベクトルが存在しないようにである。そして、コアを、より深いアイドル状態の中に置くことができる。類似のオペレーションを追加のプロセッサコアに対して適用することができ、インタラプトベクトルをより少ないプロセッサコア上に納めることをもたらす。アイドル状態から出てくるコアの検出に応じて、ベクトルの一部をこれらのコアに対して再マップすることにより、インタラプトベクトルの再コンフィグレーションが実行されて、アクティブなコアに渡るベクトルの割り当てが再びバランスされる。

上述の態様および本発明に付随する多くの有利な点は、以降の詳細な説明を参照することによって、添付の図面を考慮した場合に、より容易に理解され、同様により良く理解される。ここで、別に指定がない場合は、種々のビューを通じて、類似の参照番号は類似のパーツを参照するものである。
図１は、一つの実施例に従って、効率的な消費電力管理のためのインタラプトの動的な再コンフィグレーションをサポートするように構成されたコンピュータシステムに係る模式的なブロックダイヤグラムである。 図２は、一つの実施例に従って、効果的な動的インタラプトコンフィグレーションおよびインタラプトリクエストバランスのための選択的なソフトウェアコンポーネントを示すブロックダイヤグラムである。 図３は、一つの実施例に従って、効率的な消費電力管理のためのインタラプトの動的な再コンフィグレーションに対するオペレーションとロジックを説明するフローチャートである。 図４ａは、インタラプトベクトルが第１のプロセッサコアから再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第１の実施例を説明している。 図４ｂは、インタラプトベクトルが第１のプロセッサコアから再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第１の実施例を説明している。 図４ｃは、インタラプトベクトルが第１のプロセッサコアから再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第１の実施例を説明している。 図５ａは、インタラプトベクトルが第１のプロセッサコアから再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第２の実施例を説明している。 図５ｂは、インタラプトベクトルが第１のプロセッサコアから再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第２の実施例を説明している。 図５ｃは、インタラプトベクトルが第１のプロセッサコアから再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第２の実施例を説明している。 図６ａは、第１のコアがアクティブ状態に戻されて、全てのアクティブなコアに渡りロードバランスをもたらすようにンタラプトベクトルが再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第３の実施例を説明している。 図６ｂは、第１のコアがアクティブ状態に戻されて、全てのアクティブなコアに渡りロードバランスをもたらすようにンタラプトベクトルが再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第３の実施例を説明している。 図６ｃは、第１のコアがアクティブ状態に戻されて、全てのアクティブなコアに渡りロードバランスをもたらすようにンタラプトベクトルが再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第３の実施例を説明している。 図７ａは、第１のコアがアクティブ状態に戻されて、全てのアクティブなコアに渡りロードバランスをもたらすようにンタラプトベクトルが再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第４の実施例を説明している。 図７ｂは、第１のコアがアクティブ状態に戻されて、全てのアクティブなコアに渡りロードバランスをもたらすようにンタラプトベクトルが再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第４の実施例を説明している。 図７ｃは、第１のコアがアクティブ状態に戻されて、全てのアクティブなコアに渡りロードバランスをもたらすようにンタラプトベクトルが再マップされる状況下で、インタラプトベクトルの動的な再コンフィグレーションの第４の実施例を説明している。 図８ａは、コアをアイドル状態の置くことができるようにインタラプトベクトルがより少ないコア上に納められる状況下で、インタラプトファンイン（ｆａｎ ｉｎ）シーケンスに応じたインタラプトベクトルの動的な再コンフィグレーションの第５の実施例を説明している。 図８ｂは、コアをアイドル状態の置くことができるようにインタラプトベクトルがより少ないコア上に納められる状況下で、インタラプトファンイン（ｆａｎ ｉｎ）シーケンスに応じたインタラプトベクトルの動的な再コンフィグレーションの第５の実施例を説明している。 図８ｃは、コアをアイドル状態の置くことができるようにインタラプトベクトルがより少ないコア上に納められる状況下で、インタラプトイン（ｆａｎ ｉｎ）シーケンスに応じたインタラプトベクトルの動的な再コンフィグレーションの第５の実施例を説明している。 図９ａは、コアがアイドル状態からアクティブ状態に戻された際にインタラプトベクトルが新たに利用可能なプロセッサコアに再マップされる状況下で、インタラプトファンアウト（ｆａｎ ｏｕｔ）シーケンスに応じたインタラプトベクトルの動的な再コンフィグレーションの第６の実施例を説明している。 図９ｂは、コアがアイドル状態からアクティブ状態に戻された際にインタラプトベクトルが新たに利用可能なプロセッサコアに再マップされる状況下で、インタラプトファンアウト（ｆａｎ ｏｕｔ）シーケンスに応じたインタラプトベクトルの動的な再コンフィグレーションの第６の実施例を説明している。 図９ｃは、コアがアイドル状態からアクティブ状態に戻された際にインタラプトベクトルが新たに利用可能なプロセッサコアに再マップされる状況下で、インタラプトファンアウト（ｆａｎ ｏｕｔ）シーケンスに応じたインタラプトベクトルの動的な再コンフィグレーションの第６の実施例を説明している。

ここにおいて、効率的な消費電力管理のための動的インタラプト再コンフィグレーションを実施する方法、装置、および、システムに係る実施例が説明される。以降の説明においては、本発明開示に係る実施例のより完全な説明を提供するために数多くの詳細が説明される（ＰＣＩｅおよびＭＳＩベクトルの使用といったもの）。しかしながら、当業者にとっては、これら一つまたはそれ以上の特定の詳細がなくても、もしくは、他の方法、コンポーネント、材料、等を使用して、本発明を実行することができることが理解できよう。他のインスタンスにおいて、よく知られた構成、材料、またはオペレーションは、示されないか、または、詳細には説明されない。本発明の態様が不明瞭となるのを避けるためである。

この明細書の全体に渡る「一つの実施例」または「実施例」に対する言及は、実施例に関して説明された所定の特徴、構成、または、特性は、本願発明の少なくとも一つのの実施例に含まれる。従って、「一つの実施例において」または「実施例において」というフレーズがこの明細書の全体に渡って現れるが、必ずしもすべてが同一の実施例を参照するものではない。さらに、所定の特徴、構成、または、特性は、一つまたはそれ以上の実施例において、あらゆる好適なやり方で組み合わせることができる。

明確化のために、ここにおける図面の中のそれぞれのコンポーネントは、また、所定の参照番号より、むしろ、図面におけるラベルによって参照されてもよい。加えて、所定のタイプのコンポーネント（所定のコンポーネントとは対照的なものとして）を参照する参照番号は、後ろに「（ＴＹＰ）」が続く参照番号を用いて示され、「典型的」であることを意味している。これらのコンポーネントの構成は、簡素化または明確化のために図面には示されていないが実際には存在するような典型的な類似のコンポーネントであることが理解されよう。

図１は、一つの実施例に従って、効率的な消費電力管理のための動的なインタラプトの再コンフィグレーションを実施するための典型的なコンポーネントを示しているブロックレベルのダイヤグラムである。オペレーティングシステム（ＯＳ）と、種々のアプリケーション及びＯＳサービスは、コア１−ｎとラベル付けされた複数のプロセッサコア１０２を含むＣＰＵ１００上で実行される。一般的に、コアの数量ｎは、２から上の範囲であってよく、これらに限定されるわけではないが、２、４、６、８、１０、１２、１６、２０、２４、４８、６４、１２８、等を含んでいる。ＣＰＵ１００は、また、ＡＰＩＣ１０４および電力制御ユニット（ＰＣＵ）１０５を含んでいる。ダイヤグラムの中央は、ＮＩＣ（ネットワークインターフェイスコントローラ）であり、物理ポートのペア１０８と１１０、および、複数の論理ポート１１２−１から１１２−ｍを含んでいる。。ここで、ｍは、一つの実施例において、２０４８以下である。それぞれの論理ポートは、一つまたはそれ以上の関連する入力キュー（ｑｕｅｕｅ）１１４と出力キュー１１５を有している。ＮＩＣ１０６は、一つまたはそれ以上のＰＣＩｅリンクを介してＣＰＵ１００と通信するようにリンクされている。リンクは、説明のために、一つの幅広い両端矢印として示されている。一つまたはそれ以上のＰＣＩｅリンクは、現在又は将来のＰＣＩｅ仕様に従って種々のレーン幅を有してよい。これらに限定されるわけではないが、１×、２×、４×、８×、１６×、および、３２×といったものである。

オペレーションの最中に、種々のアプリケーションおよびサービスは、ＮＩＣ１１６を介して、および、通信リンク１２２と１２４に渡って、ネットワーク１２０と通信するようにリモートホスト１１８にリンクされている。一般的に、ネットワーク１２０は、種々のタイプのネットワークを表しており、ＬＡＮ、ＷＡＮ、インターネット、および、イントラネットを含んでいる。通信リンク１２２と１２４は、有線および無線リンクの両方を表しており、これらに限定されるわけではないが、イーサネット（登録商標）、８０２．１１ｘ、ＷｉＭＡＸ、および、モバイルデータキャリアリンク（例えば、ＧＳＭ（登録商標）、ＵＭＴＳ、ＣＤＭＡ、ＷＣＤＭＡ（登録商標），ＬＴＥ、等で実行されるデータサービス）を含んでいる。

実行時間オペレーションの最中に、種々のアプリケーションおよびＯＳサービスは、ホスト１１８のうち一つと接続するといった、種々の目的のためにネットワーク接続を確立する。例えば、ウェブブラウザといったアプリケーションは、ウェブサーバを含むホスト１１８とのＨＴＴＰ接続をオープンする。ホストに対するそれぞれの接続は、物理リンクとポートおよび関連するインフラストラクチャに渡るものである。しかしながら、複数の同時通信リンクをサポートするために、ＮＩＣ１０６および関連するファームウェアおよびソフトウェアリソースは、仮想ポートおよびキューの動的な配分（ａｌｌｏｃａｉｏｎ）をサポートしている。それぞれの物理リンクインスタンスが、対応する仮想ポートおよび対応する入力および出力キューと関連するようにである。このことは、部分的に、ＰＣＩｅの使用を通じて促進される。ＰＣＩｅは、発信元アドレスと宛先アドレスおよびペイロードデータを含む、種々のパケット構成を使用する、パケットベースのメッセージング（ｍｅｓｓａｇｉｎｇ）を採用している。さらに、ＮＩＣ１０６に関する非同期性のオペレーションおよびサービスリクエストをサポートするために、ＰＣＩｅは、ＭＳＩベクトルを採用して、対応するプロセッサインタラプトを呼び出す。図１においてＭＳＩ Ｖ１−ｍとラベル付けされた、ＭＳＩベクトル１２６によって示されるようにである。それぞれのＭＳＩベクトルは、ＰＣＩｅメッセージを含んでおり、ＰＣＩｅメッセージは、適用可能なアドレス情報およびＭＳＩベクトルであることを特定するヘッダー表示を含んでいる。

ＭＳＩベクトルを好適な処理リソースにマッピングするためのコーディネイションは、ＡＰＩＣ１０４および関連するデータ構造およびドライバと調整してＯＳによって管理される。ＯＳは、処理スレッドをＣＰＵリソースに配分することに責任がある。ＣＰＵリソースは、ＣＰＵハードウェア上で実行される場合は、物理的にＣＰＵコアを含んでおり、または、ＣＰＵハードウェア上で実行される仮想マシンマネージャ（ＶＭＭ）や類似のものによってホストされる仮想マシン上で実行される場合には、仮想コアまたはプロセッサを含んでよい。いくつかのインスタンスにおいて、物理的コアは、論理的コアとしてＯＳにさらされる。まるでＣＰＵがマルチスレッドコア（例えば、インテル製ＣＰＵはハイパースレッド（Ｈｙｐｅｒｔｈｒｅａｄｉｎｇ）をサポートしている）を使用しているようにといったものである。明確化および簡素化のために、物理的コアの割り当てがここにおいて説明される。しかしながら、当業者によれば、類似の技術が、論理的コアとＶＭＭ実施を用いて実施し得ることが理解されよう。

現代のオペレーティングシステムは、マルチスレッドアーキテクチャを採用しており、一つまたはそれ以上の実行スレッドがそれぞれのアプリケーションまたはサービスに配分され、それぞれの処理リソースに対して割り当てられる。スレッドは、タイムスライス（ｔｉｍｅ−ｓｌｉｃｉｎｇ）スキームを使用してプロセッサコア上で実行される。ここで、所与のスレッドは実行のために対応するタイムスライスに対して配分され、コンテクストスイッチと続いて起こるタイムスライスの最中の別のスレッドの実施が後に続く。このことは、進行ベースで継続される。

何年もの間、プロセッサは単一のプロセッサコアを採用し、そのため、マルチスレッドＯＳのスレッドは、単一のプロセッサコアだけに対して配分されるだろう。いくつかのアーキテクチャも、また、インタラプトピンを使用して（ＭＳＩおよびＭＳＩ−Ｘといった、より最近のインタラプトスキームとして）ハードウェア信号ベースのインタラプトをサポートしていた。その下で、物理的ＣＰＵピン上の電気的信号の使用を通じてインタラプト信号が呼び出され、ＣＰＵハードウェアは、ＯＳとは独立したやり方でハードウェアファシリティを介してインタラプトのサービスをスケジュールすることによってインタラプトに対応する（もしくは、マスク不能なインタラプト（ＮＭＩ）である場合には直ちにインタラプトをサービスする）。

マルチコアプロセッサ、ＡＰＩＣ、および、ＭＡＳＩ／ＭＳＩ−Ｘの出現は、インタラプト処理の新たなパラダイムを導入した。最初に、実行スレッドを単一のプロセッサコアに対して配分することに代わって、スレッドは複数のプロセッサコアに渡って配分される。典型的には、ラウンドロビン（ｒｏｕｎｄ−ｒｏｂｉｎ）配分スキームや類似のものを使用したものである。このことは、プロセッサコアの使用が、ロードバランスされることを保証して、ＣＰＵの処理スループットを最大化している。しかしながら、複数の実行ユニット（つまり、プロセッサコア）があるからには、インタラプトに対してサービスするためにインタラプトされる一つ以上の単一の実行ユニットが存在する。結果として、マッピングインタラプトリクエストをプロセッサコアに対してマップするためのメカニズムが採用された。このメカニズムは、ＡＰＩＣの使用を介して有効化され、ベクトルマッピング情報を含んでいる。図１におけるＡＰＩＣベクトルマップによって図示されるように、それぞれのＭＳＩベクトルを対応するプロセッサコアにマップする情報であり、進行中のオペレーションの最中に、ＩＲＱバランサ１３０の使用を通じて動的に更新される。以下のさらに詳細が説明されるようにである。

ＭＳＩ／ＭＳＩ−Ｘインタラプトリクエスト（ＩＲＱ）は、以下のやり方でサービスされる。最初に、インタラプトソースデバイスのＰＣＩｅインターフェイスにおいてＰＣＩｅメッセージが生成される。この実施例においては、ＮＩＣ１０６である。より、特定的には、ＰＣＩｅメッセージは、適用可能なアドレス情報を含んでいるＭＳＩベクトルとして構成されており、インタラプトのサービスに関するデータを含んでいるデータペイロードも同様である。アドレス情報は、ＭＳＩベクトルを特定するために使用され、次に、サービスのためにＩＲＱを好適なコアに対してマップするために使用される。

ＩＲＱのマッピングに加えて、ＡＰＩＣは、また、それぞれのプロセッサコアに対しするＩＲＱのキューイングと優先度付けのための機能を提供する。ＩＲＱはＡＰＩＣ１０４によって受け取られるので、それらは好適なプロセッサコアに対してマップされ、優先度ベースでキューされる。それぞれのコアが自身のキューを有し、かつ、他のプロセッサコアに対するＩＲＱに関して非同期的にＩＲＱに応答するようにである。

マルチコアプロセッサの顕著な利点が、プロセッサのパフォーマンスを増加させている。マルチコアプロセッサが導入される以前、ＣＰＵアーキテクチャは、パフォーマンスの壁に衝突していた。利用可能なファブリケーション（ｆａｂｒｉｃａｔｉｏｎ）技術を使用している利用可能な削減されたライン幅が、実質的な終点に到達してしまったからである。そして、より高いクロックレートを通じたパフォーマンス増加は、物理的な限界を表していた。信号スキュー（ｓｋｅｗ）の限界および温度の限界を超えているといったものである。マルチコアの使用によって、ライン幅の減少またはクロックレートの増加なしに、プロセッサのスループットを拡大することができた。しかしながら、典型的なＣＰＵワークロードの下にある場合にプロセッサ回路の多くの部分がアクティブであるので、マルチコアプロセッサは、単一コアの対応物よりも、多くの電力を消費し、多くの熱を発生する。結果として、マルチコアプロセッサは、しばしば、コアとＣＰＵダイの温度を削減するために、（同様な生産技術を使用している単一コアのプロセッサと比較して）より低いクロックレートにおいてオペレーションされている。

マルチコアの態様は、また、一つまたはそれ以上のコアを節電または「アイドル（”ｉｄｌｅ”）」状態に置くことによって電力を削減する機会を表している。典型的に、マルチコアＣＰＵは、それぞれのコアの消費電力管理を有効化するための消費電力管理ロジックを含んでいる。オペレーションモードの積極性に依存して、コアは選択的に「保留（”ｐａｒｋ”）」され、また、そうでなければ、全体的なＣＰＵ消費電力を削減するために節電状態に置かれる（一方で、また、熱発生も削減し、かつ、ダイ温度も下げている）。

インテル製プロセッサは、マイクロプロセッサ、ＣＰＵパッケージ、および、システム全体に対する４つの消費電力管理状態をサポートしている。表１は、種々の消費電力管理状態の名前を、簡潔な説明と供に、提供している。

マイクロプロセッサパフォーマンス状態（Ｐ状態）は、ＣＰＵがアクティブな場合に、マイクロプロセッサが動作することができる周波数と電圧の既定のセットである。マイクロプロセッサは、マイクロプロセッサによってサポートされている種々のＰ状態を実施するために、動的周波数スケーリング（ＤＦＳ）と動的電圧スケーリング（ＤＶＳ）を使用する。ＤＦＳとＤＶＳは、現在の動作条件に基づいて、マイクロプロセッサコアの動作周波数と動作電圧を動的に変化させる技術である。マイクロプロセッサの現在のＰ状態は、オペレーティングシステムによって決定される。一つのＰ状態から別のＰ状態へ変化するのに要する時間は、比較的に短い。オペレーティングシステムは、Ｐ状態を動的に変化させる場合には、この時間を考慮に入れる。ＯＳは、マイクロプロセッサによる消費電力とマイクロプロセッサのパフォーマンスとの間のトレードオフを管理する。

Ｃ状態は、アイドル状態として定義される。何も役に立つものが実行されていない場合には、エネルギーを節約するために、マイクロプロセッサの種々の部分が電源オフされる。Ｃ状態には、３つの分類がある。スレッド（論理的）Ｃ状態、マイクロプロセッサコアＣ状態、および、マイクロプロセッサパッケージＣ状態である。Ｃ状態の３つ全ての分類のうち、いくつかの態様は類似している。それらは全て、プロセッサスレッド、プロセッサコア、または、プロセッサパッケージのアイドル状態のいくつかの形式を表しているからである。しかしながら、Ｃ状態は、また、実質的なやり方において相違する。

スレッド（論理的）Ｃ状態は、スレッドレベルにおいて、マイクロプロセッサの現在のＣ状態のオペレーティングシステムの見解を表している。アプリケーションがプロセッサコアのＣ状態をリクエストするとき、アプリケーションは、「論理的コア（”ｌｏｇｉｃａｌ ｃｏｒｅ”）」のＣ状態を受け取る。論理的コアとは、アプリケーションの個々のスレッドがコアであると理解するものである。スレッドは、特定のコアの完全なオーナーシップを有すると理解するからである。実施例として、物理的コアごとに２つの論理的コアを採用しているＣＰＵ（ハイパースレッドをサポートしているインテル製ＣＰＵといったもの）に対して、論理的コア０（コア０上で実行されているスレッド０）は、所定のアイドル状態にあってよく、一方で、論理的コア１（コア０上のスレッド１）は、別のアイドル状態にあってよい。オペレーティングシステムは、所与のスレッドに対して、あらゆるＣ状態をリクエストすることができる。

コアＣ状態は、ハードウェア特有のＣ状態である。一つの実施例の下では、ＣＰＵパッケージの中に存在しているマルチコアＣＰＵのあらゆるコアは、特定のＣ状態に居ることができる。従って、全てのコアが、同一のＣ状態に居ることはリクエストされない。コアＣ状態は、コアのアイドル状態ごとに相互に排他的なものである。

パッケージＣ状態は、ＣＰＵパッケージの中の全てのコアに適用するアイドル状態である。ＣＰＵのパッケージＣ状態は、個々のコアＣ状態に関連する。ＣＰＵは、全てのコアが同一のコアＣ状態に入る準備ができている場合にだけ、ＣＰＵは低消費電力パッケージＣ状態に入ることができる。従って、全てのコアが同一のより低い消費電力コアＣ状態に入る準備ができている場合に、パッケージは、同等なより低消費電力のパッケージＣ状態の中に安全に移行することができる。

一つの実施例においては、４つのＣ状態（アイドル状態）があり、アイドル状態Ｃ０、アイドル状態Ｃ１、アイドル状態Ｃ３、および、アイドル状態Ｃ６を含んでいる。Ｃ状態が高いだけ、アイドルのレベルがより高く、かつ、消費電力削減もより大きい。アイドル状態Ｃ０から開始するが、コアに対する通常のアクティブオペレーションに対応するものである。例えば、アイドル状態Ｃ６に居る間、コアのＰＬＬ（フェーズロックループ）は電源オフされ、コアのキャッシュはフラッシュされ、コア状態がラストレベルキャッシュ（ＬＬＣ）に保管される。パワーゲートトランジスタは、およそゼロワット（Ｗａｔｔ）まで特定のコアに対して消費電力を削減するようにアクティブ化される。アイドル状態Ｃ６に居るコアは、アクティブ化されていないコアであると考えられる。アイドル状態Ｃ６に居るコアのウェークアップタイムが最も長い。ウェークアップイベントに応じて、コア状態がＬＬＣから回復され、コアＰＬＬが再びロックされ、パワーゲートが非アクティブ化され、そして、コアクロックが再び電源オンされる。

Ｃ６は最も深いＣ状態なので、この状態へ又はこの状態からの以降に対するエネルギーコストは最も高い。深いＣ状態に頻繁に出たり入ったりすることは、正味のエネルギー損失を結果として生じ得る。これを防ぐために、いくつかの実施例は、インテリジェントなヒューリスティクス（ｈｅｕｒｉｓｔｉｃｓ）を使用する自動降格機能を含んでおり、アイドル期間の節約が、深いＣ状態への移行および次にＣ０へ戻る移行のエネルギーコストに見合うのがいつかを判断する。もし、Ｃ６への移行が十分に見合わなければ、消費電力管理ロジックは、ＯＳのＣ状態リクエストをＣ３に格下げする。

現行のアプローチの下で、ＯＳは、オペレーティングシステム指向コンフィグレーション及び消費電力管理（ＯＳＰＭ）を使用してＣＰＵに対する消費電力管理機能とインターフェイスすることができる。ＯＳＰＭは、ＡＣＰＩを実施するシステムを説明しており、従って、システムＢＩＯＳからデバイス管理を取り外して、オペレーティングシステムのコントロールの下に置いている。これにより、ＯＳは、マルチコアプロセッサにおけるコアのＣ状態を（大幅に）コントロールすることができる。さらに、ＯＳが、実行に渡りスレッドからコア（ｔｈｒｅａｄ−ｔｏ−ｃｏｒｅ）の割り当てのコントロールを有しているので、ＯＳは、実行スレッドを、より大きな消費電力節約のために、より少ないコア上に結合する能力を有している。

上記に説明したように、Ｃ状態、特にアイドル状態Ｃ−３およびＣ−６、からコアを目覚めさせることは、著しいエネルギ消費を結果として生じる。コアを目覚めさせる一つのオペレーションは、ＩＲＱを扱うことである。結果として、ＩＲＱをサービスするためにコアが使用されウェイク場合には、低アイドル状態であることはできず、従って、ＩＲＱを断続的にサービスしているだけの場合ですら、より多くの電力を消費する。

ここにおいて開示される実施例に従えば、この問題は、新規なコンポーネントとデータ構造の使用を通じて取り扱われる。インタラプトベクトルをアイドルコア（または、アイドル状態に入りそうな対象）から離れて再マッピングすることによって動的に再コンフィグレーションできるようにするものであり、それにより、ＩＲＱをサービスさせることからアイドルコアを防ぎ、インタラプトすることなく、より深いアイドル状態に留まることができるようにしている。このことは、結果として、著しい消費電力節減のポテンシャルを生じている。

一つの実施例において、インタラプトベクトルの再マッピングは、ＩＲＱバランサ１３０の使用を介して有効化される。システムのオペレーションの最中に、ＩＲＱバランサは、ＯＳドライバと共同して、ＯＳとＡＰＩＣ１０４との間のブリッジとして動作し、ファイルまたはＯＳが利用可能な他のデータ構造における対応するデータを通じて、ベクトルマップ１２８に対する変更を、ＯＳ（または、別のソフトウェアエンティティ）が有効化できるようにしている。ＩＲＱバランサにおけるロジックも、また、ＩＲＱバランスをサポートするために実施される。効果的な消費電力管理をサポートするために、インタラプトベクトルのインテリジェントな再マッピングも同様に実施される。

図２は、リナックス（登録商標）（Ｌｉｎｕｘ（登録商標））オペレーティングシステムを採用している動的なインタラプト再コンフィグレーションの典型的な実施を伴う使用のために構成された、選択されたコンポーネントを説明するブロックダイヤグラムである。ダイヤグラムは、ＯＳネットワークスタック２００の選択されたコンポーネントを示しており、ソケット、レイヤ４およびレイヤ３（Ｌ４／Ｌ３）、レイヤ２（Ｌ２）のフレーミング（ｆｒａｍｉｎｇ）およびフィルタリングを含むコアネットワーキングレイヤ、および、ベースドライバ２０２を含んでいる。当業者によって理解されるように、ベースドライバ２０２は、ＯＳスタックと根柢の物理的ネットワークハードウェアとの間の抽象化インターフェイスとして使用されるＯＳドライバを含んでおり、この実施例においてはＮＩＣ１０６に対応している。ダイヤグラムの右側は、スタック２０４であり、擬似ファイルシステム２０６、ＩＲＱ記述子２０６、および、ＡＰＩＣ１０４を含んでいる。ダイヤグラムは、また、ＯＳのユーザ空間において動作しているＩＲＱバランサ１３０も含んでいる。

図３は、一つの実施例に従って、ＩＲＱバランサ１３０の態様を実施するためのロジックおよびオペレーションを説明するフローチャート３００である。フローチャートの最上部は、ＩＲＱバランサ開始／終了ブロック３０２である。開始すると、プロセッサコアのインタラプトワークロードが、既定の又はブロック３０４において計算された閾値に対してモニタされ、いつワークロード閾値を通過したかが判断される。コアのワークロードのための種々のデータは、ＯＳ及び/又はＣＰＵ機能によって典型的には維持される。例えば、現代のオペレーティングシステムは、典型的にはコアの利用率を示す統計値を保持している。それぞれのコアに対して割り当てられたプロセス（つまり、実行スレッド）の数も同様に保持している。加えて、ＰＣＵを採用しているＣＰＵは、コアの利用率に関する無数の統計値を維持しており、ＯＳを含む他のシステムエンティティにアクセス可能である。

一つの実施例において、閾値はインタラプトの頻度に基づいている。ＩＯ（入力／出力）インタラプトの頻度といったものである。この情報は、ＯＳまたはＣＰＵコンポーネントによって直ちにモニタされ得る。任意的に、インタラプトに対する応答に関するコアのワークロードは、インタラプトワークロード閾値として使用されてよく、または、インタラプト頻度とインタラプトコアワークロードの重み付けされた組み合わせが使用されてよい。他の実施例において、コア利用率の情報は、単独又はインタラプト頻度データと一緒のいずれかで使用され、いつワークロード閾値を通過したかを判断する。例えば、ここにおいて開示される消費電力管理技術の態様は、コアがより深いＣ状態に入れるようにするためのＩＲＱからコア（ＩＲＱ−ｔｏ−ｃｏｒｅ）のマッピングを再コンフィグレーションすることを含んでいるので、顕著なレベルで現在使用されているコアにとってそうすることはほとんど意味をなさないであろう。他のシステムロジック（ＰＣＵによって採用といったもの）は、マップされたインタラプトベクトルの数にかかわらず、より深いＣ状態へ置くことから、コアを防いでいる。例えば、第１のコアは、ＩＯに関係ない（従って、ＩＯインタラプトに対応するものでない）まさに計算集約的なアプリケーション、および、頻繁でないＩＯインタラプトを伴う別のバックグラウンドサービスが実行されていてよい。一方で、第２のコアは、著しい量のネットワークトラフィックおよび関連するＩＯインタラプトを伴うウェブサービスをホストしてよい。このインスタンスにおいては、バックグラウンドサービスのために、ＩＲＱを第１のコアから第２のコアへ再マッピングすることに利点はない。第１のコアの利用率レベルが、より深いＣ状態に入ることからコアを防いでいるからである。

インタラプトワークロード閾値を通過したとき、ロジックは判断ブロック３０６に進み、閾値がワークロード増加又はワークロード減少のいずれに対応するかを判断する。ワークロード減少である場合、ブロック３０８において、ＣＰＵのＩＯ構成を複数のコアの中に展開するか否かについて判断が行われる。もし、そうであれば、コアに対するＩＯインタラプトを一つまたはそれ以上の他のコアに対して再マップする機会が存在する。そのことにより、次に、コアはより深いアイドル状態に入ることができる。従って、ブロック３１０において、インタラプトは、適用可能なＭＳＩベクトルを再マッピングすることによって、より少ない数のコア上に「納められる（”ｃｏｌｌａｐｓｅｄ”）」。そして、コア「保留（”ｐａｒｋｉｎｇ”）」プロセスが開始される。コア保留は、コアがより深いアイドル状態（典型的にはＣ−３またはＣ−６）の中に置かれていることを示すために使用される一般的な用語である。インタラプトが現在は展開されていない場合（少なくともある程度で、ＩＲＱからコアへのマッピングが既に納められていることを意味している）、ロジックはブロック３１２に進む。ここにおいて、納められたインタラプトモデルが一つまたはそれ以上のコアを保留するのに十分であるか否かの検証が行われる。

判断ブロック３０６に戻ると、プロセッサ利用率及び/又はＩＯインタラプトアクティビティが閾値を上方に向かって通過したという状況に対応して、インタラプトワークロードが増加する。この場合、インタラプトを複数のコアの中で展開する、または、そうでなければ分散することが有利でる。従って、ブロック３１４において、現在のＩＲＱからコアへのマッピングを展開するか否かの判断がなされる。インタラプトが既に展開されている場合は、ブロック３１６において、より最適な展開コンフィグレーションが利用可能かであるかを判断するための検査が行われ、もし、そうであれば、ＩＲＱコアのマッピングは、より最適な展開コンフィグレーションのために再コンフィグレーションされる。判断ブロック３０６に戻ると、インタラプトが現在は展開されていない場合、ロジックはブロック３１８に進み、ワークロードを正規化するために、ＩＲＱが適用可能なコアに渡り展開される。

一つの実施例においては、それぞれのコアに割り当てられたＩＯインタラプトが（少なくともある程度は）バランスされているように、コアロードバランシング（ｂａｌａｎｃｉｎｇ）考慮がなされる。つまり、ロードバランシングを使用してインタラプトを展開することは、インタラプトを「ファンアウト（”ｆａｎ ｏｕｔ”）」するものとして参照される。一方で、インタラプトをより少ないコアにまとめることは、インタラプトを「ファンイン（”ｆａｎ ｉｎ”）」するものとして参照される。このことは、図４ａ−４ｃから図９ａ−９ｃにおいて示されるような、図解を通じてより容易に理解される。

より詳細には、図４ａ−４ｃから図９ａ−９ｃでは、ＭＳＩベクトルを図示するために矢印が使用されており、それぞれの矢印のラインタイプがＭＳＩベクトルに関するインタラプト頻度を表している。図示されているように、実線は安定したインタラプト頻度に対応しており、一方、破線は断続的なインタラプト頻度に対応し、かつ、点線は希発なインタラプト頻度に対応している。矢印を通るクネクネは、ＭＳＩベクトルがもはや存在しないことを意味している（対応するＭＳＩベクトルが配分された対応するアプリケーションまたはサービスが、停止されたか、または、そうでなければ、完了したことを意味している）。

図４ａ−４ｃは、インタラプトを納めること及びシーケンスを再コンフィグレーションの実施例を説明する。図４ａは、オリジナルのコンフィグレーションを示しており、その下では３つのＭＳＩベクトル１２６がコア１−４のそれぞれに対してマップされている。それぞれのＭＳＩベクトルの頻度は、ＭＳＩベクトル１２６−１と１２６−２を除いて安定状態であり、ＭＳＩベクトル１２６−１と１２６−２は希発である。一つの実施例において、ワークロード閾値は、それぞれのコアに対する結合されたインタラプトの頻度に基づいている。頻度は、例えば、移動平均または類似の技法を使用して、上記に説明した方法の一つによって判断され得る。あまりに頻繁に再コンフィグレーションを実行することは避けるのが望ましい。そのため、いくつかのヒステリシス（ｈｙｓｔｅｒｅｓｉｓ）がインタラプト頻度の計算の中に取込まれている。

典型的な用途を仮定する。頻度の閾値が１．１であり、安定した頻度のＭＳＩが１の値を有し、断続的な頻度が安定した頻度の半分（値＝０．５）であり、一方、希発の頻度が安定した頻度の４分の１（値＝０．２５）であるとする。図４ｂでは、閾値イベントが表されており、結合されたインタラプトの頻度は１．１以下である。図示されているように、ＭＳＩベクトル１２６−３は停止され、値が０．５であるＭＳＩベクトル１２６−１と１２６−２の結合されたＭＳＩベクトルインタラプト頻度が残っている。従って、閾値条件に応じて、ベクトル納めと再コンフィグレーションのプロセスが開始され、初期的にコア１にマップされたＭＳＩベクトルが他のコアに対して再マップされる。図示された実施例において、ＭＳＩベクトル１２６−１はコア２に再マップされ、ＭＳＩベクトル１２６−２はコア３に再マップされる。ＭＳＩベクトルがコア１から再マップされると、コア１が保留の候補であるか否かを判断するためのオペレーションが実行され、そうであれば、アイドルＣ状態をより高い値（例えば、Ｃ−３またはＣ−６）に変更することによって、コアが保留される。一般的に、コアが保留されるか否か、および、どのＣ状態が適用されるかの判断は、ＯＳによって、ＰＣＵによって、または、２つの組み合わせによって決定されてよい。

図５ａ−５ｃには、インタラプトを納めること及びシーケンスを再コンフィグレーションの第２の実施例が示されている。図５ａに図示されたオリジナルのコンフィグレーションの下で、４つのコアそれぞれは、３つのＭＳＩベクトルを受け取る。ここにおいて、ＭＳＩベクトル１２６−４を除くすべてのベクトルは安定状態である。上記のように、閾値は１．１に設定されている。図５ｂでは、閾値イベントが表されており、ＭＳＩベクトル１２６−５と１２６−５は停止されている。従って、残っているＭＳＩベクトルのコア１に対する頻度は１．１以下であり、図５ｃに示される結果を用いて、ＭＳＩベクトルの納めと再コンフィグレーションのプロセスを設定する。図５ｃは、また、ロードバランシング状況を示しており、再マップされたＭＳＩベクトル１２６−４は、コア３に対して再度向けられる。コア３は以前にインタラプトワークロードが最少であったものである。

ＭＳＩベクトルの納めに加えて、ＭＳＩベクトルを正規化または「ファンアウト」するための再コンフィグレーションのオペレーションが実行され得る。利用可能なアクティブなコアの数が増加するときに（例えば、アイドルのコアがアクティブ状態に戻ったとき）、ＭＳＩベクトルをサービスするコアの数を増加するようにである。このプロセスの２つの実施例が、図６ａ−６ｃと図７ａ−７ｃにおいて示されている。

図６ａにおけるオリジナルコンフィグレーションの下で、コア１は保留されており、一方、コア２−４は３つのＭＳＩベクトルを受け取っている。この実施例における閾値は３であり、ワークロード納めの閾値とワークロード拡張の閾値は一致する必要がないことに留意する。そして、上記に説明したように、閾値は、進行中のオペレーションの最中に動的に調整され得る（例えば、リアルタイムのワークロード測定及び/又は他の考慮に基づくものである）。図６ｂは、また、コア１が保留状態からアクティブ状態へと移行することを示している。コーディネイトされた消費電力管理アプローチに従って、ＭＳＩベクトルは、アクティブなコアに対してだけマップされる（初期的な割り当て又は再コンフィグレーションのいずれかによるものである）。図６ｂに示されたコンフィグレーションの下では、また、新たなＭＳＩベクトル１２６−７と１２６−８がコア２とコア３に対して割り当てられ、一方、コア１は保留されている。コア１がアクティブ状態に再び入ったことを検出すると、コアワークロード閾値が再び開始され、コア２とコア３のそれぞれに対するインタラプト頻度が閾値の３を超えているとの判断に至る。結果として、再コンフィグレーションのオペレーションが実行され、図６ｃに示された結果となる。この実施例においては、ＭＳＩベクトルのファンアウトが実行され、新たなＭＳＩベクトル１２６−７と１２６−８がコア１に対して再マップされる。このことは、また、ＭＳＩベクトルワークロードを再バランスしたものである。

図７ａ−７ｃに示した実施例の下では、初期のコンフィグレーションは、コア２−４のそれぞれに割り当てられた２つのＭＳＩベクトルを有しており、コア１が保留されている。図７ａに示すようにである。上記のように閾値は３である。図７ｂにおいて、コア４には３つの新たなＭＳＩベクトル１２６−９、１２６−１０、および、１２６−１１が割り当てられ、一方で、コア１は保留されている。その後、コア１は移行されてアクティブ状態に戻る。このことは、ワークロード閾値評価を再び開始する。コア１−３が追加のＭＳＩベクトルを受け取り、かつ、コア１には現在割り当てられたＭＳＩベクトルが無い間は、コア３がオーバーロードであることを示している。結果として、ファンアウトと再コンフィグレーションのオペレーションが実行され、図７ｃに示された結果となる。この実施例において、ＭＳＩベクトル１２６−９と１２６−１０はコア１に対して再マップされ、一方、ＭＳＩベクトル１２６−１１はコア２に対して再マップされる。上記のように、このことは、また、全てのアクティブなコアに渡るＭＳＩベクトルのワークロードの再バランシングをもたらす。

図８ａ−８ｃは、複数の再コンフィグレーションプロセスを示しており、４つから２つのコアへＭＳＩベクトルのマッピングを納めることを、結果として生じている。一方、図９ａ−９ｃは、一つのコアを使用して開始され、４つ全てのコアに渡り配分されたＭＳＩベクトルを伴って終了するファンアウトシーケンスを示している。図８ｂと８ｃは、コア１が保留されている下での第１の再コンフィグレーションのベクトルコンフィグレーション、および、コア１とコア２が保留されている下での第２の再コンフィグレーションのベクトルコンフィグレーションの後でのベクトルコンフィグレーションをそれぞれ示している。上記のように、ファンアウト又は「正規化」シーケンスの最中、一つまたはそれ以上のコアが保留されている間に追加のＭＳＩベクトルが受け取られる。そして、追加のコードが利用可能になると、再バランシングが実行される。複数のアクティブなコアを使用している所与の進行中のコンフィグレーションの下で、新たなＭＳＩベクトルが、ロードバランスを維持するやり方で、既存のアクティブなコアに追加されることにも、留意すべきである。

本発明の実施例は、種々のシステムエンティティと協調して、インタラプトベクトルの動的な再コンフィグレーションを通じて効果的な消費電力管理を促進している。進行中のオペレーションの最中に、インタラプトベクトルは、マルチコアプロセッサの中の種々のプロセスに対してマップされ、プロセッサコア上のワークロードがモニタされる。所与のプロセッサに対するインタラプトワークロードが閾値以下に低下したことを検出した場合には、そのコアはより深いアイドル状態に置く候補であり、このように、著しく電力を節約している。このことを促進するために、インタラプトベクトルは、プロセッサコア（ワークロード閾値イベントが検出されたもの）に現在マップされているインタラプトベクトルを少なくとも一つの他のプロセッサコアに再マッピングすることによって、インタラプトベクトルが動的に再コンフィグレーションされる。再コンフィグレーションの後では、プロセッサコアにマップされたインタラプトベクトルが存在しないようにである。このように、プロセッサコアは、より深いアイドル状態の中に置かれ、インタラプトリクエストをサービスするために目覚める必要なく、その状態に留まることができる。類似のオペレーションを追加のプロセッサコアに対して適用することができ、反復プロセッサを介してといったように、インタラプトベクトルをより少ないプロセッサコア上に納めることをもたらし、より大きな節電に至る。

インタラプトベクトルをより少ないプロセッサコア上に納めることに加えて、正規化または「ファンアウト」オペレーティングシステムが、プロセッサコアがアクティブ状態に戻る際に、使用され得る。例えば、アクティブ状態に戻るコアに応じて、ワークロード閾値検出オペレーションが実行され、プロセッサコアに対するワークロードが超過しているか否かを判断する。例えば、ワークロード閾値は、超過したインタラプト頻度に基づいてよい。この閾値イベントの検出に応じて、このコアからのインタラプトが、アクティブ状態に戻っているコアに対して再マップされてよい。同時に、この再コンフィグレーションは、コアに対するインタラプトベクトルの割り当ての再バランシングをもたらす。

ここにおいて開示された実施例の態様は、ＣＰＵまたはＣＰＵ上で実行されている仮想マシン上でのインストラクションの実行を通じて、もたらされ得る。従って、本発明の実施例は、プロセッサコアのいくつかのフォーム上で実行され、または、そうでなければ、マシンで読取り可能な媒体上又は中で実施もしくは実行されるインストラクションとして、または、インストラクションをサポートするために、使用され得る。マシンで読取り可能な媒体は、マシン（例えば、コンピュータ）によって読取り可能な形式において情報を保管し、または、伝送するためのあらゆるメカニズムを含んでいる。例えば、マシンで読取り可能な媒体は、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記録媒体、光記録媒体、および、フラッシュデバイス、等を含んでいる。

要約において記載されているものを含み、図示された本発明の実施例に係る上記の説明は、網羅的であること、または、本発明を開示されたまさにその形式に限定することを意図するものではない。本発明の所定の実施例、および例示、が説明目的のためにここにおいて開示されている一方で、当業者であれば理解するように、本発明の範囲内で種々の均等な変形が可能である。

こうした変形は、上記の詳細な説明に照らして本発明に対して成し得るものである。添付の特許請求の範囲において使用される用語は、本発明を明細書及び図面に開示された所定の実施例に限定するものと理解されるべきではない。むしろ、本発明の範囲は、添付の特許請求の範囲によって全体的に決定されるべきものであり、請求項解釈の確立された方策に従って解釈されるべきものである。

Claims (22)

1. 複数のプロセッサコアを有するマルチコアプロセッサを使用しているコンピュータシステムにおいてインタラプトをコンフィグレーションするための方法であって：
   前記複数のプロセッサコアに対してインタラプトベクトルをマップするステップと、
   第１のプロセッサコアのインタラプトワークロードが、閾値以下に低下したことを検出するステップと、
   前記の検出に応じて、
   前記第１のプロセッサコアに対してマップされていた前記インタラプトベクトルのそれぞれを、前記第１のプロセッサコア以外のプロセッサコアに対して再マップすされるように、再コンフィグレーションするステップと、
   を含む、方法。
2. 前記インタラプトベクトルの再コンフィグレーションは、少なくとも部分的に、オペレーティングシステムの使用を通じて行われる、
   請求項１に記載の方法。
3. 前記オペレーティングシステムは、リナックス（Ｌｉｎｕｘ）オペレーティングシステムである、
   請求項２に記載の方法。
4. 前記オペレーティングシステムは、前記マルチコアプロセッサ上のインタラプトコントローラとインタラクションするデバイスドライバの使用を通じて、インタラプトベクトルの再コンフィグレーションを行う、
   請求項２に記載の方法。
5. 前記デバイスドライバは、前記オペレーティングシステムによってアクセスされた、再コンフィグレーションファイルまたはデータ構造のうち一つにおけるデータを読み出す、
   請求項４に記載の方法。
6. 前記方法は、さらに、
   前記複数のプロセッサコアに対する、ロードバランシングのインタラプトベクトル割り当て、を含む、
   請求項１乃至５いずれか一項に記載の方法。
7. 前記方法は、さらに、
   第２のプロセッサコアのインタラプトワークロードが閾値以下に低下したことを検出するステップと、
   前記の検出に応じて、
   前記第２のプロセッサに対してマップされていた前記インタラプトベクトルのそれぞれを、前記第１のプロセッサコアおよび前記第２のプロセッサコア以外のプロセッサコアに対して再マップされるように、再コンフィグレーションするステップと、
   を含む、
   請求項１乃至６いずれか一項に記載の方法。
8. 前記第２のプロセッサコアは、前記第２のプロセッサコアの前記ワークロードが前記閾値以下に低下する以前に、第１のオペレーション状態において動作しており、
   前記方法は、さらに、
   前記第２のプロセッサコアに対してマップされた前記インタラプトベクトルが再コンフィグレーションされた後で、前記第２のプロセッサコアを、前記第１のオペレーション状態より深いアイドル状態の中に置くステップと、を含む、
   請求項７に記載の方法。
9. 前記インタラプトワークロードの閾値は、インタラプト頻度のレベルに基づいている、
   請求項１乃至８いずれか一項に記載の方法。
10. 前記第１のプロセッサコアは、前記第１のプロセッサコアの前記インタラプトワークロードが前記閾値以下に低下する以前に、第１のアイドル状態において動作しており、
    前記方法は、さらに、
    前記第１のプロセッサに対してマップされた前記インタラプトベクトルが再コンフィグレーションされた後で、前記第１のプロセッサコアを、より深いアイドル状態の中に置くステップと、を含む、
    請求項１乃至９いずれか一項に記載の方法。
11. 前記方法は、さらに、
    前記第１のプロセッサコアが、前記第１のアイドル上に戻ったことを検出するステップと、
    第３のプロセッサコア上のインタラプトワークロードが、閾値を越えたことを検出するステップと、を含み、
    前記の検出に応じて、
    少なくとも一つのインタラプトベクトルを、前記第３のプロセッサコアから前記第１のプロセッサコアへ再マッピングする、
    請求項１０に記載の方法。
12. 前記方法は、さらに、
    インタラプトベクトルのロードバランシングを行うように、前記インタラプトベクトルの一部を他のプロセッサコアに対して選択的に再マッピングすることによってインタラプトベクトルを再コンフィグレーションするステップと、を含む、
    請求項１１に記載の方法。
13. 前記方法は、さらに、
    少なくとも一つのインタラプトワークロードの閾値を動的に調整するステップと、を含む、
    請求項１１に記載の方法。
14. 前記インタラプトワークロードの閾値は、インタラプト頻度に基づいている、
    請求項１１に記載の方法。
15. 前記インタラプトベクトルは、メッセージシグナルインタラプト（ＭＳＩ）ベクトルを含む、
    請求項１乃至１４いずれか一項に記載の方法。
16. 前記インタラプトベクトルは、ＩＯデバイスにによって生成される入力／出力（ＩＯ）インタラプトベクトルを含む、
    請求項１乃至１５いずれか一項に記載の方法。
17. マルチコアプロセッサを有し、かつ、請求項１乃至１６いずれか一項に記載の方法を実行するように構成されている、
    コンピュータシステム。
18. 前記マルチコアプロセッサは、入ってくるインタラプトベクトルを対応するプロセッサコアに向けるために使用されるインタラプトベクトルのマッピングデータを保管するように構成されているアドバンストプログラマブルインタラプトコントローラ（ＡＰＩＣ）、を含む、
    請求項１７に記載のコンピュータシステム。
19. 前記マルチコアプロセッサは、さらに、
    前記複数のプロセッサコアそれぞれのオペレーション状態の変更を有効化するために使用される電力制御ユニット（ＰＣＵ）、を含む、
    請求項１７に記載のコンピュータシステム。
20. 前記コンピュータシステムは、さらに、入ってくるネットワーク通信に応じて、インタラプトベクトルを生成するように構成されたネットワークインターフェイスコントローラ（ＮＩＣ）、を含む、
    請求項１７に記載のコンピュータシステム。
21. 前記ＮＩＣは、ＰＣＩｅデバイスを含む、
    請求項２０に記載のコンピュータシステム。
22. コンピュータデバイス上で実行されると、前記コンピュータデバイスに請求項１乃至１６いずれか一項に記載の方法を実施させる、複数のインストラクションを含む、少なくとも一つのマシンで読み出し可能な媒体。

Images