JP2022550064A - マルチスレッドマイクロプロセッサにおける共有リソース割り当て - Google Patents

Abstract

各スレッドの共有リソースの有用性に基づいて、マルチスレッドマイクロプロセッサにおけるスレッドに共有リソースを割り当てるアプローチが提供される。スレッドの共有リソースの有用性は、スレッドに割り当てられた共有リソース内のエントリの数と、共有リソース内でスレッドが有するアクティブエントリの数と、に基づいて決定される。並列度が低く、共有リソース内で多数のエントリが割り当てられ、共有リソース内で少数のアクティブエントリを有するスレッドは、共有リソース内の少ないエントリで効率的に動作することができ、共有リソース内の割り当て制限を低減させることができる。【選択図】図１

Description

このセクションに記載されたアプローチは、追及され得るアプローチであるが、必ずしも以前に着想され、追及されたアプローチではない。したがって、特に断りのない限り、このセクションに記載された何れかのアプローチがこのセクションに含まれるという理由だけで、従来技術として適格であると想定されるべきではない。更に、このセクションに記載される何れかのアプローチがこのセクションに含まれるという理由だけで、よく理解され、日常的であり、又は、従来通りであると想定されるべきではない。

マルチスレッドマイクロプロセッサは、複数のスレッドによって使用されるロードキュー及びリザベーションステーション等の共有リソースを有することが多い。共有リソースは、多くの場合、先着順（first come, first served）を原則としてスレッドに割り当てられる。このアプローチによる問題点は、共有リソースを使用するスレッドが異なる実行特性を有する場合、或るスレッドが共有リソースの過剰なシェアを取得することによって、他のスレッドの効率的な実行を妨げる可能性があることである。例えば、或るスレッドが、ロードキュー内の大部分のエントリを取得する場合がある。この場合、他のスレッドがロードキューに多くのエントリを有することで利益を得ることができるのに、それらのスレッドが利用できるエントリが少なすぎると、他のスレッドのパフォーマンスが低下する可能性がある。

この問題に対する技術的な解決策の１つは、スレッドによる共有リソースの使用を制限することである。例えば、スレッドに割り当てられた共有リソース内のエントリの数は、全てのスレッドで又は個々のスレッド単位で上限を設定することができる。しかしながら、スレッドの実行特性が著しく変化することがあり、一部のスレッドは、共有リソース内の制限された数以上のエントリを有することで利益を得る可能性があるので、特定のスレッドへの影響を把握せずにスレッドに割り当てられるエントリの数を制限すると、全体的なパフォーマンスが低下することがある。よって、マルチスレッドマイクロプロセッサにおける共有リソースの使用を管理するためのより良好なアプローチが求められている。

実施形態は、添付図面に例示として示されており、限定するものではない。同様の符号は、同様の要素を指す。

マルチスレッドマイクロプロセッサを表すブロック図である。 共有リソースへのアクセスを管理するために共有リソースロジックによって使用される情報のテーブルを表すブロック図である。 スレッドへの共有リソースの割り当てを変更するように共有リソースロジックが動作するタイムラインを表すブロック図である。 スレッドに対する共有リソースの有用性に基づいてマルチスレッドマイクロプロセッサ上のスレッドに共有リソースを割り当てることを表すフローチャートである。 第１のクロックサイクルウィンドウにわたるスレッドに対して取得された例示的な使用状況データを表す図である。 第２のクロックサイクルウィンドウにわたるスレッドに対して取得された例示的な使用状況データを表す図である。 第３のクロックサイクルウィンドウにわたるスレッドに対して取得された例示的な使用状況データを表す図である。 第４のクロックサイクルウィンドウにわたるスレッドに対して取得された例示的な使用状況データを表す図である。

以下の説明では、説明のために、実施形態の十分な理解を提供するために、多数の具体的な詳細が示されている。しかしながら、実施形態が、それらの具体的な詳細なしに実施され得ることは、当業者には明らかであろう。他の例では、実施形態を不必要に不明瞭にすることを回避するために、周知の構造及びデバイスがブロック図の形式で示されている。
Ｉ．概要
ＩＩ．アーキテクチャ
ＩＩＩ．有用性に基づいた共有リソースへのスレッドアクセスの管理
Ａ．概要
Ｂ．スレッドに対する共有リソース割り当て制限の変更
Ｃ．有用性メトリック
Ｄ．リソース割り当て変動の対処

（Ｉ．概要）
マルチスレッドマイクロプロセッサにおいて、各スレッドに対する共有リソースの有用性に基づいてスレッドに共有リソースを割り当てるアプローチが提供される。スレッドに対する共有リソースの有用性は、スレッドに割り当てられた共有リソース内のエントリの数と、共有リソース内でスレッドが有するアクティブエントリの数と、に基づいて決定される。共有リソース内で多数のエントリが割り当てられ、共有リソース内で少数のアクティブエントリを有するスレッドは、並列度が低いことを示し、共有リソース内で少ないエントリで効率的に動作することができ、共有リソース内での割り当てを減らすことができる。本明細書で使用される「アクティブエントリ」という用語は、ワークを実行している（例えば、命令を準備又は実行するために現在使用されている）共有リソース内のエントリを指す。異なるスレッドは、同じ共有リソースに対して異なるレベルの有用性を有することがあり、本アプローチは、任意の数のスレッド及び共有リソースに適用可能である。このアプローチにより、或るスレッドが共有リソースのエントリを大量に取得して、その共有リソースを使用する他のスレッドのパフォーマンスを低下させる可能性を低減することができる。

