(57)【要約】      （修正有）【課題】コンピュータシステム内の複数のリソースの管理によりシステムのエネルギー消費を低減する方法を提供する。【解決手段】複数のアプリケーションステート及びマルチスレッディングシステム内の複数のスレッドステートをモニタし、システム内の複数のリソース調整を実施する。複数のソフトウェアアプリケーションにより使用される仮データ用のデータバッファをモニタすることで、複数のリソースは、複数のバッファレベルに依存して増やされ、または減らされる。複数のリソースの複数の調整では、プロセッサの電圧および周波数を変更する。準備ができたスレッドは、複数のスレッドの同時実行の機会を増やすために遅らされる。複数のスレッドの同時実行は、システムアイドル時間のための機会を増やすことに役立ち、したがって、エネルギー消費は、減らされる。【選択図】図４Ａ
2011018352.tif 000002
【特許請求の範囲】
【請求項１】
システム内で実行中のアプリケーションのステートをモニタする段階であって、前記アプリケーションに関連した１つ以上のバッファをモニタする段階を有する段階、
前記システム内の１つ以上のスレッドのディスパッチを制御する段階であって、前記システム内の少なくとも１つのスレッドは、前記アプリケーションに関連する段階、および
前記システム内の前記アプリケーションの前記ステートおよび前記１つ以上のスレッドの前記ステートに少なくとも基づいて前記システム内の複数のリソースを管理する段階
を備える方法。
【請求項２】
スレッドは、１つ以上のアクティビティを有し、
前記システム内の前記１つ以上のスレッドの前記ディスパッチを制御する段階は、前記１つ以上のアクティビティの実行準備性を評価する段階を有する請求項１に記載の方法。
【請求項３】
前記システム内の前記１つ以上のスレッドの前記ディスパッチを制御する段階は、ディスパッチされる準備ができたアクティビティをディスパッチされることから遅らせる段階を有する請求項２に記載の方法。
【請求項４】
第一のアクティビティおよび第二のアクティビティの両方が、共にディスパッチされることができるように、前記第一のアクティビティは、前記第二のアクティビティの準備ができるのを待つために、ディスパッチされることから遅らされ、前記第一のアクティビティおよび前記第二のアクティビティは、１つ以上のアプリケーションからである請求項３に記載の方法。
【請求項５】
前記システムのマシンステートをモニタする段階であって、
前記システム内の利用可能な複数のリソースを決定する段階、および
前記システム内の前記アプリケーションの前記ステートおよび前記１つ以上のスレッドの前記ステートに基づいて前記システム内の利用可能な前記複数のリソースを増やす段階または減らす段階
を有する段階をさらに備える請求項１に記載の方法。
【請求項６】
前記複数のリソースは、設定可能な複数のハードウェアコンポーネントを有する請求項５に記載の方法。
【請求項７】
前記設定可能なハードウェアコンポーネントは、前記システム内の１つ以上のプロセッサ、複数のハードウェアバッファ、メモリ、キャッシュ、算術論理ユニット（ＡＬＵ）、および複数のレジスタを有する請求項６に記載の方法。
【請求項８】
前記システム内の利用可能な前記複数のリソースを増やす段階または減らす段階は、前記システム内の少なくとも前記１つ以上のプロセッサに適用される前記複数の周波数を設定する段階を有する請求項７に記載の方法。
【請求項９】
前記システム内の利用可能な前記複数のリソースを増やす段階または減らす段階は、前記システム内の少なくとも前記１つ以上のプロセッサに適用される前記複数の電圧を設定する段階を有する請求項８に記載の方法。
【請求項１０】
前記システム内の前記複数のリソースを増やす段階または減らす段階は、前記システム内の回路の少なくとも一部を電源オンする段階または電源オフする段階を有する請求項７に記載の方法。
【請求項１１】
前記アプリケーションに関連した前記１つ以上のバッファをモニタする段階は、前記１つ以上のバッファの複数のバッファ充満レベルをモニタする段階を有する請求項１に記載の方法。
【請求項１２】
前記複数のバッファ充満レベルをモニタする段階は、前記アプリケーションに関連したそれぞれのバッファに対して、バッファレベルを所定の複数のバッファ充満レベルと比較する段階を有し、
前記所定の複数のバッファ充満レベルは、高レベルマークおよび低レベルマークを含む請求項１１に記載の方法。
【請求項１３】
比較する段階は、バッファオーバーフローおよびバッファアンダーフロー条件を判断することである請求項１２に記載の方法。
【請求項１４】
複数の実行可能命令を備え、
前記複数の命令がプロセッシングシステム内で実行された場合、前記プロセッシングシステムに、
システム内で実行中のアプリケーションのステートをモニタする段階であって、前記アプリケーションに関連した１つ以上のバッファの複数のバッファ充満レベルをモニタする段階を有する段階、
前記システム内の１つ以上のスレッドのディスパッチを制御する段階であって、前記システム内の少なくとも１つのスレッドは、前記アプリケーションに関連する段階、および
前記システム内の前記アプリケーションの前記ステートおよび前記１つ以上のスレッドの前記ステートに少なくとも基づいて前記システム内の複数のリソースを管理する段階
を備える方法を実行させるコンピュータ可読媒体。
【請求項１５】
前記システム内の前記１つ以上のスレッドの前記ディスパッチを制御する段階は、ディスパッチされる準備ができたスレッドをディスパッチされることから遅らせる段階を有する請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
前記システムのマシンステートをモニタする段階であって、
前記システム内の利用可能な複数のリソースを決定する段階、および
前記システム内の前記アプリケーションの前記ステートおよび前記１つ以上のスレッドの前記ステートに基づいて前記システム内の利用可能な前記複数のリソースを増やす段階または減らす段階
を有する段階をさらに備える請求項１４に記載のコンピュータ可読媒体。
【請求項１７】
前記複数のリソースは、設定可能な複数のハードウェアコンポーネントを有する請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
前記システム内の利用可能な前記複数のリソースを増やす段階または減らす段階は、前記システム内の少なくとも前記１つ以上のプロセッサに適用される前記複数の周波数および／または前記複数の電圧を設定する段階を有する請求項１６に記載のコンピュータ可読媒体。
【請求項１９】
前記複数のバッファ充満レベルをモニタする段階は、前記アプリケーションに関連したそれぞれのバッファに対して、バッファレベルを所定の複数のバッファ充満レベルと比較する段階を有し、
前記所定の複数のバッファ充満レベルは、高レベルマークおよび低レベルマークを含む請求項１４に記載のコンピュータ可読媒体。
【請求項２０】
システム内の実行中のアプリケーションにより使用される１つ以上のバッファの複数のバッファ充満レベルをモニタすることにより、および前記システム内の複数のスレッドのディスパッチを協調させることにより、前記システム内の複数のリソースを管理する段階を備える方法。
【請求項２１】
前記１つ以上のバッファの前記複数のバッファ充満レベルをモニタする段階は、バッファオーバーフロー条件またはアンダーフロー条件を判断するために前記１つ以上のバッファのそれぞれのバッファレベルをモニタする段階を有する請求項２０に記載の方法。
【請求項２２】
前記システム内の前記複数のスレッドの前記ディスパッチを協調させる段階は、複数のスレッドの実行の中のオーバーラップを増やすために実行される請求項２０に記載の方法。
【請求項２３】
前記複数のスレッドの実行内の前記オーバーラップを増やす段階は、スレッドをレディステートから待ち行列ステートに変更する段階を有する請求項２２に記載の方法。
【請求項２４】
前記スレッドは、両方のスレッドが共にディスパッチされることができるように、前記レディステートである他のスレッドが存在するまで、前記待ち行列ステートのままである請求項２３に記載の方法。
【請求項２５】
前記システム内の前記複数のスレッドの前記ディスパッチを協調させる段階は、複数のスレッドの依存性を決定する段階を有し、
前記アプリケーションの現在のスレッドと次のスレッドとの間に依存性があり、また、前記複数のバッファの全ての前記複数のバッファ充満レベルが潜在的なオーバーフロー条件を示す場合、前記システム内の前記複数のリソースは、増やされる請求項２０に記載の方法。
【請求項２６】
前記複数のバッファの全ての前記複数のバッファ充満レベルがクリティカル局面に達した場合、前記システム内の前記複数のリソースは、調整される請求項２０に記載の方法。
【請求項２７】
複数の実行可能命令を備え、
前記複数の命令がプロセッシングシステム内で実行された場合、前記プロセッシングシステムに、
システム内の実行中のアプリケーションにより使用される１つ以上のバッファの複数のバッファ充満レベルをモニタすることにより、および前記システム内の複数のスレッドのディスパッチを協調させることにより、前記システム内の複数のリソースを管理する段階を備える方法を実行させるコンピュータ可読媒体。
【請求項２８】
前記複数のバッファ充満レベルをモニタする段階は、バッファオーバーフロー条件またはアンダーフロー条件のためにモニタする段階、および相応して、前記バッファオーバーフロー条件またはアンダーフロー条件を避けるために前記システム内の前記複数のリソースを増やす段階または減らす段階を有する請求項２７に記載のコンピュータ可読媒体。
【請求項２９】
前記システム内の前記複数のスレッドの前記ディスパッチを協調させる段階は、実行オーバーラップを増やすために、スレッドをレディステートから待ち行列ステートに変更する段階および複数のスレッドをディスパッチする段階を有する請求項２７に記載のコンピュータ可読媒体。
【請求項３０】
システム内の１つ以上のスレッドの複数のステートをモニタする段階であって、前記１つ以上のスレッドをディスパッチするために準備性をモニタする段階を有する段階、および
前記システム内の前記１つ以上のスレッドの前記複数のステートに少なくとも基づいて前記システム内の複数のリソースを管理する段階であって、前記複数のリソースは、前記システム内の複数の設定可能ハードウェアコンポーネントを有する段階
を備える方法。
【請求項３１】
前記システム内の前記複数のリソースを管理する段階は、前記システム内の少なくとも１つ以上のプロセッサに適用される前記複数の周波数および／または複数の電圧を設定する段階を有する請求項３０に記載の方法。
【請求項３２】
前記システム内の前記複数のリソースを管理する段階は、前記システム内の回路の一部を電源オンする段階または電源オフする段階をさらに有する請求項３０に記載の方法。
【請求項３３】
前記システム内で実行中のアプリケーションのステートを管理する段階をさらに備え、
前記アプリケーションの前記ステートは、前記アプリケーションにより使用される１つ以上のバッファの複数のバッファ充満レベルを有し、
前記システム内の前記複数のリソースは、前記アプリケーションの前記ステートに基づいて増やされ、または減らされる請求項３０に記載の方法。
【請求項３４】
システム内で実行中のアプリケーションのステートをモニタする段階であって、前記アプリケーションに関連した１つ以上のバッファの複数のバッファ充満レベルをモニタする段階を有する段階、および
前記アプリケーションの前記ステートに基づいて前記システム内の複数のリソースを管理する段階
を備える方法。
【請求項３５】
前記システム内の１つ以上のスレッドの実行準備性を管理する段階をさらに備え、
前記複数のリソースを管理する段階は、前記アプリケーションに関連する少なくとも１つのスレッドの前記実行準備性にさらに基づく請求項３４に記載の方法。
【請求項３６】
前記実行準備性は、ディスパッチされる準備ができたステートおよびディスパッチされることから遅らせるステートを有する請求項３５に記載の方法。
【請求項３７】
前記システム内の前記１つ以上のスレッドの前記実行準備性を管理する段階は、スレッドをディスパッチされる準備ができたステートからディスパッチされることから遅らせるステートに置く段階を有する請求項３６に記載の方法。
【請求項３８】
前記１つ以上のバッファの前記複数のバッファ充満レベルをモニタする段階は、
潜在的なバッファアンダーフロー条件またはオーバーフロー条件を判断する段階、および
前記潜在的なバッファアンダーフロー条件またはオーバーフロー条件を避けるために前記システム内の利用可能な複数のリソースを変更するために前記システム内の１つ以上のコンポーネントを設定する段階
を有する請求項３７に記載の方法。
【請求項３９】
データおよび複数の命令を記憶するためのメモリと、
バス上で前記メモリに結合されたプロセッサであって、複数の命令を実行できるプロセッサと
を備え、
前記プロセッサは、
前記メモリからの複数の命令のシーケンスを受信するバスユニットと、
前記バスユニットに結合された実行ユニットであって、複数の命令の前記シーケンスを実行する実行ユニットと
を有し、
複数の命令の前記シーケンスは、前記実行ユニットに、
システム内で実行中のアプリケーションのステートをモニタする手順であって、前記アプリケーションに関連した１つ以上のバッファの複数のバッファ充満レベルをモニタすることを有する手順、
前記システム内の１つ以上のスレッドのディスパッチを制御する手順であって、前記システム内の少なくとも１つのスレッドは、前記アプリケーションに関連する手順、および
前記システム内の前記アプリケーションの前記ステートおよび前記１つ以上のスレッドの前記ステートに少なくとも基づいて前記システム内の複数のリソースを管理する手順
を実行させるシステム。
【請求項４０】
前記システム内の前記１つ以上のスレッドの前記ディスパッチを制御する手順は、ディスパッチされる準備ができたスレッドをディスパッチされることから遅らせる手順を有する請求項３９に記載のシステム。
【請求項４１】
複数の命令をさらに備え、
前記複数の命令は、前記実行ユニットに、
前記システムのマシンステートをモニタする手順であって、
前記システム内の利用可能な複数のリソースを決定する手順、および
前記システム内の前記アプリケーションの前記ステートおよび前記１つ以上のスレッドの前記ステートに基づいて前記システム内の利用可能な前記複数のリソースを増やす手順または減らす手順
を有する手順を実行させる請求項３９に記載のシステム。
【請求項４２】
前記複数のリソースは、複数の設定可能ハードウェアコンポーネントを有する請求項４１に記載のシステム。
【請求項４３】
前記システム内の利用可能な前記複数のリソースを増やす手順または減らす手順は、前記システム内の少なくとも前記１つ以上のプロセッサに適用される前記複数の周波数および前記複数の電圧を設定する手順を有する請求項４１に記載のシステム。
【請求項４４】
マルチスレッディングプロセッサ、および
前記マルチスレッディングプロセッサに結合されたリソースマネージャであって、
システム内で実行中のアプリケーションの複数のステートをモニタし、前記アプリケーションの前記複数のステートは、前記アプリケーションにより使用される１つ以上のバッファの複数のバッファ充満レベルを有し、
実行準備性のために前記システム内の１つ以上のスレッドの複数のステートをさらにモニタし、前記システム内の前記アプリケーションの前記複数のステートおよび／または前記１つ以上のスレッドの前記複数のステートに依存して前記システム内の利用可能な複数のリソースを増やし、または減らすリソースマネージャ
を備えるシステム。
【請求項４５】
前記リソースマネージャは、他のスレッドの実行と続いて起こるスレッド実行とのオーバーラップを増やすために、スレッドの前記実行準備性をレディステートから待ち行列ステートに変更する請求項４４に記載のシステム。
【請求項４６】
前記リソースマネージャは、スレッド実行がない場合、続いて起こるシステムアイドル時間を増やすために、スレッドの前記実行準備性をレディステートから待ち行列ステートに変更する請求項４５に記載のシステム。
【請求項４７】
前記リソースマネージャは、前記１つ以上のバッファで生じるバッファアンダーフロー条件またはオーバーフロー条件を避けるために前記システム内の利用可能な前記複数のリソースを増やし、または減らす請求項４６に記載のシステム。
【請求項４８】
システム内で実行中のアプリケーションの複数のステートをモニタするロジックであって、前記アプリケーションの前記複数のステートは、前記アプリケーションにより使用される１つ以上のバッファの複数のバッファ充満レベルを有するロジック、
実行準備性のために前記システム内の１つ以上のスレッドの複数のステートをモニタするロジック、および
前記システム内の前記アプリケーションの前記ステートおよび／または前記１つ以上のスレッドの前記複数のスレッドに基づいて前記システム内の利用可能な複数のリソースを調整するロジック
を備える装置。
【請求項４９】
他の実行中またはディスパッチされる準備ができたスレッドがないと判断される場合、スレッドの前記実行準備性をレディステートから待ち行列ステートに変換するロジックをさらに備える請求項４８に記載の装置。
【請求項５０】
前記システム内の前記利用可能な複数のリソースを調整するロジックは、１つ以上のバッファの複数のバッファ充満レベルがクリティカル局面にあるかどうかを判断するロジックを含む請求項４８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンピュータシステムの領域に関し、より詳細には、複数のコンピュータシステムの電力消費を低減する方法および装置に関する。
【背景技術】
【０００２】
マルチスレッディングは、並列に処理されるように、複数の命令を、複数の実行の複数のストリーム（または複数のスレッド）に分割する技術である。
【０００３】
図１は、マルチスレッディングをサポートするために使用されることができる先行技術システムの一例を説明するブロック図である。システム１００は、２つの物理プロセッサ１０５および１１０を備え、複数のマルチスレッドソフトウェアを実行するために使用される。複数の物理プロセッサ１０５および１１０のそれぞれは、複数のリソースの同様の一式（例えば、複数のアーキテクチャステート、複数の実行レジスタ、複数のキャッシュなど）を有する。２つの物理プロセッサは、共通システムバス１１５および共通メインメモリ１２０を共有する。
【０００４】
一般的に、並列度を増やすために、システム１００は、スレッドがディスパッチされる準備ができた場合はいつでもスレッドをディスパッチするスケジューリング技術を使用する。
【図面の簡単な説明】
【０００５】
下記の複数の図面は、本発明のさまざまな実施形態を、説明の目的としてのみ開示し、本発明の範囲を制限するようには意図されない。
【０００６】
【図１Ａ】マルチスレッディングをサポートするために使用される先行技術システムの一例を説明するブロック図である。
【０００７】
【図１Ｂ】１つの実施形態に従ってハイパースレッディング技術をサポートする１基のプロセッサを伴うシステムの一例を説明するブロック図である。
【０００８】
【図１Ｃ】１つの実施形態に係るデータバッファを用いる複数のアプリケーションの一例を説明するブロック図である。
【０００９】
【図２】１つの実施形態に係るマルチスレッディングシステムにおける異なる複数のステートを説明するブロック図である。
【００１０】
【図３Ａ】複数の図３Ａおよび３Ｂは、１つの実施形態に係るソフトウェアアプリケーションにより使用される複数のバッファの２つの例を説明する。
【図３Ｂ】複数の図３Ａおよび３Ｂは、１つの実施形態に係るソフトウェアアプリケーションにより使用される複数のバッファの２つの例を説明する。
【００１１】
【図４Ａ】複数の図４Ａおよび４Ｂは、１つの実施形態に係るマルチスレッディングシステムおいてディスパッチされた複数のスレッドの複数の例を説明する。
【図４Ｂ】複数の図４Ａおよび４Ｂは、１つの実施形態に係るマルチスレッディングシステムおいてディスパッチされた複数のスレッドの複数の例を説明する。
【００１２】
【図５】１つの実施形態に係る遅延ディスパッチスキームを用いてマルチスレッディングシステムにおいてディスパッチされた複数のスレッドの一例を説明するブロック図である。
【００１３】
【図６】１つの実施形態に係るビデオ復号化プロセスの一例を説明する図である。
【発明の詳細な説明】
【００１４】
１つの実施形態に関して、システム内の複数のリソースを管理する方法が開示される。本方法は、ソフトウェアアプリケーションに関連した複数のバッファをモニタすることおよびシステムにおける複数のスレッドをモニタすることを備える。利用可能な複数のリソース（例えば、電圧、周波数、複数のアーキテクチャパラメータなど）は、現在のバッファレベルおよびスレッド状態の少なくとも１つに基づいて増やされ、または減らされる。
【００１５】
下記の説明において、説明の目的のために、多くの特定の詳細が、本発明の完全な理解を提供するために示される。しかしながら、当業者にとって、本発明がこれら特定の複数の詳細なしで実施できることは、明らかである。他の複数の例において、周知の複数の構造、複数のプロセスおよび複数のデバイスは、過度の詳細のない説明を提供するために、ブロック図形式で示され、または要約した方式で参照される。
【００１６】
ハイパースレッディング技術は、Ｉｎｔｅｌ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎ（Ｓａｎｔａ  Ｃｌａｒａ、  Ｃａｌｉｆｏｒｎｉａ）からの技術であり、１つの物理プロセッサを用いて複数のスレッドを並列に実行することを可能にする。ハイパースレッディング技術は、１つの物理プロセッサ上で複数のソフトウェアアプリケーションの複数のスレッドが同時に実行される同時マルチスレッディング技術（ＳＭＴ）の形式である。これは、アーキテクチャステートを二重にし、それぞれのアーキテクチャステートが、複数のプロセッサ実行リソースの一式を共有することにより遂行される。
【００１７】
図１Ｂは、ハイパースレッディング技術をサポートしている１つのプロセッサを伴うシステムの一例を説明するブロック図である。システム１０１は、物理プロセッサ１５０が２つの論理プロセッサ１５５、１６０として認識されるために、２つのアーキテクチャステート１８５、１９０を有する物理プロセッサ１５０を備える。２つの論理プロセッサ１５５、１６０は、同じ複数の実行リソース１６５、複数のキャッシュ１７０、システムバス１７５およびメインメモリ１８０を共有する。物理プロセッサ１５０は、複数の論理プロセッサ１５５、１６０のどちらが利用可能かに依存してインターリーブ方式で複数のスレッドをスケジュールする。ハイパースレッディング技術は、複数のプロセッサ実行リソース１６５および全体のスループットの増加した活用をもたらす。
【００１８】
ハイパースレッディング技術は、複数の実行ユニットをより忙しくし、したがって、複数の実行ユニットは、ハイパースレッディング技術をサポートしないプロセッサと比べてより多くの電力を消費する。電力消費は、現代の複数のシステム、特に、バッテリ動作の複数のモバイルシステムにとって、重要な検討事項になってきている。これらの複数のバッテリ動作システムにおいて、既知の固定のアプリケーションのための平均電力消費は、システムの全体の性能の評価のために考慮すべき重要なパラメータである。例えば、動的電圧制御（ＤＶＭ）などを含む電力消費の低減のための異なる複数の技術が提案された。ＤＶＭを用いて、プロセッサの性能および電力消費は、適用される周波数および／または電圧を変えることにより設定される。
【００１９】
アプリケーション制約
多くのソフトウェアアプリケーションは、複数のデータ配信要求により制約される。図１Ｃは、１つの実施形態に係るデータバッファを用いる複数のアプリケーションの一例を説明するブロック図である。図１Ｃに説明されるように、第一のアプリケーション１８２は、データを生成し、第一のデータバッファ１８４に記憶する。第一のデータバッファ１８４内のデータは、その後入力として第二のアプリケーション１９２に使用される。第二のアプリケーション１９２は、その後第二のデータバッファ１９４に記憶されるデータを生成する。第一のアプリケーション１８２および第二のアプリケーション１９２がいずれのデータ配信要求にも制約されない場合、データがどの程度の速さで第一のデータバッファ１８４または第二のデータバッファ１９４に記憶されるかについての周波数、およびデータがどの程度の速さでこれら複数のバッファから取り出されるかについての周波数を任意に変えることは、第一のアプリケーション１８２および第二のアプリケーション１９２にほとんど影響をおよばさない。
【００２０】
しかしながら、第一のアプリケーション１８２および第二のアプリケーション１９２が複数のデータ配信要求の幾つかの方法により制約される場合、この要因を考慮しないことは、ユーザの経験および／またはソフトウェアアプリケーションの信頼性に干渉する。例えば、マルチメディアをストリーミングすること、または他の複数のリアルタイムアプリケーションのために、不適切な時間の低周波数プロセッサは、アプリケーションを機能させなくし、スキップした複数のフレームまたは劣化した複数のイメージを引き起こす。
【００２１】
１つの実施形態に関して、システム内の複数のリソースを制御することは、１つ以上のバッファを使用する１つ以上のソフトウェアアプリケーションをモニタすることにより実行される。ソフトウェアアプリケーションは、１つ以上のスレッドを有する。スレッドは、複数回ディスパッチされる。システムにおいて、同時に実行している２つ以上のスレッドがある。これら複数のスレッドは、同じソフトウェアアプリケーションから、または異なるソフトウェアアプリケーションからである。複数のソフトウェアアプリケーションは、複数のリアルタイムソフトウェアアプリケーションを含む。システムは、マルチスレッディングをサポートする１つ以上のプロセッサ（例えば、ハイパースレッディング技術をサポートするプロセッサ）を備える。システムは、マルチスレッディングシステムと称される。
【００２２】
ステート
図２は、１つの実施形態に係るマルチスレッディングシステムにおいて複数のリソースを管理するために使用される異なる複数のステートの１つの例を説明するブロック図である。システム２００は、アプリケーションステート２０５、第一のスレッドステート２０６、第一のマシンステート２０７、およびリソースマネージャ２１０を備える。アプリケーションステート２０５、第一のスレッドステート２０６、および第一のマシンステート２０７に依存して、リソースマネージャ２１０は、例えば、システム２００を第一のマシンステート２０７から第二のマシンステート２２０に遷移させ、および／またはシステム内のスレッドを第一のスレッドステート２０６から第二のスレッドステート２１５に遷移させる。
【００２３】
第一のマシンステート２０７および第二のマシンステート２２０は、システム２００が任意の特定の時刻にありうるステートの複数の例である。１つの実施形態に関して、マシンステートは、システム２００内の１つ以上のハードウェアコンポーネントの複数の構成または複数の性能レベルに関連する。マシンステートは、プロセッサに適用される周波数および／または電圧の複数のレベル、複数の不具合エントリの数、複数のハードウェアバッファ、メモリまたはキャッシュのサイズ、算術ロジックユニット（ＡＬＵ）、複数のレジスタなどに関連する。例えば、システム２００は、プロセッサに適用される周波数／電圧が減らされる場合、低電力消費ステート（例えば、第一のマシンステート２０７）にあってよい。同様に、システム２００は、プロセッサに適用される周波数／電圧が増やされる場合、標準電力消費ステート（例えば、第二のマシンステート２２０）にあってよい。異なる複数のマシンステートがある。
【００２４】
リソースマネージャ
リソースマネージャ２１０は、システム内で現在利用可能な複数のリソースのレベルを決定することに責任を持つ。リソースマネージャ２１０は、利用可能な複数のリソースを増やし、または減らす。したがって、システム２００を第一のマシンステート２０７から第二のマシンステート２２０へ遷移させる。例えば、リソースマネージャ２１０は、システム２００内のプロセッサに適用される周波数および／または電圧を動的にスケーリングするために複数の動作を実行する。リソースマネージャ２１０は、同様に、ソフトウェアアプリケーションにより使用される複数のバッファのサイズを変更する。一般的に、リソースマネージャ２１０は、システム２００内のハードウェア回路の少なくとも一部分を構成する。ハードウェア回路は、例えば、プロセッサ、メモリ、キャッシュ、チップセットなどの複数のハードウェアコンポーネントを含む。ハードウェア回路を構成することは、１つ以上のハードウェアコンポーネントを電源オフまたは電源オンすることを含む。これは、リソースマネージャ２１０がソフトウェアアプリケーションの実行に間接的に影響することを可能にする。例えば、利用可能な複数のリソースを増やすことは、ソフトウェアアプリケーションに、より速いレートで実行させ、また、利用可能な複数のリソースを減らすことは、ソフトウェアアプリケーションに、より遅いレートで実行させる。
【００２５】
リソースマネージャ２１０は、同様に、スレッドを第一のスレッドステート２０６から第二のスレッドステート２１５に遷移させることにより複数のリソースを保持する。例えば、第一のスレッドステート２０６は、ディスパッチされる準備ができた（または、レディ）、第二のスレッドステート２１５は、ディスパッチされることを遅らせる（または、待ち行列）ステートである。スレッドのスレッドステートを変更することは、その実行準備性（例えば、レディから待ち行列、または、待ち行列からレディ）、システム２００の電力消費を低減することに役立つ。状況に依存して、リソースマネージャ２１０は、スレッドのスレッドステートおよび／またはシステム２００のマシンステートを変更しても、しなくてもよいことを留意すべきである。
【００２６】
アプリケーションステート
ソフトウェアアプリケーションは、任意の特定の時刻において、異なるアプリケーションステート２０５にあってよい。例えば、ソフトウェアアプリケーションは、バッファ内のデータをバッファリングしており、バッファの現在のバッファレベルは、バッファがアンダーフロー条件に近いことを示してよく、１つのアプリケーションステートを表す。バッファの現在のバッファレベルが変化するにつれて、ソフトウェアアプリケーションは、異なるアプリケーションステートにある。ソフトウェアアプリケーションにより使用されるバッファの現在のバッファレベルは、標準条件および潜在的な複数のクリティカル条件を決定するためにモニタされる。複数のクリティカル条件は、バッファアンダーフロー条件、バッファオーバーフロー条件などを含む。
【００２７】
現在のバッファレベルおよびバッファの使用方法（例えば、入力または出力バッファ）に依存して、どれだけ速くデータがバッファに置かれ、またはバッファから読み出されるかのレートが、増やされ、または減らされる。これは、リソースマネージャ２１０が、システム２００内の利用可能な複数のリソースを増やし、または減らすことを要求する。例えば、入力バッファの現在のバッファレベルが潜在的なバッファオーバーフロー条件を示す場合、リソースマネージャ２１０は、入力バッファのサイズを増やす。他の例として、リソースマネージャ２１０は、システム２００内のプロセッサに適用される周波数／電圧を増やす。
【００２８】
図３Ａおよび図３Ｂは、１つの実施形態に係るソフトウェアアプリケーションにより使用される複数のバッファの２つの例を説明する。図３Ａは、ソフトウェアアプリケーションが１つのバッファ３００内のデータを伴う複数の動作を含む状況の一例を説明する。例えば、ソフトウェアアプリケーションは、バッファ３００からデータを読み出す。データは、バッファ３００に変化するレートで受信され（バッファ３００に通じる指向的な矢印により説明されるように）、ソフトウェアアプリケーションは、そのレート上で最小の制御を有する。
【００２９】
１つの実施形態に関して、バッファ３００のバッファレベル３０２は、システム内の複数のリソースのための要求を決定するために使用される。例えば、バッファレベル３０２が所定の低バッファマークＬ０より下の場合、システム２００内のプロセッサに適用される周波数および電圧は、ソフトウェアアプリケーションがバッファ３００からより遅いレートで読み出される（バッファ３００から出る指向的な矢印により説明されるように）ように減らされる。これは、潜在的なバッファアンダーフロー条件からバッファを保護することに役立つ。同様に、バッファレベル３０２が所定の高バッファマークＨ０より上の場合、ソフトウェアアプリケーションが潜在的なバッファオーバーフロー条件からバッファ３００を保護するためにより速いレートでバッファ３００からデータを読み出すように、プロセッサに適用される周波数および電圧は、増やされる。この例では、斜線部分が、バッファ３００内のデータを説明する。
【００３０】
図３Ｂは、ソフトウェアアプリケーションが２つのバッファ３０５および３１５内のデータを伴う複数の動作を含む状況の一例を説明する。１つの実施形態に関して、複数のバッファ３０５および３１５のそれぞれは、所定の低バッファマークＬ１およびＬ２のそれぞれに、ならびに所定の高バッファマークＨ１およびＨ２のそれぞれに関連する。複数のバッファ３０５および３１５のそれぞれは、現在のバッファレベル３１０および３２０にそれぞれ関連している。１つの実施形態に関して、ソフトウェアアプリケーションは、例えば、マルチメディアソフトウェアアプリケーションなどのリアルタイムソフトウェアアプリケーションである。リアルタイムソフトウェアアプリケーションの１つの特性は、例えば、３０フレーム／秒でビデオデータを表示する要求などの周期的なデッドラインの可能性である。そのような複数のソフトウェアアプリケーションは、なめらかなプレイバック、再生、録音などを保証するために全てのデッドラインに会うための幾つかのバッファを通常有する。例で用いられる用語「フレーム」は、複数のビデオアプリケーションまたは複数のオーディオアプリケーションに関連することが留意される。より一般的には、用語「フレーム」は、処理されるデータの一片と考えられる。
【００３１】
現在の例において、２つのバッファ３０５および３１５は、ビデオデコーダプロセスに使用される。バッファ３０５は、ビットストリームバッファであり、第一のレート３３０でネットワークまたはデータソースからデータを受信する（バッファ３０５に通じる指向性の矢印により説明されるように）。第一のレート３３０は、変数である。バッファ３０５内のデータは、ビデオデコーダプロセスにより操作され、その後、バッファ３１５に記憶される（バッファ３１５に通じる指向性の矢印により説明されるように）。ビデオデコーダプロセスは、第二のレート３４０で動作する。バッファ３１５は、非圧縮フレームバッファである。データは、その後、第三のレート３５０で表示されるためにバッファ３１５から読み出される（バッファ３１５から出る指向性の矢印により説明されるように）。任意の与えられる時刻において、第一のレート３３０、第二のレート３４０、および第三のレート３５０は、全て互いに異なる。１つの実施形態に関して、リソースマネージャ２１０は、第一のレート３３０、第二のレート３４０、および第三のレート３５０の１つ以上を変更するために、システム２００のマシンステートおよびシステム２００内のスレッドのスレッドステートを変更する。この変更は、動的に実行される。幾つかのソフトウェアアプリケーションは、入力データレートおよび出力データレートの両方の上での複数の制約を有するので、これは、必要である。
【００３２】
１つの実施形態に関して、入力データレートおよび出力データレートの両方の上に複数の制約がある場合、複数の図３Ａおよび３Ｂで説明される複数のバッファモニタリング動作の組み合わせは、システム２００内の複数のリソースを管理するために使用される。図３Ｂ内の図を参照して、複数のバッファ３０５および３１５の複数のバッファ充満レベルに依存して、システム２００内の複数のリソースのための要求は異なる。１つの実施形態に関して、バッファ３０５のバッファレベル３１０が、バッファ３０５内のデータの量が少ない（低レベルマークＬ１の下）、または標準（低レベルマークＬ１と高レベルマークＨ１との間）のどちらかであることを示し、また、バッファ３１５のバッファレベル３２０が、バッファ３１５内のデータが多い（高レベルマークＨ２の上）ことを示す場合、複数のリソースのための要求は、第二のレート３４０を低減するために低減される。これは、例えば、プロセッサに適合される周波数および電圧を減らすことを含む。これは、ソフトウェアアプリケーションが、バッファ３１５を潜在的なバッファオーバーフロー条件から保護するために、データをバッファ３１５に、より遅い第二のレート３４０で書き込むことを可能にする。
【００３３】
１つの実施形態に関して、バッファ３０５のバッファレベル３１０が、バッファ３０５内のデータの量が標準（低レベルマークＬ１と高レベルマークＨ１との間）または多い（高レベルマークＨ１の上）のどちらかであることを示し、およびバッファ３１５のバッファレベル３２０が、バッファ３１５内のデータが少ない（低レベルマークＬ２の下）ことを示す場合、複数のリソースのための要求は、第二のレート３４０を増やすために増やされる。これは、例えば、プロセッサに適用される周波数および電圧を増やすことを含む。これは、ソフトウェアアプリケーションが、バッファ３１５を潜在的なバッファアンダーフロー条件から保護するために、データをバッファ３１５に、より速い第二のレート３４０で書き込むことを可能にする。
【００３４】
複数のバッファレベル３１０および３２０をモニタリングすることに加えて、システム２００内の複数のリソースを管理する場合、データ依存性は、考慮される必要がある要因である。例えば、デッドラインの前にフレームを解凍／圧縮するために、時折、アンカーフレームを前もって解凍／圧縮することが必要である。データ依存性が存在する場合、リソースマネージャ２１０は、複数のリソースを管理するために、それが通常に行うことと異なるように何かをする必要がある。
【００３５】
ソフトウェアアプリケーションがビデオプレーヤアプリケーション（ビデオデコーダアプリケーションとは異なる）である例において、ソフトウェアアプリケーションは、複数のバッファ３０５および３１５内のデータの量が多い場合、および次のフレームが現行のフレームに依存する場合、ディスプレイレートをリサンプリングする必要がある。ディスプレイレートをリサンプリングすることは、例えば、バッファ３１５が第二のレート３４０で記憶される復号化されたフレームを記憶するための十分な空間を有するように、複数のフレームを１／３０秒（ビデオプレーヤアプリケーションのための標準の第三のレート３５０）よりも速いレートで表示することを含む。
【００３６】
その上、ソフトウェアアプリケーションは、次のフレームが現行のフレームに依存しない場合、および複数のバッファ３０５および３１５内のデータの量が多い（それぞれ、複数の高レベルマークＨ１およびＨ２の上）場合、フレームを落とす、または破棄する必要がある。例えば、バッファ３０５から取り除かれたフレームは、バッファ３１５に記憶される代わりに落とされる。これは、複数のバッファ３０５および３１５の潜在的なバッファオーバーフローを防止することに役立つ。フレームを落とすこと、または破棄することは、例えば、関連したスレッドを実行しないことを含む。データのバッファリングおよびデータの依存性は、アプリケーションステートの複数の例である。表１は、上記の複数の例の要約を提供する。図３Ｂで説明された複数のバッファ３０５および３１５は、それぞれビットストリームバッファおよび非圧縮フレームバッファとして表１でリストにされる。「−」を示す表エントリは、情報が実行される動作に関係しないことを示す。
【表１】
2011018352.tif 000003
【００３７】
スレッドステート
スレッドステートは、複数のソフトウェアアプリケーション内の複数のスレッドがディスパッチされる方法に関連する。上記で説明されたように、ソフトウェアアプリケーションは、同時に実行する複数のスレッドを有する。１つの実施形態に関して、ソフトウェアアプリケーションに関連したスレッドのディスパッチは、複数のスレッドが同時に実行する複数の機会を増やすために遅らされる。スレッドのディスパッチを遅らすことは、複数のリソースのための要求を低減することを助け、したがって、システム２００が、例えば、第一のマシンステート２０７から第二のマシンステート２２０に遷移することを可能にする。例えば、他に実行しているスレッドがない場合、スレッドは、ディスパッチされる準備ができた（または、レディ）ステート（例えば、第一のスレッドステート２０６）からディスパッチされることを遅らされる（または、待ち行列）ステート（例えば、第二のスレッドステート２１５）に遷移される。両方のスレッドが共にディスパッチされるように、スレッドは、他のスレッドが準備できるまで、待ち行列に入れられ、または遅らされる。共にディスパッチされる複数のスレッドは、同じソフトウェアアプリケーションに関連し、またはそれらは、異なる複数のソフトウェアアプリケーションに関連する。
【００３８】
概して、最大のスループットのために、準備のできた複数のスレッドは、即座にディスパッチされる。これは、複数のスレッドが、できるだけ速く終了することを可能にする。これは、一般的に、スループット指向の複数のソフトウェアアプリケーションにとって功を奏する。複数のスレッドをディスパッチすることにおける任意の遅延は、さもすればソフトウェアアプリケーションの性能に影響を与えていることと見なされる。１つのスレッドがその仕事を終えた場合、それは、次のスレッドが取りかかれるためにデータをバッファに書き込む。
【００３９】
図４Ａは、２つの例のスレッド４０１および４０２を説明する。それぞれのスレッドは、繰り返し、異なる時刻にディスパッチされる。この例において、スレッドがディスパッチされるたびにそれは、アクティビティと称される。例えば、複数のアクティビティ４０５および４１０は、異なる時刻にディスパッチされた同じスレッド４０１に関連する。同様に、複数のアクティビティ４１５および４２０は、同じスレッド４０２に関連する。この例において、第二のスレッド４０２は、第一のスレッド４０１に依存しており、第一のスレッド４０１の完了の直後にのみディスパッチされる。例えば、アクティビティ４１５は、アクティビティ４０５の完了の後にディスパッチされる。同様に、アクティビティ４２０は、アクティビティ４１０の完了の後にディスパッチされる。リアルタイムビデオアプリケーションにおいて、ビデオを取り込む１つのスレッド、ビットストリームを符号化する１つのスレッド、およびビットストリームを送り出す他のスレッドが存在する。これら複数のスレッドは、本来、ビデオフレームバッファ（例えば、バッファ３１５）およびビットストリームバッファ（例えば、バッファ３０５）により同期された。通常、データが準備できた場合、次のスレッドは、即座に、データに取りかかる。
【００４０】
スレッドがディスパッチされる時刻（１つのアクティビティとして）と、同じスレッドがディスパッチされる次の時刻（他のアクティビティとして）との間の期間は、サイクル期間と称される。ソフトウェアアプリケーションに依存して、サイクル期間は、小さいまたは大きい。サイクル期間が小さい場合、他のアクティビティとの幾つかの実行オーバーラップが存在する。図４Ａを参照して、２つのアクティビティ４０５および４１０は、同じスレッド４０１からである。この例において、アクティビティ４０５とアクティビティ４１０との間のサイクル期間４００は、アクティビティ４０５およびアクティビティ４１５の結合された実行時間と比較して小さい。そのようなものとして、アクティビティ４１０とアクティビティ４１５との間に実行オーバーラップが存在する。アクティビティ４１５は、それがディスパッチされる準備ができる前に、アクティビティ４０５の完了を待つ必要がある。これは、アクティビティ４１５の実行は、アクティビティ４０５の完了および出力に依存するからである。アクティビティ４１０は、しかしながら、アクティビティ４１５の完了に依存せず、それ故に、アクティビティ４１５の完了の前にディスパッチされる。これは、オーバーラップ期間４９０で示されるように、アクティビティ４１０とアクティビティ４１５との間の実行オーバーラップをもたらすことを留意すべきである。
【００４１】
アクティビティ４１５は、アクティビティ４１０がディスパッチされる時刻まで実行している唯一のアクティビティである。これは、システム２００が複数の論理プロセッサをサポートする場合、唯一の論理プロセッサは、アクティビティ４１５を実行することで忙しいが、他の論理プロセッサは、アクティビティ４１０がディスパッチされるまで、アイドルまたは停止となる。アクティビティ４１０がディスパッチされた後、２つの論理プロセッサは、期間４９０の間、２つのアクティビティ４１０および４１５を同時に実行することに忙しくなる。アクティビティ４１５が実行している唯一のアクティビティである期間は、ソフトウェアアプリケーションのシングルアクティビティ部分と称され、アクティビティ４１５がアクティビティ４１０と同時に実行している期間は、ソフトウェアアプリケーションのマルチスレッディング部分と称される。実行オーバーラップが存在するので、ソフトウェアアプリケーションは、ソフトウェアアプリケーションが一度に１つのスレッド実行する通常のプロセッサを伴い実行している場合は、より早く完了される。
【００４２】
サイクル期間が大きい場合、複数のアクティビティの間で任意の実行オーバーラップが存在しない。例えば、図４Ｂに説明されるように、スレッド４０３は、複数のアクティビティ４５５および４６０を有し、スレッド４０４は、アクティビティ４６５を有する。この例において、アクティビティ４５５とアクティビティ４６０との間のサイクル期間４５０は、複数のアクティビティ４６５および４５５の総実行時間より大きいことを留意すべきである。そのようなこととして、アクティビティ４６０とアクティビティ４６５との間には、実行オーバーラップは、存在しない。この例において、アクティビティ４６５は、それがディスパッチされる用意ができる前に、アクティビティ４５５の完了を待つ必要があるが、アクティビティ４６０は、ディスパッチされるために、アクティビティ４６５の完了を待つ必要はない。複数のアクティビティの間に実行オーバーラップが存在しない場合、マルチスレッディングシステム２００は、通常のシングルスレッディングシステムのように振る舞い、複数のアクティビティは、逐次的に実行しているように見なされる。
【００４３】
図５は、１つの実施形態に係る遅延ディスパッチスキームを用いるマルチスレッディングシステムにおいてディスパッチされた複数のスレッドの一例を説明するブロック図である。１つの実施形態に関して、複数のアクティビティがディスパッチされる準備ができたら直ぐに複数のアクティビティをディスパッチする代わりに、リソースマネージャ２１０は、複数のアクティビティを協調してディスパッチする。例えば、リソースマネージャ２１０は、複数のアクティビティ（または複数のスレッド）のディスパッチを、実行オーバーラップの増加があるように、協調させる。
【００４４】
図５の図は、スレッド５０１およびスレッド５０２の複数の例を説明する。スレッド５０１は、複数のアクティビティ５０５および５１０を有する。スレッド５０２は、複数のアクティビティ５１５および５２０を有する。この例において、アクティビティ５１５は、アクティビティ５０５がその実行を完了した場合、ディスパッチされる準備ができたステートにある。ディスパッチされる準備ができたステートは、図２の例に説明されるように、第一のスレッドステート２０６と称される。しかしながら、アクティビティ５０５の完了の直後にアクティビティ５１５をディスパッチする代わりに、リソースマネージャ２１０は、アクティビティ５１５のディスパッチを、アクティビティ５１０がディスパッチされる準備ができるまで遅延させる。アクティビティ５１５の遅延ステートは、図２の例に説明されるように、第二のスレッドステート２１５と称される。遅延させることにより、アクティビティ５１０およびアクティビティ５１５は、それらが同時に実行するように、共に実行される。これは、オーバーラップ期間５２５として説明される。
【００４５】
幾つかの状況において、アクティビティ５１５は、実行オーバーラップが生じるように、それがディスパッチされる前に１サイクル期間５００より多くの間、遅らされなければならない。あるいは、アクティビティ５１５は、ディスパッチされることを待機している他のアクティビティが存在する場合、遅らされる必要はない。この他のアクティビティのディスパッチは、以前に遅らされた。この状況において、複数のアクティビティの両方は、共にディスパッチされる。
【００４６】
複数のアクティビティ５１０および５１５の１つまたは両方が実行している期間は、非停止期間５３０と称される。非停止期間５３０の間、システム２００は、ビジーのままであり、複数のリソースを消費する。非停止期間５３０は、同様に、オーバーラップ期間５２５を有することを留意すべきである。アクティビティ５１５のディスパッチを遅れさせることにより、実行されない期間が導入される。この期間は、停止した、またはアイドル期間５３５と称される。１つの実施形態に関して、停止した期間５３５の間、システム２００は、よりビジーではなく、したがって、より少ないリソースを必要とする。例えば、ハイパースレッディング技術をサポートするプロセッサを用いる場合、複数のリソースのための複数の要求は、両方の論理プロセッサがアイドルなので、停止した期間の間はより少ない。複数のリソースのための複数の要求は、複数の論理プロセッサのどちらかまたは両方が忙しい場合で、およそ同様である。したがって、１つの論理プロセッサの複数のビジーサイクルを他のプロセッサの複数のビジーサイクルと重複させることは、複数のリソースを保持するために都合がよい。
【００４７】
１つの実施形態に関して、必要以上にスレッドを遅延させることを避けるために、タイムアウトスキームが実装される。例えば、タイムアウトスキームは、遅延の所定の量を設定することを含み、それにより、アクティビティは、ディスパッチされる前に待ち行列内で遅らされる。他の実施形態に関して、複数のアクティビティは、異なる複数の優先度を有し、それぞれの優先度は、ディスパッチされる前の異なる遅延時間に関連する。アクティビティが、たとえ実行しているいずれの他のアクティビティが存在しなくても、遅延なしでディスパッチされることを必要とする複数の状況が存在することが、留意される。例えば、アクティビティは、クリティカルとしてフラグを立てられ、そのディスパッチは、アクティビティの準備ができている場合は直ちに実行される。
【００４８】
アプリケーションステート、スレッドステート、およびマシンステート
１つの実施形態に関して、リソースマネージャ２１０は、システム２００を１つのマシンステートから他のマシンステートに遷移させるかどうかを決定するために、ソフトウェアアプリケーションのアプリケーションステートおよびスレッドのスレッドステートを評価する。図３Ｂで説明された例において、スレッドは、バッファ３０５からフレームを復号化するアクティビティを有する。フレームを復号化することは、直接的に、または間接的にバッファ３０５内のデータ量に影響を与える。バッファ３０５のバッファレベル３１０が、バッファ３０５内のデータ量が少ない（低レベルマークＬ１の下）ことを示す場合、およびバッファ３１５のバッファレベル３２０が、バッファ３１５内のデータが標準（低レベルマークＬ２と高レベルマークＨ２との間）であることを示す場合、リソースマネージャ２１０は、現在のアクティビティをディスパッチするかどうかを決定する前に、システム２００内の他の複数のアクティビティを評価する。１つの実施形態に関して、他の実行しているアクティビティが存在し、そのアクティビティは、現在のアクティビティに関連している（例えば、前回のフレームを現行フレームに復号化する）場合、リソースマネージャ２１０は、利用可能な複数のリソースを減らすことにより（例えば、プロセッサに適用される周波数／電圧を減らす）、システム２００のマシンシステムを変更する。これは、実行中のアクティビティの実行を遅くし、バッファ３０５内のデータ量がすでに少ないので、バッファ３０５を使い果たすこと、またはアンダーフローさせることの可能性を減らす。
【００４９】
他の実施形態において、実行中の他のアクティビティが存在し、そのアクティビティは、現在のアクティビティが現在のアクティビティと関連しない場合（例えば、実行中のアクティビティは、現在のフレームの前のフレームを復号化していない）、現在のアクティビティのディスパッチは、遅らされる。これは、例えば、現在のアクティビティを、１つ以上のサイクル期間のために、待ち行列の中に配置することを含む。現在のアクティビティのディスパッチを遅らせることにより、バッファ３０５を消耗することの潜在性は、減らされる。
【００５０】
一般的に、１つ以上のアクティビティの一式のディスパッチを遅らせることおよび利用可能な複数のリソース減らすことは、可能性のある複数のバッファアンダーフローまたはオーバーフロー条件を減らす。１つ以上のアクティビティの一式のディスパッチを遅らせることは、複数の同時マルチスレッディングプロセッサ上の複数のプロセッサリソースのより効果的な活用を可能にする。表２は、上記複数の例の要約を提供する。
バッファ３０５  →  ビットストリームバッファレベル  →  低
バッファ３１５  →  非圧縮フレームバッファ  →  標準
【表２】
2011018352.tif 000004
【００５１】
１つの実施形態に関して、バッファレベル３１０が、バッファ３０５内のデータ量が標準（低レベルマークＬ１と、高レベルマークＨ１との間）であることを示し、バッファレベル３２０が、バッファ３１５内のデータ量が標準（低レベルマークＬ２と、高レベルマークＨ２との間）であることを示す場合、リソースマネージャ２１０は、現在のアクティビティをディスパッチする前に、システム２００内の他の複数のアクティビティを評価する。実行している他のアクティビティが存在する場合、またはディスパッチされる準備ができている他のアクティビティが存在する場合、現在のアクティビティは、実行オーバーラップが存在するように、リソースマネージャ２１０によりディスパッチされる。しかしながら、実行している他のアクティビティが存在しない場合、または、ディスパッチされる準備ができている他のアクティビティが存在しない場合、リソースマネージャ２１０は、現在のアクティビティのディスパッチを遅らせる。この状況において、遅延は、複数のバッファ３０５および３１５内のデータの現在の複数のバッファレベル上に依存しない（なぜなら、それらは、両方とも標準レベルにある）。しかしながら、遅延は、実行オーバーラップのための可能性を増やし、それは、複数のスレッドのための要求を減らすことを助ける。表３は、上記複数の例の要約を提供する。
バッファ３０５  →  ビットストリームレベル  →  標準
バッファ３１５  →  非圧縮フレームバッファレベル  →  標準
【表３】
2011018352.tif 000005
【００５２】
１つの実施形態に関して、バッファレベル３１０が、バッファ３０５内のデータ量が多い（高レベルマークＨ１の上）ことを示し、バッファ３１５のバッファレベル３２０が、バッファ３１５内のデータが標準（低レベルマークＬ２と高レベルマークＨ２との間）であることを示す場合、リソースマネージャ２１０は、現在のアクティビティをディスパッチする前に、システム２００における他の複数のアクティビティを評価する。他の実行中のアクティビティがある場合、または他のディスパッチされる準備ができたアクティビティがある場合、現在のアクティビティは、実行オーバーラップが存在するように、ディスパッチされる。しかしながら、他の実行中のアクティビティがない場合、およびディスパッチされる準備ができたアクティビティがない場合、リソースマネージャ２１０は、可能なだけ早くデータをバッファ３０５の外に出すために現在のアクティビティをディスパッチする。これは、バッファ３０５内のデータ量が高レベルであり、現在のアクティビティをディスパッチすることにおける任意の不必要な遅延は、潜在的に、バッファ３０５に起こるバッファオーバーフロー条件を引き起こすからである。１つの実施形態に関して、現在のアクティビティをディスパッチすることに加えて、リソースマネージャ２１０は、同様に、バッファ３０５から読み出され、または処理されるデータのレートを上げるために、利用可能な複数のリソース（例えば、プロセッサに適用される周波数／電圧を上げる）を増やす。これは、システム２００を、１つのマシンステートから他のマシンステートに遷移させ、バッファ３０５への潜在的なオーバーフロー条件を避けることに役立つ。図４は、上記複数の例のデータの要約を提供する。
バッファ３０５  →  ビットストリームバッファレベル  →  高
バッファ３１５  →  非圧縮フレームバッファ  →  標準
【表４】
2011018352.tif 000006
【００５３】
他の実施形態に関して、複数のアプリケーションステートおよび／または複数のスレッドステートは、マルチスレッディングシステムにおいてリソース管理のために積極的に作成される。例えば、複数のアプリケーションは、複数のスレッドの形式の複数のサブタスクに細分される。これは、たとえアプリケーションがマルチスレッドでなくてもなされる。データバッファは、複数のスレッドのためにセットアップされ、一時的なアプリケーションデータ記憶のために使用される。その上、複数のバッファ指示部レベルは、バッファオーバーフロー条件および／またはアンダーフロー条件を定義するために設定される。バッファの複数のステートは、オーバーフロー指示部またはアンダーフロー指示部に対する現在のバッファ充満レベルを判定することにより、モニタされる。バッファの複数のステートおよび／または複数のスレッドの複数のステートをモニタすることにより、マルチスレッディングシステム内の複数のリソースが調整される。
【００５４】
図６は、１つの実施形態に係るビデオ復号化プロセスの一例を説明する図である。ブロック６０５において、フレームが受信され、復号化される準備ができる。このフレームは、例えば、図３Ｂに説明されるようなバッファ３０５などのバッファから受信される。ブロック６１０において、例えば、図３Ｂに説明されるようなバッファ３１５などの非圧縮フレームバッファ内に十分な非圧縮フレームがあるかどうかを判断するテストが実施される。バッファ３１５内に十分なデータが存在しない場合（例えば、現在のバッファレベル３２０は、低レベルマークＬ２の下）、プロセスは、ブロック６９０へ流れ、適切な復号化アクティビティが、フレームを復号化するためにディスパッチされる。
【００５５】
ブロック６１０から、十分な非圧縮フレームが存在する場合（バッファ３１５内に）、プロセスは、ブロック６１５へ流れ、次のフレームが現在のフレームに依存するかどうかを判断するためにテストが実施される。依存性が存在する場合、プロセスは、ブロック６１５からブロック６４０へ流れ、実行中の他のアクティビティまたはスレッドがあるかどうかを判断するためのテストが実施される。実行中の他のアクティビティが存在する場合、現在のアクティビティは、実行オーバーラップを可能にするためにディスパッチされる。
【００５６】
ブロック６４０から、実行中の他のアクティビティが存在しない場合、プロセスは、ブロック６４５へ流れ、ディスパッチされる準備ができている他のアクティビティが存在するかどうかを判断するためにテストが実施される。これは、以前に遅らされたアクティビティである。ディスパッチされる準備のできたアクティビティが存在する場合、現在のアクティビティおよびディスパッチされる準備のできたアクティビティは、ブロック６６０に示されるように、共にディスパッチされる。
【００５７】
ブロック６４５から、ディスパッチされる準備のできた他のアクティビティが存在しない場合、現在のアクティビティは、ディスパッチされることから遅延される。これは、ブロック６５０に示されるように、例えば、現在のアクティビティを待ち行列に配置することを含む。現在のアクティビティは、他のアクティビティがディスパッチされる準備ができるまで、待ち行列の中で待機する。１つの実施形態に関して、アクティビティが待ち行列の中で待機する時間を制限するために、所定の時間が使用される。他の実施形態に関して、ブロック６５５に示されるように、現在のアクティビティが遅らされることができるかどうかを判断するためにテストが実施され、ブロック６９０に示されるように、現在のアクティビティが遅らされることができない場合、現在のアクティビティは、ディスパッチされる。
【００５８】
ブロック６１５から、次のフレームが現在のフレームに依存しない場合、プロセスは、ブロック６２０に流れ、復号化される準備ができた他のフレームが存在するかどうかを判断するためにテストが実施される。復号化される準備のできた他のフレームが存在する場合、現在のフレームおよび他のフレームは、共に復号化される（例えば、両方のアクティビティが共にディスパッチされる）。ブロック６２０から、復号化される他のフレームがない場合、プロセスは、ブロック６５０へ流れ、上記で説明されたように、待機が生じる。
【００５９】
これらさまざまな方法の複数の動作は、コンピュータシステム内のプロセッサにより実装され、プロセッサは、マシン可読記憶媒体と見なされるメモリに記憶される複数のコンピュータプログラム命令の複数のシーケンスを実行する。メモリは、ランダムアクセスメモリ、読み出し専用メモリ、大容量記憶デバイスなどの固定記憶域メモリ（ｐｅｒｓｉｓｔｅｎｔ  ｓｔｏｒａｇｅ  ｍｅｍｏｒｙ）、またはそれらデバイスの任意の組み合わせでよい。命令の複数のシーケンスの実行は、プロセッサに、図６の例に説明されるような動作を実行させる。
【００６０】
複数の命令は、ストレージデバイスから、または１つ以上の他のコンピュータシステム（例えば、サーバコンピュータシステム）からコンピュータシステムのメモリへロードされる。複数の命令は、幾つかのストレージデバイス（例えば、ＤＲＡＭおよび仮想メモリなどのハードディスク）に、同時に記憶される。したがって、これら複数の命令の実行は、プロセッサにより直接実行される。他の複数のケースにおいて、複数の命令は、プロセッサにより直接実行され、またはそれらは直接実行されない。これらの状況の下、複数の実行は、プロセッサに複数の命令を解釈するインタープリタを実行させることにより、またはプロセッサに受信された複数の命令をプロセッサにより直接実行されることができる複数の命令に変換するコンパイラを実行させることにより実行される。他の複数の実施形態において、本発明を実装するために、複数の命令の代わりに、または複数の命令と組み合わせて、結線回路が使用される。例えば、リソースマネージャは、上記で説明された１つ以上の動作（例えば、複数のアプリケーションステートをモニタリングすること、複数のリソースを調整することなど）を実行するロジックを含むために実装される。したがって、本発明は、ハードウェア回路およびソフトウェアのいずれの特定の組み合わせに、またはコンピュータシステムにより実行される複数の命令のためのいずれの特定のソースに制限されない。
【００６１】
複数のシステムにおいて複数のリソースを管理するための複数の方法および複数のシステムが開示された。複数のリソースのための要求は、データのバッファリングをモニタすることおよびソフトウェアアプリケーションの複数のスレッドのディスパッチを協調させることにより、減らされ、または増やされる。これは、プロセッサアイドル時間を増やすことに役立つ。
【００６２】
本発明は、特定の例の複数の実施形態を参照して説明されたが、様々な修正および変更が、複数の請求項に記載の本発明の上位精神および範囲を逸脱することなく、これら複数の実施形態になされることは、明白である。例えば、本明細書は、複数のスレッドおよび複数のアクティビティのディスパッチを参照したが、説明された複数の技術は、例えば、複数のプロセッサ、複数のタスク、複数のプロセスの複数の部分、複数のタスクの複数の部分などの他の複数の実体をスケジューリングするために、同様に使用される。その上、複数の技術は、他の複数のマルチスレッディングプロセッサに同様に使用され、ハイパースレッディング技術をサポートする複数のプロセッサに制限されない。例えば、プロセッサは、デュアルコアを有するプロセッサであり、複数のスレッドを同時に実行できる。したがって、本明細書および複数の図面は、限定的な意味ではなく説明のためである。
【図１Ａ】
2011018352.tif 000007
【図１Ｂ】
2011018352.tif 000008
【図１Ｃ】
2011018352.tif 000009
【図２】
2011018352.tif 000010
【図３Ａ】
2011018352.tif 000011
【図３Ｂ】
2011018352.tif 000012
【図４Ａ】
2011018352.tif 000013
【図４Ｂ】
2011018352.tif 000014
【図５】
2011018352.tif 000015
【図６】
2011018352.tif 000016
【手続補正書】
【提出日】平成22年9月22日(2010.9.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アプリケーションに関連したスレッドを少なくとも含むシステム内の複数のスレッドのステートをモニタする段階と、
アウトオブオーダ実行プロセッサが、前記システム内の１以上のスレッドに関連した命令のディスパッチを協調させる段階と、
前記システム内の１以上のプロセッサに適用される周波数および電圧を、少なくともアプリケーションの要求に基づいて動的に調整する段階と、
前記アウトオブオーダ実行プロセッサが、動的に前記システム内の複数のリソースを割り当てる段階と
を備える方法。
【請求項２】
前記システム内の前記複数のリソースは、キャッシュメモリを含む
請求項１に記載の方法。
【請求項３】
前記キャッシュメモリは、前記システム内の前記１以上のプロセッサのための共有メモリである
請求項２に記載の方法。
【請求項４】
前記スレッドは、１以上のアクティビティを有し、
前記ディスパッチを協調させる段階は、前記１以上のアクティビティの実行準備性を評価する段階を有する
請求項１に記載の方法。
【請求項５】
前記ディスパッチを協調させる段階は、ディスパッチされる準備ができたアクティビティをディスパッチされることから遅延させる段階を有する
請求項４に記載の方法。
【請求項６】
１以上の前記アプリケーションの第１スレッドが有する第１アクティビティおよび１以上の前記アプリケーションの第２スレッドが有する第２アクティビティの両方が共にディスパッチされるべく、前記第１アクティビティのディスパッチは、前記第２アクティビティの準備ができるまで遅延される
請求項５に記載の方法。
【請求項７】
前記アウトオブオーダ実行プロセッサが、前記システムのマシンステートをモニタする段階
をさらに備え、
前記システムのマシンステートをモニタする段階は、
前記システム内の利用可能な複数のリソースを決定する段階と、
前記システム内の前記アプリケーションの要求および前記複数のスレッドのステートに基づいて、前記複数のリソースを増加または減少させる段階と
を有する請求項１から６のいずれか一項に記載の方法。
【請求項８】
前記複数のリソースは、設定可能な複数のハードウェアコンポーネントを含む
請求項７に記載の方法。
【請求項９】
前記設定可能なハードウェアコンポーネントは、前記システム内の前記１以上のプロセッサ、複数のハードウェアバッファ、メモリ、キャッシュ、算術論理ユニット（ＡＬＵ）、および複数のレジスタを含む
請求項８に記載の方法。
【請求項１０】
前記複数のリソースを増加または減少させる段階は、前記システム内の回路の少なくとも一部を電源オンまたは電源オフする段階を有する
請求項７から９のいずれか一項に記載の方法。
【請求項１１】
前記ディスパッチを協調させる段階は、複数のスレッドの依存性を決定する段階を有し、
前記アプリケーションの現在のスレッドと次のスレッドとの間に依存性があり、複数のバッファの全てのバッファ充満レベルがオーバーフロー状態になる可能性がある場合、前記システム内の前記複数のリソースは増加される
請求項７から９のいずれか一項に記載の方法。
【請求項１２】
アプリケーションに関連したスレッドを少なくとも含むシステム内の複数のスレッドのステートを、前記複数のスレッドをディスパッチするためにモニタする段階と、
プロセッサが、前記システム内の１以上のプロセッサに適用される周波数および電圧を、少なくともアプリケーションの特性に基づいて動的に調整する段階と、
前記プロセッサが、前記システム内の複数のリソースを管理する段階と
を備える方法。
【請求項１３】
前記複数のリソースは、前記システム内の設定可能な複数のハードウェアコンポーネントを含む
請求項１２に記載の方法。
【請求項１４】
前記複数のリソースを管理する段階は、前記システム内の回路の少なくとも一部を電源オンまたは電源オフする段階を有する
請求項１２に記載の方法。
【請求項１５】
前記プロセッサが、前記システム内で実行中のアプリケーションのステートを管理する段階
をさらに備え、
前記アプリケーションの前記ステートは、前記アプリケーションにより使用される１以上のバッファのバッファ充満レベルを含み、
前記複数のリソースは、前記アプリケーションの前記ステートに基づいて増加または減少される
請求項１２または１３に記載の方法。
【請求項１６】
データおよび複数の命令を記憶するためのメモリと、
バス上で前記メモリに結合されたプロセッサであって、複数の命令を実行できるプロセッサと
を備え、
前記プロセッサは、
前記メモリからの複数の命令のシーケンスを受信するバスユニットと、
前記バスユニットに結合された実行ユニットであって、複数の命令の前記シーケンスを実行する実行ユニットと
を有し、
複数の命令の前記シーケンスは、前記実行ユニットに、
アプリケーションに関連したスレッドを少なくとも含むシステム内の複数のスレッドのステートをモニタさせ、
前記システム内の１以上のスレッドに関連した命令のディスパッチを協調させ、
前記システム内の１以上のプロセッサに適用される周波数および電圧を、少なくともアプリケーションの要求に基づいて動的に調整させ、
動的に前記システム内の複数のリソースを割り当てさせる
装置。
【請求項１７】
前記システム内の前記複数のリソースは、キャッシュメモリを含む
請求項１６に記載の装置。
【請求項１８】
前記キャッシュメモリは、前記システム内の前記１以上のプロセッサのための共有メモリである
請求項１７に記載の装置。
【請求項１９】
前記複数のリソースの割り当ては、前記システム内の回路の少なくとも一部を電源オンまたは電源オフすることを含む
請求項１６から１８のいずれか一項に記載の装置。
【請求項２０】
前記プロセッサは、同時マルチスレッディングプロセッサである
請求項１６から１８のいずれか一項に記載の装置。
【外国語明細書】
2011018352000001.pdf