（ＩＩ．アーキテクチャ）
図１は、制御ユニット１１０と、算術論理ユニット（ＡＬＵ）１２０と、スレッドレジスタ１３０と、共有リソース１４０と、共有リソースロジック１５０と、を含むマルチスレッドマイクロプロセッサ１００を表すブロック図である。スレッドレジスタ１３０は、特定のスレッド専用のレジスタである。マイクロプロセッサは、任意の数のスレッドをサポートすることができるが、実施形態は、特定の数のスレッドに限定されない。共有リソース１４０は、マルチスレッドマイクロプロセッサ１００において複数のスレッドによって使用される任意のタイプのリソースであってもよい。共有リソース１４０の例は、ロードキュー、レジスタファイル、リザベーションステーション等を含むが、これらに限定されない。

共有リソースロジック１５０は、以下により詳細に説明するように、スレッドに対する共有リソース１４０の有用性に基づいて、マルチスレッドマイクロプロセッサ１００上で実行するスレッドへの共有リソース１４０の割り当てを管理する。共有リソースロジック１５０は、コンピュータハードウェア、コンピュータソフトウェア、又は、コンピュータハードウェア及びソフトウェアの任意の組み合わせによって実装されてもよい。共有リソースロジック１５０は、説明目的で個別の要素として図１に表されているが、共有リソースロジック１５０は、マルチスレッドマイクロプロセッサ１００内の他の要素（例えば、リソース割り当てロジック、スレッド切り替えロジック及びディスパッチ規制ロジック）に組み込まれてもよい。マルチスレッドマイクロプロセッサ１００は、図１に表されていないが、特定の実施形態に応じて変化することができる追加の要素を含んでもよい。

（ＩＩＩ．有用性に基づいた共有リソースへのスレッドアクセスの管理）
（Ａ．概要）
共有リソースロジック１５０は、スレッドに対する共有リソース１４０の有用性を評価し、有用性に基づいて、共有リソース１４０に対するスレッドに割り当てられた割り当て制限を変更する。本明細書で使用される「割り当て制限」という用語は、スレッドに割り当てることができる共有リソース１４０内のエントリの数に対する制限である。図２は、共有リソース１４０へのアクセスを管理するために共有リソースロジック１５０によって使用される情報のテーブル２００を表すブロック図である。テーブル２００内の各行は、マルチスレッドマイクロプロセッサ１００上で実行するスレッドに対応する。スレッド毎のデータの列は、第１の列において、スレッドを識別するデータを含み、第２の列において、スレッドに現在割り当てられている共有リソース１４０内のエントリの数を含み、第３の列において、共有リソース１４０内のスレッドに対するアクティブエントリの数を含み、第４の列において、有用性メトリックを含む。有用性メトリックは、スレッドに現在割り当てられているエントリの数に対するアクティブエントリの数の割合である。テーブル２００内の情報は、マルチスレッドマイクロプロセッサ１００の内部又は外部で維持されてもよい。各スレッドに割り当てられた共有リソース１４０内のエントリの数及びスレッド毎の共有リソース１４０内のアクティブエントリの数は、例えば、カウンタ又は他のハードウェア要素を使用して追跡されてもよい。

図３は、共有リソースロジック１５０が、スレッドに対する共有リソース１４０の有用性に基づいて、共有リソース１４０に対してスレッドに割り当てられた割り当て制限を変更するタイムライン３００を表すブロック図である。タイムライン３００は、クロックサイクルウィンドウ（ＣＣＷ）の形式にあるＮの数の時間周期（期間）を含み、各ＣＣＷは、クロックサイクルのセットである。各ＣＣＷ内のクロックサイクルの数は、パフォーマンスモデリングを使用して決定されてもよいし、特定の実施形態に応じて変化してもよい。パフォーマンスモデリングは、スレッドが共有リソース内の非常に多くのエントリを消費して他のスレッドのパフォーマンスを低下させることを防止するために十分に迅速に反応することと、スレッドが利用可能な共有リソース内のエントリの数を過度に制限しないことと等の要因をバランスさせることができる。実施形態では、ＣＣＷの各々は、１６のクロックサイクルを含む。クロックサイクルの数は、共有リソースロジック１５０において構成されてもよく、例えば、オペレーティングシステムを介して選択可能であってもよい。ＣＣＷが連続的であるものとして図３に表されているが、ＣＣＷは、連続的であることに限定されず、インタースティシャル（interstitial）クロックサイクルを有してもよい。また、ＣＣＷ間のインタースティシャルサイクルの数は、ＣＣＷ間で変化してもよいし、経時的に変化してもよい。クロックサイクルウィンドウの形式にある時間周期のコンテキストで実施形態が本明細書で説明されるが、実施形態は、クロックサイクルウィンドウそのものに限定されない。

時間Ｔ０において開始して、スレッドによる共有リソース１４０の使用は、ＣＣＷ１にわたって監視され、ＣＣＷ１の終わりである時間Ｔ１において、スレッドによる共有リソース１４０の使用が評価され、スレッドに割り当てられた割り当て制限が次のＣＣＷ２について更新される。ＣＣＷ２は、ＣＣＷ１の後に任意の数のクロックサイクルを発生させてもよいし、ＣＣＷ１とＣＣＷ２との間のインタースティシャルクロックサイクルの数が経時的に変化してもよいことに留意されたい。実施形態によれば、共有リソースロジック１５０は、他のスレッドのパフォーマンスを潜在的に低下させるのに十分な共有リソース内の多くの数のエントリが割り当てられているスレッドを識別する。次に、共有リソースロジック１５０は、これらのスレッドの何れかが、共有リソース１５０内で少数のアクティブエントリを有するかどうかを判別する。共有リソース１４０内で多くの数のエントリが割り当てられており、共有リソース１４０内で少数のアクティブエントリを有するスレッドは、共有リソース１５０内の少ないエントリで効率的に動作することができるので、それらの割り当て制限が低減される。

実施形態によれば、上述した判別は、閾値（例えば、割り当て閾値及びアクティブエントリ閾値）を使用して行われる。特定のスレッドに対し、特定のスレッドに現在割り当てられている共有リソース内のエントリの数が割り当て閾値を上回っており、特定のスレッドに対する共有リソース内のアクティブエントリの数がアクティブエントリ閾値未満である場合、特定のスレッドに対する割り当て制限が低減される。

割り当て閾値は、パフォーマンスモデリングを使用して設計されてもよく、共有リソース内の非常に多くの数のエントリを消費しており、すなわち、共有リソースを独占することによって他のスレッドのパフォーマンスを潜在的に悪化させるスレッドを識別するために選択される。アクティブエントリ閾値は、並列度が低く、したがって、共有リソース内のエントリ数が少なくても効率的に動作する可能性が高いスレッドを識別するために選択される。並列度が低いとは、例えば、スレッドが一連の追加命令を実行している場合に、各命令が前の命令の結果に依存するような場合である。これらの２つの閾値を組み合わせて使用することで、共有リソース内の少なくとも閾値数のエントリを有し且つ並列度が低いスレッドが共有リソース内の多くのエントリを消費して、他のスレッドのパフォーマンスを低下させるのを防止することができる。

（Ｂ．スレッドに対する共有リソース割り当て制限の変更）
図４は、スレッドに対する共有リソースの有用性に基づいて、マルチスレッドマイクロプロセッサ上のスレッドに共有リソースを割り当てることを表すフローチャート４００である。

ステップ４０２では、共有リソースに対する初期割り当て制限は、マルチスレッドマイクロプロセッサ上のスレッドに対して確立される。現在の例では、共有リソース１４０に対する初期割り当て制限は、マルチスレッドマイクロプロセッサ１００上で実行するスレッドＴ０～Ｔ３に対して確立される。

実施形態によれば、初期割り当て制限は、共有リソース内で利用可能なエントリの総数である。例えば、共有リソース１４０が５０個のエントリを有するロードキューであることを想定すると、スレッドＴ０～Ｔ３の各々に対して５０の初期割り当て制限が確立される。全てのスレッドの初期割り当て制限として共有リソース１４０内の利用可能なエントリの総数を割り当てることは、何れかのスレッドが共有リソース１４０内のエントリを大量に消費し、他のスレッドのパフォーマンスを低下させることを潜在的に可能にすることに留意されたい。代わりに、初期割り当て制限は、共有リソース内で利用可能なエントリの総数未満であってもよい。例えば、５０個のエントリを有するロードキューに対し、スレッドＴ０～Ｔ３の各々に対して１０の初期割り当て制限が確立されてもよい。

初期割り当て制限は、スレッド特有であってもよい。例えば、高優先度スレッド（例えば、特殊設計を有するスレッド、又は、特定のサービス品質（ＱＯＳ）要件を満たすことに関与するスレッド）は、低い優先度を有する他のスレッドよりも大きい初期割り当て制限が割り当てられてもよい。先の例では、高優先度スレッドに５０の初期割り当て制限が割り当てられてもよく、他のスレッドに３０の初期割り当て制限が割り当てられる。初期割り当て制限は、共有リソースロジック１５０において事前に構成されてもよいし、共有リソースロジック１５０によって使用される構成データに記憶されてもよいし、オペレーティングシステムを介して構成されてもよい。また、共有リソースロジック１５０は、例えば、電源投入時、又は、オペレーティングシステムコマンド等のコマンドを受信したことに応じて、スレッド割り当て制限を初期割り当て制限にリセットしてもよい。

ステップ４０４では、スレッド毎の割り当てられたエントリの数及びアクティブエントリの数は、クロックサイクルの第１のセットにわたって決定される。例えば、共有リソースロジック１５０は、ＣＣＷ１にわたるスレッドＴ０～Ｔ３に対する割り当てられたエントリの数及びアクティブエントリの数を決定してもよい。図５Ａは、ＣＣＷ１にわたるスレッドＴ０～Ｔ３に対する例示的な使用状況データを表す。この例では、初期割り当て制限は、ＣＣＷ１にわたるスレッドＴ０～Ｔ３に対して５０である。アクティブエントリの数は、ワークを現在行っているエントリの数であり、命令が処理されるにつれてＣＣＷ１の間に変化することがある。したがって、実施形態によれば、アクティブエントリの数は、ＣＣＷ１間の最小数のアクティブエントリである。図５Ａに表す例では、スレッドＴ１は、ＣＣＷ１間の最大数のアクティブエントリを有しており、他のスレッドに対して最高レベルの並列性を示しており、スレッドＴ０は、ＣＣＷ１間の最小数のアクティブエントリを有している。これに対応して、スレッドＴ１は、共有リソース１４０内でより多くのエントリを有することから、スレッドＴ０よりも多くの利益を得る。

ステップ４０６では、第１の／次のスレッドが選択される。本実施例では、スレッドＴ０が選択されるが、評価される第１のスレッドを選択するために任意のアプローチが使用されてもよい。ステップ４０８では、選択されたスレッドに割り当てられたエントリの数が割り当て閾値を越えるかどうかの判別が行われる。例えば、共有リソースロジック１５０は、スレッドＴ０に割り当てられた共有リソース１４０内のエントリの数が割り当て閾値よりも多いかどうかを判別する。割り当て閾値が１０であることを想定すると、スレッドＴ０に割り当てられた１２個のエントリは１０の割り当て閾値よりも多いので、割り当て閾値が満たされ、制御がステップ４１０に進む。これは、スレッドＴ０が、他のスレッドのパフォーマンスを潜在的に低下させるのに十分な共有リソース１４０内の多数のエントリが割り当てられていることを意味する。

ステップ４１０では、スレッドのアクティブエントリの数がアクティブエントリ閾値未満であるかどうかの判別が行われる。上述したように、アクティブエントリ閾値は、並列度が低く、したがって、共有リソースの割り当てが少なくても効率的に動作する可能性が高いスレッドを識別するために使用される。本実施例では、共有リソースロジック１５０は、共有リソース１４０内のスレッドＴ０におけるアクティブエントリの数がアクティブエントリ閾値未満であるかどうかを判別する。アクティブエントリ閾値が３であることを想定すると、スレッドＴ０に対する１つのアクティブエントリは３のアクティブエントリ閾値未満であるため、アクティブエントリ閾値が満たされ、制御がステップ４１２に進む。ステップ４０８及びステップ４１０における両方の閾値を満たすことにより、スレッドＴ０は、他のスレッドのパフォーマンスを潜在的に低下させるのに十分な多数のエントリを共有リソース１４０内に有し、且つ、並列度が低い。したがって、スレッドＴ０は、共有リソース１４０内の少ない数のエントリで効率的に動作することができる。

ステップ４１２では、スレッドが他のスレッドのパフォーマンスを悪化させることを防止するために、共有リソースに対するスレッドの割り当て制限が低減される。本実施例では、共有リソース１４０に対するスレッドＴ０の割り当て制限は、次の時間周期、すなわち、次のクロックサイクルウィンドウＣＣＷ２間に低減される。割り当て制限に対する低減量は、特定の実施形態に応じて変化してもよく、実施形態は、任意の特定の低減方法に限定されない。実施形態によれば、スレッドの割り当て制限は、低減した割り当て制限まで低減される。例えば、共有リソース１４０内のスレッドＴ０に割り当てられたエントリは、５０から１０に低減されてもよい。低減した割り当て制限は、共有リソースロジック１５０において構成されてもよいし、及び／又は、オペレーティングシステムを介して選択可能であってもよい。低減した割り当て制限の値は、モデリングを使用して決定されてもよく、スレッドが他のスレッドのパフォーマンスを低下させることを防止するのに十分に低い値である。

共有リソースに対するスレッドの割り当て制限を、低減した割り当て制限まで低減させる代わりに、スレッドの割り当て制限は、段階的に低減されてもよい。例えば、スレッドＴ０に割り当てられたエントリの数は、５０から４９に１つずつ低減されてもよいし、５０から４０に１０ずつ低減されてもよい。追加の計算的コストのために、より複合的な方法が実施されてもよい。例えば、低減は、アクティブエントリ閾値に対するアクティブエントリのレベルに基づいてもよい。この例では、アクティブエントリ閾値の５０％であるアクティブエントリの数は、スレッドに割り当てられたエントリの数における５０％の低減を結果としてもたらす。実施形態によれば、スレッドの割り当て制限は、そのスレッドに対する有用性メトリックに基づいて低減される。

実施形態によれば、スレッドの割り当て制限を低減させることによって、スレッドが即時にエントリを放棄することを引き起こさない。むしろ、スレッドは、ワークが完了するとエントリを通常通り放棄するが、割り当てられたエントリのスレッドの現在の数が低減した割り当て制限を下回るまで、スレッドは、共有リソース１４０内の追加のエントリが付与されない。先の例では、スレッドＴ０に対して割り当てられた共有リソース１４０内のエントリの数が１０未満になるまで、共有リソース１４０内の追加のエントリがスレッドＴ０に付与されない。

ステップ４０８において、スレッドに割り当てられたエントリの数が割り当て閾値以下である場合、又は、ステップ４１０において、スレッドに対するアクティブエントリの数がアクティブエントリ閾値以上である場合に、制御がステップ４１４に進み、スレッドの割り当て制限がリセット、すなわち、増大する。換言すれば、共有リソース１４０内の少数のエントリがスレッドに割り当てられている場合、そのスレッドは、他のスレッドのパフォーマンスを低下させる脅威にならない。或いは、スレッドが多数のアクティブエントリを有し、並列度が高い場合、そのスレッドは、共有リソース１４０内でより多くのエントリを有することから利益を得ることができ、その割り当て制限が低減されない。実施形態によれば、スレッドの割り当て制限がリセットされると、スレッドの割り当て制限は、初期割り当て制限に変更される。或いは、スレッドの割り当て制限は、特定の量だけ増加（増大）（例えば、１つの増加、又は、５若しくは１０等のより多くの増加）してもよい。この増加は、共有リソースロジック１５０において構成されてもよいし、例えば、オペレーティングシステムを介して選択可能であってもよい。スレッドの割り当て制限も、スレッドに対する有用性メトリックに基づいて増加してもよい。

スレッドの割り当て制限がステップ４１２において低減され、又は、ステップ４１４においてリセット（増大）された後、ステップ４１６では、さらなるスレッドが処理される必要があるかどうかの判別が行われる。そうである場合、制御がステップ４０６に戻り、同じ方法で次のスレッドが選択及び処理される。全てのスレッドの全てが処理されると、ステップ４１８において処理が完了する。この処理は、任意の数のスレッドについて、任意の回数だけ繰り返されてもよい。

実施形態によれば、上述したテスト（試験）は、全てのクロックサイクルの後に実行され、ステップ４１４に到達した場合、スレッドの割り当て制限は、次のＣＣＷのための初期割り当て制限にリセットされる。また、そのスレッドは、現在のＣＣＷ間にもはやテストされない。現在のＣＣＷの間に特定のスレッドに対してステップ４１４に到達しない場合、そのスレッドの割り当て制限は、現在のＣＣＷ及び次のＣＣＷについて低減されたままである。他の例は、ＣＣＷにわたる割り当てられたエントリ及びアクティブエントリの平均数を使用すること、又は、ＣＣＷの終了時に、割り当てられたエントリ及びアクティブエントリの数を使用することを含む。

割り当て制限を低減させるスレッドを識別するために割り当て閾値及びアクティブエントリ閾値の両方を使用することは、マルチスレッドマイクロプロセッサにおいて並列度の低いスレッドが、共有リソースを使用する他のスレッドのパフォーマンスを低下させることをどのように防止するかという技術的問題に対処する。この技術的解決策は、割り当て閾値によって表されるように、共有リソース内の少なくとも閾値数のエントリが現在割り当てられているスレッドを識別し、その結果、このスレッドが、共有リソースを潜在的に「独占」し、他のスレッドが利用可能な共有リソース内のエントリを制限している。次いで、アクティブエントリ閾値に基づいて、識別されたスレッドが共有リソース内で非常に少ないアクティブエントリ、すなわち、ワークを行っているエントリを有するかどうかの判別が行われる。少数のアクティブエントリは、並列度が低く、共有リソース内のエントリ数が少なくてもこのスレッドが効率的に動作し続けることが可能であることを示しているので、このスレッドに対する割り当て制限が低減される。逆に、割り当てられたエントリが少ないスレッドや、多数のアクティブエントリを有するスレッドは、割り当て制限が低減されない。

経時的に、スレッドの実行特性は、例えば、異なる命令のために変わることがある。したがって、スレッドに割り当てられた共有リソース内のエントリの数、及び、そのスレッドに対するアクティブエントリの数も経時的に変わることがある。よって、それらの割り当て制限が当初低減されなかったスレッドは、後のＣＣＷの後にそれらの割り当て制限が低減される可能性がある。

先の例を続けると、図５Ｂは、ＣＣＷ２にわたるスレッドＴ０～Ｔ３に対して取得された例示的な使用状況データを表す。スレッドＴ０に対する割り当て制限は、ＣＣＷ１の後に行われた下方修正後の１０である。それらのスレッドに対する割り当てられたエントリの数の全てが割り当て閾値未満であるので、スレッドＴ１～Ｔ３に対する割り当て制限は、５０の初期割り当て制限までリセットされている。

ＣＣＷ２の後の時間Ｔ２において、上述したテストが再度実行され、スレッドＴ０は、アクティブエントリの数が１から２に僅かに増大したが、割り当て閾値を満たすことと（割り当てられたエントリ＞１０）、アクティブエントリ閾値を満たすことと（アクティブエントリ＜３）の両方を満足するので、スレッドＴ０に対する割り当て制限は１０のままである。しかしながら、スレッドＴ２に割り当てられた１２個のエントリが１０の割り当て閾値よりも多く、２つのアクティブエントリが３のアクティブエントリ閾値未満であるので、スレッドＴ２も両方の閾値を満たす。したがって、スレッドＴ２に対する割り当て制限は、クロックサイクルの次のセット、すなわち、ＣＣＷ３について１０に低減される。スレッドＴ１，Ｔ３の両方に対する割り当て制限は、割り当てられたエントリのそれらの対応する数が割り当て閾値未満であるので、５０の初期割り当て制限にリセットされる。

図５Ｃは、時間Ｔ３におけるＣＣＷ３にわたるスレッドＴ０～Ｔ３に対して取得された例示的な使用状況データを表す。ＣＣＷ３の間、スレッドＴ０に対するＣＣＷ１の後に、スレッドＴ２に対してＣＣＷ２の後に行われた下方修正を理由に、スレッドＴ０，Ｔ２に対する割り当て制限はまだ１０である。ＣＣＷ３では、スレッドＴ０に対して割り当てられたエントリの数は、割り当て閾値を上回ったままであるが、スレッドＴ０に対するアクティブエントリの数は、２から５まで増大している。したがって、スレッドＴ０に対する割り当て制限は、ＣＣＷ４について５０の初期割り当て制限にリセット（増大）される。ＣＣＷ３の間、スレッドＴ２の１２個の割り当てられたエントリは、割り当て閾値を越え続け、スレッドＴ２は、３のアクティブエントリ閾値未満である１つのアクティブエントリのみを有している。したがって、スレッドＴ２は、ＣＣＷ４内に１０の低減した割り当て制限を続ける。スレッドＴ１に対する１１個の割り当てられたエントリが１０の割り当て閾値を超える間、７個のアクティブエントリが３のアクティブエントリ閾値を超えたことを理由に、スレッドＴ１に対する割り当て制限は、５０の初期割り当て制限にリセットされる。６個の割り当てられたエントリが１０の割り当て閾値未満であることを理由に、スレッドＴ３に対する割り当て制限は、５０の初期割り当て制限にリセットされる。よって、スレッドＴ１が共有リソース１４０内のより多くの数のエントリを使用している間、スレッドＴ１は、アクティブエントリ閾値よりも大きいレベルの並列性を有し、したがって、その割り当て制限が低減されない。

図５Ｄは、時間Ｔ４におけるＣＣＷ４にわたるスレッドＴ０～Ｔ３に対して取得された例示的な使用状況データを表す。スレッドＴ０に対して割り当てられたエントリの数は、スレッドＴ０がワークを完了し、共有リソース１４０内のエントリが解放されるにつれて、ＣＣＷ４にわたって１１から８まで減少している。ＣＣＷ４の終わりにおいて、スレッドＴ０に対して割り当てられたエントリの数が割り当て閾値未満であるので、スレッドＴ０に対する割り当て制限は、５０の初期割り当て制限にリセットされる。スレッドＴ１に対して割り当てられたエントリの数は、ＣＣＷ４にわたって増大し続けているが、スレッドＴ１に対する割り当て制限は、アクティブエントリの数がアクティブエントリ閾値を超えるので、初期割り当て制限に再度リセットされる。スレッドＴ２に対して割り当てられたエントリの数は、スレッドＴ２がワークを完了し、共有リソース１４０内のエントリが解放されるにつれて、ＣＣＷ４にわたって１２から１０まで減少している。ＣＣＷ４の終わりにおいて、スレッドＴ２に対して割り当てられたエントリの数が１０の割り当てられた閾値よりもまだ多く、アクティブエントリの数がアクティブエントリ閾値未満であるので、スレッドＴ２に対する割り当て制限は、１０に低減したままである。ＣＣＷ４にわたって、スレッドＴ３に対して割り当てられたエントリの数は、６から１０まで増大しているが、アクティブエントリの数がアクティブエントリ閾値を超えるので、スレッドＴ２に対する割り当て制限は、５０の初期割り当て制限にリセットされる。よって、スレッドＴ１及びスレッドＴ３の両方が共有リソース１４０を独占する潜在性を有する間、それらの両方は、アクティブエントリ閾値を超える数のアクティブエントリを有し、高レベルの並列性を示す。したがって、それらの割り当て制限は、初期割り当て制限にリセットされる。

（Ｃ．有用性メトリック）
本明細書で既に説明したように、有用性メトリックは、スレッドに現在割り当てられているエントリの数に対するアクティブエントリの数のスレッド特有の割合（比率）である。有用性メトリックは、Ｎ個のクロックサイクル毎に、又は、サイクルの周期にわたってクロックサイクル毎に計算されてもよい。例えば、有用性メトリックは、Ｎ個のクロックサイクルにわたる平均有用性メトリックとして計算されてもよい。

有用性メトリックは、スレッドに対する割り当て制限が変更されるべきかどうかを判別するための割り当て閾値及びアクティブエントリ閾値の代替例として使用されてもよい。例えば、図４におけるステップ４０８及びステップ４１０の代わりに、有用性メトリックは、スレッドに対する割り当て制限が変更されるべきかどうかを判別するために、選択されたスレッドに対して計算されてもよいし、有用性閾値と比較されてもよい。このテストは、クロックサイクル毎に、Ｎ個のクロックサイクル毎に、又は、サイクルの周期にわたって実行されてもよいし、個々の有用性メトリック値がテストされてもよいし、Ｎ個の有用性メトリック値の平均が有用性閾値に対してテストされてもよい。実施形態によれば、スレッドの割り当て制限が低減される前のクロックサイクルウィンドウの各クロックサイクルにわたって、スレッドの有用性メトリックがあまり使用されないこと（例えば、有用性閾値を満たさないこと）を示す必要があるウィンドウアプローチが使用されてもよい。或いは、クロックサイクルウィンドウにわたるスレッドの平均有用性メトリックは、有用性閾値と比較されてもよい。

有用性メトリックは、スレッドに対する新たな割り当て制限を決定するために使用されてもよい。実施形態によれば、スレッドに対する割り当てが変更されることが決定されると、割り当て閾値及びアクティブエントリ閾値又は有用性閾値の何れかを使用して、図４のステップ４１２において本明細書で上述したように、低減した割り当て制限まで割り当てを低減させる代わりに、スレッドに対する新たな割り当て制限を決定するために、そのスレッドに対する有用性メトリックが使用される。有用性メトリックは、共有リソースロジック１５０によって実施される数式への入力として使用されてもよく、この数式の出力は、スレッドに対する新たな割り当て制限である。使用される特定の数式によっては、スレッドに対するアクティブエントリの数が増大するにつれて、スレッドに対する割り当て制限が徐々に増大することを可能にすることができ、スレッドがアクティブスレッドのアクティブエントリ閾値数よりも少ないエントリを有することがある場合でさえ、増大した並列性を示す。スレッドに対する新たな割り当て制限を計算するために有用性メトリックを使用することは、上述したような低減した割り当てレベルを使用するよりも多くの柔軟性をもたらすことができるが、より計算量が多く、ゼロ除算の問題が発生する可能性がある。

（Ｄ．リソース割り当て変動の対処）
スレッドの並列性のレベルは、スレッドに対する命令のタイプが変わるにつれて、連続したＣＣＷにわたって著しく変わることがある。本明細書で説明するアプローチを使用すると、スレッドに割り当てられた共有リソース１５０内のエントリの数が、共有リソース内のエントリの総数（例えば、５０）と、低減した割り当てレベル（例えば、１０）との間で変動することがある。

共有リソースのスレッドの割り当てが増大する前に、スレッドが満足するレベルの有用性を証明する必要があるクロックサイクルの数を増大させることによって、スレッドに対するリソース割り当ての変動を低減させる技術が提供される。実施形態によれば、スレッドに対するリソース割り当てを減少させることよりも、スレッドに対するリソース割り当てを増大させるためにより大きなＣＣＷが使用される。例えば、スレッドに対するリソース割り当てを減少させるために、１６のクロックサイクルのＣＣＷが使用されてもよく、スレッドに対するリソース割り当てを増大させるために、３２のＣＣＷ又はより多くのクロックサイクルが使用される。よって、特定のスレッドに割り当てられた共有リソース１５０内のエントリの数は、１６のクロックサイクルのセットの後に低減されることがあるが、特定のスレッドは、共有リソース内のエントリの数が増大するために、より長い期間、すなわち、３２のクロックサイクルにわたって十分に高レベルの並列性を証明する必要がある。或いは、共有リソース割り当てを増大させるためにクロックサイクルのより大きなウインドウを使用する代わりに、共有リソース割り当てを増大させるために、クロックサイクルの複数のウインドウが使用されてもよい。例えば、スレッドに対するリソース割り当てを減少させるために、１６のクロックサイクルのＣＣＷが使用されてもよく、スレッドに対するリソース割り当てを増大させるために、１６のクロックサイクルの２つ以上のＣＣＷが使用される。

別の実施形態によれば、リソース割り当てを増大させるために、異なる閾値が使用される。例えば、スレッドに割り当てられた共有リソース１４０内のエントリの数を増大させるかどうかを考える場合、５の割り当て閾値及び４のアクティブエントリ閾値が図４のステップ４０８及びステップ４１０の各々において使用されてもよい。この例では、スレッドの割り当てが現在低減されていない場合に使用される１０の割り当て閾値と比較して、より低い５の割り当て閾値は、満たすのがより容易である。同様に、スレッドの割り当てが現在低減されていない場合に使用される３のアクティブエントリ閾値と比較して、より高い４のアクティブエントリ閾値は、満たすのがより困難である。よって、より低い割り当て閾値及びより高いアクティブエントリ閾値の組み合わせは、共有リソースの低減した割り当てを有するスレッドが共有リソースの低減した割り当てを有し続ける可能性を増大させる。

本明細書では、実施形態を、単一の共有リソースを有するマルチスレッドマイクロプロセッサの文脈で説明したが、実施形態は、この例に限定されず、任意の数の共有リソースに適用可能である。それらは、複数の共有リソースを管理する共有リソースロジックを有するマルチスレッドマイクロプロセッサ、複数の共有リソースを管理する複数の共有リソースロジックを有するマルチスレッドマイクロプロセッサを含む。

Claims (21)

1. マルチスレッドマイクロプロセッサであって、
   複数のエントリを有する共有リソースと、
   共有リソースロジックと、を備え、
   前記共有リソースロジックは、
   前記共有リソース内の前記複数のエントリから、第１の期間中に複数のスレッドのうち何れかのスレッドに割り当てられるエントリの数と
   前記第１の期間中の前記スレッドに対する前記共有リソース内のアクティブエントリの数と、
   を決定することと、
   前記第１の期間中に前記スレッドに割り当てられる前記エントリの数と、前記第１の期間中の前記スレッドに対する前記共有リソース内の前記アクティブエントリの数と、を使用して、第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を変更することと、
   を行うように構成されている、
   マルチスレッドマイクロプロセッサ。
2. 前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を変更することは、前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる前記割り当て制限を低減することを含む、
   請求項１のマルチスレッドマイクロプロセッサ。
3. 前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限は、増分量だけ、又は、低減した割り当て制限まで低減する、
   請求項２のマルチスレッドマイクロプロセッサ。
4. 前記共有リソースロジックは、前記第１の期間中に前記スレッドに割り当てられた前記エントリの数が第１の閾値を満たすことと、前記第１の期間中の前記スレッドに対する前記共有リソース内の前記アクティブエントリの数が第２の閾値を満たすことと、の両方を判別したことに応じて、前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を低減するように構成されている、
   請求項１のマルチスレッドマイクロプロセッサ。
5. 前記共有リソースロジックは、
   前記スレッドに対する有用性メトリックを決定することであって、前記有用性メトリックは、前記スレッドに割り当てられた前記エントリの数に対する、前記スレッドに対する前記共有リソース内の前記アクティブエントリの数の比率である、ことと、
   前記スレッドに対する前記有用性メトリックを有用性閾値と比較して、前記スレッドに対する前記割り当て制限を変更するかどうかを決定することと、
   を行うように構成されている、
   請求項１のマルチスレッドマイクロプロセッサ。
6. 前記共有リソースロジックは、
   クロックサイクルウィンドウのクロックサイクル毎に、前記スレッドに対する前記有用性メトリックを決定して前記有用性閾値と比較することと、
   前記クロックサイクルウィンドウのクロックサイクル毎に、前記スレッドに対する前記有用性メトリックが前記有用性閾値を満たしていないことに応じて、前記スレッドに対する前記割り当て制限を低減することと、
   を行うように構成されている、
   請求項５のマルチスレッドマイクロプロセッサ。
7. 前記共有リソースロジックは、前記スレッドに対する前記有用性メトリックに基づいて、前記スレッドに対する前記割り当て制限を変更するように構成されている、
   請求項５のマルチスレッドマイクロプロセッサ。
8. 前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を変更することは、前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を増大させることを含む、
   請求項１のマルチスレッドマイクロプロセッサ。
9. 前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を増大させることは、前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を、前記共有リソース内の利用可能なエントリの総数まで増大させることを含む、
   請求項８のマルチスレッドマイクロプロセッサ。
10. 前記共有リソースロジックは、
    前記第１の期間中に前記スレッドに割り当てられた前記エントリの数が第１の閾値を満たさないこと、又は、前記第１の期間中の前記スレッドに対する前記共有リソース内の前記アクティブエントリの数が第２の閾値を満たさないこと、の何れかを判別したことに応じて、前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を増大させるように構成されている、
    請求項１のマルチスレッドマイクロプロセッサ。
11. 前記第１の閾値の値及び前記第２の閾値の値は、前記スレッドの期間に割り当てられた前記共有リソース内の前記エントリの数に基づいて選択される、
    請求項１０のマルチスレッドマイクロプロセッサ。
12. 前記共有リソースロジックは、
    前記複数の期間において前記スレッドに割り当てられた前記エントリの数が第１の閾値を満たさないこと、又は、前記複数の期間における前記スレッドに対する前記共有リソース内の前記アクティブエントリの数が第２の閾値を満たさないこと、の何れかを判別したことに応じて、前記共有リソースについて前記スレッドに割り当てられる割り当て制限を増大させるように構成されている、
    請求項１のマルチスレッドマイクロプロセッサ。
13. 前記第１の期間中の前記スレッドに対する前記共有リソース内の前記アクティブエントリの数は、前記第１の期間中の前記スレッドに対する前記共有リソース内のアクティブエントリの最小数である、
    請求項１のマルチスレッドマイクロプロセッサ。
14. 前記第１の期間の前に、前記スレッドには、前記共有リソース内で利用可能な前記共有リソース内のエントリの総数である割り当て制限が割り当てられる、
    請求項１のマルチスレッドマイクロプロセッサ。
15. 前記共有リソースは、ロードキュー、レジスタファイル、又は、リザベーションステーションのうち１つ以上である、
    請求項１のマルチスレッドマイクロプロセッサ。
16. 前記第１の期間は第１のクロックサイクルウィンドウであり、前記第２の期間は第２のクロックサイクルウィンドウである、
    請求項１のマルチスレッドマイクロプロセッサ。
17. コンピュータが実行する方法であって、
    マルチスレッドマイクロプロセッサ内の共有リソースロジックが、
    共有リソース内の複数のエントリから、第１の期間中に複数のスレッドのうち何れかのスレッドに割り当てられるエントリの数と
    前記第１の期間中の前記スレッドに対する前記共有リソース内のアクティブエントリの数と、
    を決定することと、
    前記第１の期間中に前記スレッドに割り当てられる前記エントリの数と、前記第１の期間中の前記スレッドに対する前記共有リソース内の前記アクティブエントリの数と、を使用して、第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を変更することと、を含む、
    方法。
18. 前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を変更することは、前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる前記割り当て制限を低減することを含む、
    請求項１７の方法。
19. 前記共有リソースロジックが、前記第１の期間中に前記スレッドに割り当てられた前記エントリの数が第１の閾値を満たすことと、前記第１の期間中の前記スレッドに対する前記共有リソース内の前記アクティブエントリの数が第２の閾値を満たすことと、の両方を判別したことに応じて、前記第２の期間に関して前記共有リソースについて前記スレッドに割り当てられる割り当て制限を低減することを含む、
    請求項１８の方法。
20. 前記スレッドに対する有用性メトリックを決定することであって、前記有用性メトリックは、前記スレッドに割り当てられた前記エントリの数に対する、前記スレッドに対する前記共有リソース内の前記アクティブエントリの数の比率である、ことと、
    前記スレッドに対する前記有用性メトリックを有用性閾値と比較して、前記スレッドに対する前記割り当て制限を変更するかどうかを決定することと、を含む、
    請求項１７の方法。
21. マルチスレッドシステムであって、
    複数のエントリを有する共有リソースと、
    共有リソース割り当てロジックと、を備え、
    前記共有リソース割り当てロジックは、
    前記マルチスレッドシステムで実行するスレッドに割り当て制限を割り当てることであって、前記割り当て制限は、前記スレッドに割り当てられた以前の割り当て制限と、前記スレッドの前記共有リソース内の以前のアクティブエントリの数と、に基づいて決定される、ことを行うように構成されている、
    マルチスレッドシステム。

Images