以下に、本願の開示する演算処理装置及び演算処理装置の制御方法の実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する演算処理装置及び演算処理装置の制御方法が限定されるものではない。
図1は、実施例に係るCPUのブロック図である。演算処理装置であるCPU1は、命令をデコードして演算処理リクエストを発行する命令制御部(不図示)、演算処理回路(不図示)、L1命令キャッシュ21及びL1データキャッシュ22を有するコア20を複数有する。このコア20が、「演算処理部」の一例にあたる。L1命令キャッシュ21及びL1データキャッシュ22は、図1では、それぞれL1I及びL1Dと表した。コア20は、演算処理を実行する。
さらに、CPU1は、複数のコア20が複数のクラスタ10~13に分けられる。各クラスタ10~13は、それぞれに対応して設けられた複数の最上位レベルキャッシュ(LLC)100を有する。このクラスタ10~13が、「演算処理グループ」の一例にあたる。クラスタ10~13は、いずれも同じ機能を有するので、以下では、クラスタ10を例に説明する。
クラスタ10に属する複数のコア20は、クラスタ10に属するLLC100を共有される。すなわち、クラスタ10は、複数のコア20及びそれらが共有する1つのLLC100をひとまとまりとした演算処理ブロックである。
LLC100は、タグ記憶部101、データ記憶部102、管理表格納部103、制御パイプライン104、リクエスト受信部105、処理順調整部106、ローカルオーダー制御部107、ミスアクセス制御部108及びプライオリティ制御部109を有する。LLC100は、MAC(Memory Access Controller)30に接続される。
LLC100は、リクエストにより要求されたデータについてのキャッシュミスが発生した場合、MAC30にデータの取得を依頼する。その後、LLC100は、メモリ40からMAC30が読み出したデータを取得する。LLC100は、MAC30を介して接続するメモリ40に格納されたデータに対して「ホーム」のLLC100と呼ばれる場合がある。
タグ記憶部101は、有効ビット、アドレス及び状態などのタグデータを格納する。データ記憶部102は、タグデータで示されたアドレスにデータを格納する。
管理表格納部103は、LLC100がホームとなるメモリ40に格納されたデータの現在の位置を表す管理表を格納する。言い換えれば、管理表格納部103は、クラスタ10~13の間のデータの持ち出し状態を記録するためのディレクトリ資源を格納する。このディレクトリ資源は、キャッシュコヒーレンシ制御に用いられる。
リクエスト受信部105は、各コア20から出力されたローカルリクエストを受信するポートを有する。また、リクエスト受信部105は、クラスタ10のLLC100がホームの場合、他のクラスタ11~13のLLC100の制御パイプライン104から自己が管理するデータの送信を要求する外部リクエストを受信するポートを有する。また、リクエスト受信部105は、クラスタ10のLLC100が他のクラスタ11~13がホームとなるデータを保持する場合、そのデータの他のクラスタ11~13へのオーダーと呼ばれる転送要求を、そのデータのホームとなるクラスタから受信するポートを有する。この外部リクエスト及びオーダーが、「他グループリクエスト」の一例にあたる。
リクエスト受信部105は、ローカルリクエスト、外部リクエスト及びオーダーを受け付ける。そして、リクエスト受信部105は、ローカルリクエスト、外部リクエスト及びオーダーを保持しつつ、プライオリティ制御部109へそれぞれを出力する。その後、リクエスト受信部105は、ローカルリクエスト、外部リクエスト又はオーダーに対する完了応答を受けた場合、保持する情報を破棄する。
プライオリティ制御部109は、ローカルリクエスト、外部リクエスト及びオーダーをリクエスト受信部105から複数取得した場合、いずれか一つを処理対象として選択する。以下では、ローカルリクエスト、外部リクエスト及びオーダーのそれぞれを区別しない場合、単に「リクエスト」と呼ぶ。プライオリティ制御部109は、選択したリクエストを制御パイプライン104へ投入する。
制御パイプライン104は、プライオリティ制御部109から投入されたリクエストをパイプライン処理する。パイプライン処理は、処理段階が複数に分かれており、それぞれの処理段階がステージと呼ばれる場合がある。例えば、制御パイプライン104は、ステージ0~nのパイプライン処理を行う。その場合、ステージ0の処理が、リクエストが投入された時点の処理である。そして、ステージnの処理が、パイプライン処理が完了し処理応答を出力する時点の処理である。
例えば、制御パイプライン104は、投入されたリクエストがローカルリクエストの場合、クラスタ10のLLC100は、ミスアクセス制御部108及びローカルオーダー制御部107へアドレスを通知しアボート判定を行わせる。
また、制御パイプライン104は、ミスアクセス制御部108によるアボート判定と並行して、タグ記憶部101を検索する。ローカルリクエストにマッチするタグデータがタグ記憶部101に存在する場合、制御パイプライン104は、キャッシュヒットと判定する。そして、制御パイプライン104は、そのタグデータにより示されるデータをデータ記憶部102から取得する。その後、制御パイプライン104は、取得したデータをローカルリクエストの送信元へ出力する。また、制御パイプライン104は、ローカルリクエストの処理完了をリクエスト受信部105に通知する。
一方、ミスアクセス制御部108又はローカルオーダー制御部107からアボート処理の指示を受けた場合、制御パイプライン104は、投入されたローカルリクエストを破棄して、アボート通知をリクエスト受信部105へ出力する。これに対して、管理表格納部103を確認してデータがクラスタ10のLLC100に存在しないと判定した場合、制御パイプライン104は、その時点でデータを有するクラスタ11~13を管理表格納部103から取得し、取得したクラスタに対してオーダーを送信する。
これに対して、ローカルリクエストにマッチするタグデータがタグ記憶部101に存在しない場合、制御パイプライン104は、キャッシュミスと判定する。そして、制御パイプライン104は、ミスアクセス制御部108にアドレスを格納させるとともに、データの取得要求をMAC30へ出力する。その後、制御パイプライン104は、MAC30からデータを取得すると、取得したデータをデータ記憶部102に格納させ、タグ記憶部101に格納したデータを指すタグデータを格納させる。さらに、制御パイプライン104は、取得したデータをローカルリクエストの送信元へ出力する。また、制御パイプライン104は、ローカルリクエストの処理完了をリクエスト受信部105に通知する。
一方、リクエストが示すデータが、クラスタ10のLLC100がホームとなるデータでない場合、制御パイプライン104は、そのデータのホームであるクラスタ11~13に対する外部リクエストをオンチップネットワーク7を介して送信する。その後、制御パイプライン104は、外部リクエストの送信先からデータの入力をオンチップネットワーク7を介して受ける。そして、制御パイプライン104は、処理完了をリクエスト受信部105へ通知する。
また、投入されたリクエストが外部リクエストの場合、制御パイプライン104は、リクエストの送信元を他のクラスタ11~13として、ローカルリクエストと同様の処理を行う。この場合、制御パイプライン104は、取得したデータをリクエストコンプリートと呼ばれる応答を用いてリクエストの送信元のクラスタ11~13へ送信する。この時、制御パイプライン104は、管理表格納部103に格納された管理表にデータの移動先を登録して、管理表を更新する。
また、投入されたリクエストがオーダーの場合、制御パイプライン104は、ローカルオーダー制御部107にアドレスを通知してアボート判定を行わせる。ローカルオーダー制御部107からアボート処理の指示を受けた場合、制御パイプライン104は、投入されたオーダーを破棄して、アボート通知をリクエスト受信部105へ出力する。これに対して、ローカルオーダー制御部107からアボート処理の指示を受けない場合、制御パイプライン104は、自己が有するデータをオーダーで指定された他のクラスタ11~13へオンチップネットワーク7を介して送信する。その後、制御パイプライン104は、処理完了をリクエスト受信部105へ通知する。
また、リクエストがインターコネクトコントローラ5を介して他のCPU1へ送信される命令やPCIeインタフェース6を介してPCIeバス60へ送信される命令の場合、制御パイプライン104は、リクエストをオンチップネットワーク7へ送出する。ただし、このリクエストのCPU1への送信は、実際には、メモリ40に対して直接データの読み書きを行うDMA(Direct Memory Access)転送によりリクエストを送信する。
この場合、制御パイプライン104は、リクエストをパケット化してオンチップネットワーク7へ発行する。リクエストがインターコネクトコントローラ5を介して他のCPU1へ送信される命令やPCIeインタフェース6を介してPCIeバス60へ送信される命令は、CPU1の動作クロックに対する遅延がそれほど大きくはない。また、これらの命令は、キャッシュには格納されないノンキャッシャブル(NC:Non Cachable)リクエストである。以下では、リクエストがインターコネクトコントローラ5を介して他のCPU1へ送信される命令やPCIeインタフェース6を介してPCIeバス60へ送信される命令を、「通常NCリクエスト」という。インターコネクトコントローラ5やPCIeインタフェース6が有する通常NCリクエスト用のバッファが一杯になった場合、制御パイプライン104は、その後の通常NCリクエストに対して、バッファが空くまでアボート処理を行う。
また、リクエストがオフチップコントローラ80へ送信される命令の場合、制御パイプライン104は、リクエストをオンチップネットワーク7及びチップセットIF(Interface)8を介して、オフチップコントローラ80へ送出する。チップセットIF8からオフチップコントローラ80へ繋がるバスはCPU1の動作クロックに対して非常に低速である。また、この命令は、キャッシュには格納されないノンキャッシャブルリクエストである。以下では、リクエストがオフチップコントローラ80へ送信される命令を、「低速NCリクエスト」という。低速NCリクエストは、例えば、ファームやセキュリティメモリに対する命令である。後述するオンチップIF8が有する低速NCリクエスト用のバッファが一杯になった場合、制御パイプライン104は、その後の低速NCリクエストに対して、バッファが空くまでアボート処理を行う。この通常NCリクエスト及び低速NCリクエストが、「制御パイプラインを経由して他の処理機構に転送され、他の処理機構で処理される要求」の一例にあたる。
また、制御パイプライン104は、投入されたリクエストに対する強制アボートの指示を処理順調整部106から受けた場合、リクエストの状態に関わらずリクエストを破棄して、アボート通知をリクエスト受信部105へ出力する。
また、リクエストがストアリクエストの場合、制御パイプライン104は、MAC30に対してデータの格納要求を送信する。次に、制御パイプライン104は、データのストが完了するまで、リクエストで指定されたアドレスを保持する。そして、制御パイプライン104は、同一アドレスに対するストアリクエストに対してアボート処理を行う。制御パイプライン104は、データ格納完了の通知をMAC30から受けて、保持するアドレスを開放する。
ローカルオーダー制御部107は、コア20が出力したリクエストやLLC100の配下のコア20に対する外部リクエストやオーダーをきっかけとして発生したリクエストに対するオーダー処理発行済みアドレスを保持する。ローカルオーダー制御部107は、コア20から出力された新規リクエストや外部リクエストやオーダーの指定するアドレスが、保持するアドレスにマッチした場合、制御パイプライン104にそのリクエストのアボート処理を行わせる。
ミスアクセス制御部108は、キャッシュミスのアドレスを保持する。ミスアクセス制御部108は、コア20から出力されたリクエストが保持するアドレスにマッチした場合、制御パイプライン104にそのリクエストのアボート処理を行わせる。制御パイプライン104がMAC30からキャッシュミスしたデータを取得した場合、ミスアクセス制御部108は、制御パイプライン104からの通知を受けて保持するアドレスを開放する。
処理順調整部106は、制御パイプラインに投入されたリクエストの情報の入力を受ける。そして、処理順調整部106は、投入されたリクエストについてアボート判定を行う。リクエストをアボートさせると判定した場合、処理順調整部106は、強制アボートの指示を制御パイプライン104へ出力する。処理順調整部106によるアボート判定については後で詳細に説明する。
MAC30~33は、制御パイプライン104からデータの取得要求を受けて、指定されたデータをメモリ40~43から読み出す。そして、MAC30~33は、読み出したデータを制御パイプライン104へ送信する。
MAC30~33は、制御パイプライン104からデータの格納要求を受けて、メモリ40~43の指定されたアドレスにデータを格納する。格納が完了すると、MAC30~33は、データの格納完了の通知を制御パイプライン104へ出力する。
オンチップネットワーク7は、クラスタ10~13のLLC100、インターコネクトコントローラ5、PCIeインタフェース6及びチップセットIF8が接続される。オンチップネットワーク7は、複数のメッセージクラスにより分類されるバーチャルチャネル(VC:Virtual Channel)を有する。バーチャルチャネルには、例えば、外部リクエストVC、オーダーVC、リクエストコンプリートVC、オーダーコンプリートVC、通常NCリクエストVC及び低速NCリクエストVCなどが存在する。通常NCリクエストVC及び低速NCリクエストVCは、いずれもノンキャッシャブルアクセス用のバーチャルチャネルである。低速NCリクエストVCは、オフチップの低速バスであるチップセットIF8宛てのリクエスト用のバーチャルチャネルであり、それ以外のメモリマップドレジスタは通常NCリクエストVCを使って転送される。これにより、低速NCリクエストVCが低速バスに降り滞留しても、通常NCリクエストVCは分離されているため制御パイプライン104は新たなリクエストが通常NCリクエストVCへ発行可能である。オンチップネットワーク7の内部には、バーチャルチャネル毎のバッファが存在し、その資源数管理をリクエストの発行側である制御パイプライン104が行う。
図2は、LLCの一例の回路図である。LLC100は、図2に示すように、ローカルリクエストポート111~113、外部リクエストポート121、オーダーポート122及びMIB(Move In Buffer)ポート123を有する。さらに、LLC100は、プライオリティ回路131、キャッシュ制御パイプライン132、タグRAM(Random Access Memory)133、データRAM134、オーダロック回路135、ストアロック回路137及び持出管理表138を有する。
ローカルリクエストポート111~113、外部リクエストポート121、オーダーポート122及びMIBポート123は、図1に示すリクエスト受信部105の機能を実現する。このローカルリクエストポート111~113、外部リクエストポート121及びオーダーポート122が、「リクエストポート」の一例にあたる。
ローカルリクエストポート111~113は、それぞれ異なるコア20に接続される。ローカルリクエストポート111~113は、ローカルリクエストの入力を受けるポートである。以下では、ローカルリクエストポート111~113を区別しない場合、ローカルリクエストポート110という。
外部リクエストポート121及びオーダーポート122は、オンチップネットワーク7を介して他のクラスタ11~13に接続される。ただし、図2ではオンチップネットワーク7を省略した。外部リクエストポート121は、他のクラスタ11~13から送信された外部リクエストの入力を受けるポートである。オーダーポート122は、他のクラスタ11~13から送信されたオーダーリクエストの入力を受けるポートである。
MIBポート123は、MAC30に接続される。MIBポート123は、MAC30からメモリ40から読み出されたデータの入力を受けるポートである。
プライオリティ回路131は、図1に例示したプライオリティ制御部109の機能を実現する。プライオリティ回路131は、ローカルリクエストポート111~113、外部リクエストポート121、オーダーポート122及びMIBポート123から入力されたリクエストの中から1つのリクエストを選択してキャッシュ制御パイプライン132へ投入する。
キャッシュ制御パイプライン132は、図1に例示した制御パイプライン104の機能を実現する。キャッシュ制御パイプライン132は、ステージ0~nのステージ0のパイプライン処理を実行する。キャッシュ制御パイプライン132は、ステージ0においてプライオリティ回路131から投入されたリクエストを、タグRAM133、データRAM134、オーダロック回路135、MIB回路136、ストアロック回路137及び持出管理回路138を用いてパイプライン処理する。また、キャッシュ制御パイプライン132は、ステージnにおいて処理が完了したリクエストの処理応答を処理順調整回路200及びリクエストの送信元のリクエストポートへ通知する。また、キャッシュ制御パイプライン132は、処理順調整回路200からの強制アボートの指示を受けて、投入されたリクエストに対してアボート処理を行う。このアボート処理が「終了処理」の一例にあたる。ここでは、キャッシュ制御パイプライン132によるパイプライン処理が、0~nステップまでの段階で処理される場合で説明する。このキャッシュ制御パイプライン132が、「制御パイプライン」の一例にあたる。
タグRAM133は、図1に例示したタグ記憶部101の機能を実現する。また、データRAM134は、図1に例示したデータ記憶部102の機能を実現する。タグRAM133は、データRAM134のキャッシュラインに関するタグデータを格納する。
オーダロック回路135は、図1に例示したローカルオーダー制御部107の機能を実現する。オーダロック回路135は、コア20に対してのオーダー処理発行済みアドレスを記録するロック資源である。オーダロック回路135は、新規リクエストが保持するアドレスにマッチした場合は、オーダー処理が完了するまでそのアドレスに対するオーダーをアボートさせる。
MIB回路136は、図1に例示したミスアクセス制御部108の機能を実現する。MIB回路136は、キャッシュミスアドレスを保持する。そして、MIB回路136は、リクエストが指定するアドレスが保持するとマッチした場合、そのリクエストが要求するデータのメモリ40への取得を行う先行リクエストが存在することを示すので、そのリクエストをアボートさせる。
ストアロック回路137は、MAC30に対してストアリクエストを発行したアドレスを記録するロック資源である。ストアロック回路137は、ストア順序が確定した通知をMAC30から受けるまで同一アドレスの後続のストアリクエストをアボートさせる。
持出管理回路138は、図1に例示した管理表格納部103の機能を実現する。持出管理回路138は、クラスタ間のキャッシュコヒーレンシ制御に用いられる。
処理順調整回路200は、処理順調整部106の機能を実現する。図3は、処理順調整回路のブロック図である。処理順調整回路200は、図3に示すように、全体動作管理部201、モード管理部202、対象アドレス保持部203、待ちリクエスト管理部204及びアドレスマッチ判定部205を有する。さらに、処理順調整回路200は、パイプライン制御部206、外部リクエストポート管理部207、オーダーポート管理部208及びアボートカウンタ209を有する。
また、図4は、処理順調整回路の保持情報をまとめた図である。処理順調整回路200は、全体動作情報301、モード識別情報302、アドレスマッチ有効状態情報303、アボートカウンタ209、待ちリクエストリスト305及び対象アドレス情報306を有する。
全体動作情報301は、処理順調整回路200がリクエストの処理順の監視を行っているか否かを示す全体有効フラグを表す情報である。全体有効フラグは、フラグが立っていれば処理順調整回路200がリクエストの処理順の監視を行っていることを表し、フラグが立っていなければ処理順調整回路200がリクエストの処理順の監視を行っていないことを表す。全体動作情報301は、例えば、全体動作管理部201により保持される。
モード識別情報302は、アドレス競合モード、通常資源競合モード及び低速資源競合モードという3つの監視モードのいずれで処理順調整回路200が動作中かを表す情報である。アドレス競合モードとは、ローカルリクエスト、外部リクエスト及びオーダーの競合を監視するモードである。通常資源競合モードは、通常NCリクエストの競合を監視するモードである。低速資源競合モードは、低速NCリクエストの競合を監視するモードである。モード識別情報302は、例えば、モード管理部202により保持される。
アドレスマッチ有効状態情報303は、リクエストで指定されたデータに対してLLC100がホームの場合、外部リクエストの監視が有効であるか無効であるかを示す外部リクエスト有効フラグを表す情報である。外部リクエスト有効フラグが立っていれば、外部リクエストの監視が有効である。リクエストで指定されたデータに対してLLC100がホームの場合、アドレスマッチ有効状態情報303は、外部リクエストポート管理部207により保持される。
また、リクエストで指定されたデータに対してLLC100がホームでない場合、アドレスマッチ有効状態情報303は、オーダーの監視が有効であるか無効であるかを示すオーダー有効フラグを表す情報である。オーダー有効フラグが立っていれば、オーダーの監視が有効である。リクエストで指定されたデータに対してLLC100がホームでない場合、アドレスマッチ有効状態情報303は、オーダーポート管理部208により保持される。
アボートカウンタ209は、オーダーのアボート回数を表すカウンタ値を保持する。
待ちリクエストリスト305は、コア20毎に、ウェイトビット、完了ビット及びエントリID(Identifier)が登録される。ウェイトビットは、待ちリクエストであるローカルリクエストが存在するか否かを表す。完了ビットは、待ちリクエストとなったローカルリクエストの処理が完了したか否かを表す。エントリIDは、コア20に対応するローカルリクエストポート110の資源のエントリ番号を表す。例えば、ローカルリクエストポート110が4エントリを有する場合、エントリIDは、2ビットの情報となる。図4では、クラスタ10が有するコア20をそれぞれコア#00~#xxと表した。ここでは、ウェイトビットが1の場合、そのコア20のエントリIDから発行されたリクエストが待ちリクエストとなったことを表す。これに対して、ウェイトビットが0の場合、そのコア20から出力されたリクエストに待ちリクエストが存在しないことを表す。
また、待ちリクエストリスト305は、クラスタ11~13に対応させて、ウェイトビット、完了ビット及びエントリIDが登録される。例えば、外部リクエストポート121が8エントリを有する場合、エントリIDは、3ビットの情報となる。また、待ちリクエストリスト305は、オーダーポート122に対応させて、ウェイトビット及びエントリIDが登録される。待ちリクエストリスト305は、例えば、待ちリクエスト管理部204により保持される。
対象アドレス情報306は、ローカルリクエスト、外部リクエスト及びオーダーの競合を監視する場合の、監視対象とするアドレス値である。対象アドレス情報306は、例えば、対象アドレス保持部203により保持される。
以下に、図3及び4を参照して、処理順調整回路200の詳細について説明する。この処理順調整回路200が、「順序調整部」の一例にあたる。
全体動作管理部201は、パイプライン処理のステージ0においてキャッシュ制御パイプライン132に投入されたリクエストの情報をプライオリティ回路131から取得する。リクエストの情報には、リクエストの種別、アドレス、送信元の情報などが含まれる。次に、全体動作管理部201は、全体動作情報301が表す全体有効フラグを確認して、リクエストの処理順の監視が実行中か否かを判定する。
監視が実行中でない場合、全体動作管理部201は、モード管理部202及び待ちリクエスト管理部024にリクエストの情報を送るとともに初回登録の実行を指示する。その後、投入されたリクエストが監視対象となる場合、全体動作管理部201は、監視開始の通知をモード管理部202から受ける。そして、全体動作管理部201は、全体動作情報301が表す全体有効フラグを監視実行中に変更し、監視動作を開始する。投入されたリクエストが監視対象とならない場合、全体動作管理部201は、監視動作を行わずに処理を終了する。
これに対して、監視が実行中の場合、全体動作管理部201は、モード管理部202及び待ちリクエスト管理部024にリクエストの情報を送るとともに後続リクエスト処理の実行を指示する。ここで、後続リクエストとは、既にパイプラインに投入されたリクエストと競合する後発のリクエストを指す。
その後、全体動作管理部201は、監視の終了の通知を待ちリクエスト管理部204から受ける。そして、全体動作管理部201は、全体動作情報301における全体有効フラグを監視動作無効を表す状態に変更して監視動作を終了する。
モード管理部202は、初回登録の実行の指示を全体動作管理部201から受ける。さらに、モード管理部202は、リクエストの情報を全体動作管理部201から取得する。そして、モード管理部202は、取得したリクエストの情報からリクエスト種別を判定する。
次に、モード管理部202は、リクエスト種別から、取得したリクエストに対する監視モードがアドレス競合モード、通常資源競合モード又は低速資源競合モードのいずれかを判定する。具体的には、モード管理部202は、リクエスト種別がローカルリクエストの場合にアドレス競合モードによる監視を実行すると判定する。また、リクエスト種別がNC通常リクエストの場合、モード管理部202は、通常資源競合モードによる監視を実行すると判定する。また、リクエスト種別がNC低速リクエストの場合、モード管理部202は、低速資源競合モードによる監視を実行すると判定する。
アドレス競合モードで動作する場合、モード管理部202は、モード識別情報302をアドレス競合モードに設定する。次に、モード管理部202は、監視開始を全体動作管理部201に通知する。次に、モード管理部202は、アドレス競合モードによる監視開始の指示を待ちリクエスト管理部204に通知する。さらに、モード管理部202は、リクエストの情報に含まれるアドレスを対象アドレス保持部203に通知する。
通常資源競合モードで動作する場合、モード管理部202は、モード識別情報302を通常資源競合モードに設定する。次に、モード管理部202は、監視開始を全体動作管理部201に通知する。さらに、モード管理部202は、通常資源競合モードによる監視開始の指示を待ちリクエスト管理部204に通知する。
低速資源競合モードで動作する場合、モード管理部202は、モード識別情報302を低速資源競合モードに設定する。次に、モード管理部202は、低速資源競合モードによる監視開始を全体動作管理部201に通知する。さらに、モード管理部202は、低速資源競合モードによる監視開始の指示を待ちリクエスト管理部204に通知する。
これに対して、投入されたリクエストが監視対象とならない場合、モード管理部202は、監視を行わないと判定する。リクエストが、アドレス競合モード、通常資源競合モード及び低速資源競合モードという3つの監視モードのいずれの対象にも当たらない場合とは、例えば、リクエストがシステムレジスタアクセスなどの場合である。その後、モード管理部202は、全体動作管理部201に監視動作の停止を指示し、登録処理を終了する。
監視が実行中の場合、モード管理部202は、後続リクエスト処理の実行の指示を全体動作管理部201から受ける。さらに、モード管理部202は、キャッシュ制御パイプライン132に投入されたリクエストの情報を全体動作管理部201から取得する。そして、モード管理部202は、取得したリクエストの情報からリクエスト種別を判定する。また、モード管理部202は、モード識別情報302を確認し、現在の監視モードを特定する。
次に、モード管理部202は、投入されたリクエストが動作中の監視モードの監視対象にあたるか否か判定する。投入されたリクエストが動作中の監視モードの監視対象にあたらない場合、モード管理部202は、待ちリクエスト管理部204及びパイプライン制御部206に対して、アボート指示を送らずにリクエストをキャッシュ制御パイプライン132へ投入させる処理を実行させる。
監視モードがアドレス競合モードであり且つリクエストが監視対象の場合、モード管理部202は、リクエストの情報とともにアドレスの確認依頼をアドレスマッチ判定部205へ出力する。また、監視モードが通常資源競合モードで且つリクエストが監視対象の場合、モード管理部202は、NC通常リクエストについての待ちリクエストの判定依頼を待ちリクエスト管理部204へ出力する。また、監視モードが低速資源競合モードで且つリクエストが監視対象の場合、モード管理部202は、NC低速リクエストについての待ちリクエストの判定依頼を待ちリクエスト管理部204へ出力する。
対象アドレス保持部203は、モード管理部202から通知されたキャッシャブルリクエストによる要求の対象となるアドレスを記憶して保持する。
監視モードがアドレス競合モードであり且つリクエストが監視対象の場合、アドレスマッチ判定部205は、リクエストの情報とともにアドレスの確認依頼の入力をモード管理部202から受ける。次に、アドレスマッチ判定部205は、リクエストの情報からリクエストが指定するアドレスを取得する。そして、アドレスマッチ判定部205は、対象アドレス情報306から監視対象のアドレスを取得し、リクエストが指定するアドレスと一致するか否かを判定する。アドレスが一致しなければ、アドレスマッチ判定部205は、アドレスの不一致を待ちリクエスト管理部204へ出力する。アドレスが一致した場合、アドレスマッチ判定部205は、リクエストの情報とともに待ちリクエストの判定依頼を待ちリクエスト管理部204へ出力する。
初回登録処理の場合、待ちリクエスト管理部204は、監視モードの情報とともに監視開始の指示をモード管理部202から受ける。また、また、待ちリクエスト管理部204は、リクエストの情報の入力を全体動作管理部201から受ける。
投入されたリクエストがキャッシャブルリクエストであれば、待ちリクエスト管理部204は、アドレス競合モードによる監視開始時の指示をモード管理部202から受ける。次に、待ちリクエスト管理部204は、全体動作管理部201から取得したリクエストの情報から送信元のコア20及びエントリIDを取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305の取得したコア20に対応する欄のウェイトビットを1にし、且つ、エントリIDを表す値を登録して待ちリクエスト情報を追加する。
次に、待ちリクエスト管理部204は、リクエストが要求するデータのホームはクラスタ10か否かを判定する。クラスタ10がホームでない場合、待ちリクエスト管理部204は、アドレスマッチ有効状態情報303におけるオーダー有効フラグの設定処理の実行をオーダーポート管理部208に指示する。これに対して、クラスタ10がホームの場合、待ちリクエスト管理部204は、外部リクエスト有効フラグの設定処理の実行を外部リクエストポート管理部207に指示するとともにリクエストの情報を送信する。
リクエストがNC通常リクエストであれば、待ちリクエスト管理部204は、通常資源競合モードによる監視開始の指示をモード管理部202から受ける。次に、待ちリクエスト管理部204は、全体動作管理部201から取得したリクエストの情報から送信元のコア20の情報及びエントリIDを取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305の取得したコア20に対応する欄のウェイトビットを1にし、且つ、エントリIDを表す値を登録して待ちリクエスト情報を追加する。
リクエストがNC低速リクエストであれば、待ちリクエスト管理部204は、低速資源競合モードによる監視開始の指示をモード管理部202から受ける。次に、待ちリクエスト管理部204は、全体動作管理部201から取得したリクエストの情報から送信元のコア20の情報及びエントリIDを取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305の取得したコア20に対応する欄のウェイトビットを1にし、且つ、エントリIDを表す値を登録して待ちリクエスト情報を追加する。
後続リクエスト処理の場合、待ちリクエスト管理部204は、以下の処理を実行する。監視モードがアドレス競合モードで且つリクエストが監視対象であって、リクエストが指定したアドレスが対象アドレス情報306に一致すると、待ちリクエスト管理部204は、待ちリクエストの判定依頼をアドレスマッチ判定部205から受ける。さらに、待ちリクエスト管理部204は、リクエストの情報の入力をアドレスマッチ判定部205から受ける。次に、待ちリクエスト管理部204は、リクエストの情報を用いて、リクエストがローカルリクエスト、外部リクエスト又はオーダーのいずれであるかを判定する。
リクエストがローカルリクエストの場合、待ちリクエスト管理部204は、アドレスマッチ有効状態情報303を用いて外部リクエスト監視が有効か否かを判定する。外部リクエスト監視が無効であれば、待ちリクエスト管理部204は、外部リクエスト監視開始の判定処理の実行を外部リクエストポート管理部207に指示する。
次に、待ちリクエスト管理部204は、リクエストの情報から送信元のコア20の情報を取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のコア20の欄における完了ビットの値を確認する。そして、待ちリクエスト管理部204は、そのコア20から出力されたリクエストと同じアドレスに対するローカルリクエストが要求した処理が完了済みか否かを判定する。以下では、リクエストが要求した処理が完了したことを、「要求処理の完了」という。この要求処理が完了したリクエストが「完了リクエスト」の一例にあたる。
要求処理が完了済みの場合、待ちリクエスト管理部204は、投入されたローカルリクエストに対する強制アボートの実行をパイプライン制御部206に指示する。これに対して、要求処理が完了していない場合、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のコア20の欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
ウェイトビットが1であり、既に待ちリクエストが存在し待ちリクエストの保持が困難な場合、待ちリクエスト管理部204は、投入されたローカルリクエストに対する強制アボートの実行をパイプライン制御部206に指示する。これに対して、ウェイトビットが0であり、待ちリクエストが存在しない場合、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のコア20の欄におけるウェイトビットを1にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部204は、強制アボートの実行の指示を行わない。
リクエストが外部リクエストの場合、待ちリクエスト管理部204は、アドレスマッチ有効状態情報303を確認して、外部リクエスト監視が有効か否かを判定する。外部リクエスト監視が有効であれば、待ちリクエスト管理部204は、リクエストの情報から送信元のクラスタ11~13の情報を取得する。以下では、送信元のクラスタ11~13を送信元クラスタと言う。そして、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元クラスタの欄における完了ビットの値を確認する。そして、待ちリクエスト管理部204は、その送信元クラスタから出力されたリクエストと同じアドレスに対する外部リクエストの要求処理が完了済みか否かを判定する。
要求処理が完了済みの場合、待ちリクエスト管理部204は、投入された外部リクエストに対する強制アボートの実行をパイプライン制御部206に指示する。これに対して、要求処理が完了していない場合、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元クラスタの欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
ウェイトビットが1であり、既に待ちリクエストが存在し待ちリクエストの保持が困難な場合、待ちリクエスト管理部204は、投入された外部リクエストに対する強制アボートの実行をパイプライン制御部206に指示する。これに対して、ウェイトビットが0であり、待ちリクエストが存在しない場合、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元クラスタの欄におけるウェイトビットを1にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部204は、強制アボートの実行の指示を行わない。
これに対して、外部リクエスト監視が無効の場合、待ちリクエスト管理部204は、外部リクエスト監視開始の判定処理の実行を外部リクエストポート管理部207に指示する。
リクエストがオーダーの場合、待ちリクエスト管理部204は、オーダー有効フラグの設定処理の実行指示をオーダーポート管理部208へ出力する。その後、待ちリクエスト管理部204は、オーダーの判定依頼の入力をオーダーポート管理部208から受ける。そして、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のオーダーポートの欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
ウェイトビットが0であり、待ちリクエストが存在しない場合、待ちリクエスト管理部204は、待ちリクエストリスト305におけるオーダーポートの欄におけるウェイトビットを1にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部204は、強制アボートの実行の指示を行わない。
一方、監視モードが通常資源競合モードで且つリクエストが監視対象である場合、待ちリクエスト管理部204は、NC通常リクエストについての待ちリクエストの判定依頼をモード管理部202から受ける。次に、待ちリクエスト管理部204は、リクエストの情報から送信元のコア20の情報を取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のコア20の欄における完了ビットの値を確認する。そして、待ちリクエスト管理部204は、そのコア20から出力されたNC通常リクエストの要求処理が完了済みか否かを判定する。
要求処理が完了済みの場合、待ちリクエスト管理部204は、投入されたNC通常リクエストに対する強制アボートの実行をパイプライン制御部206に指示する。これに対して、要求処理が完了していない場合、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のコア20の欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
ウェイトビットが1であり、既に待ちリクエストが存在し待ちリクエストの保持が困難な場合、待ちリクエスト管理部204は、投入されたNC通常リクエストに対する強制アボートの実行をパイプライン制御部206に指示する。これに対して、ウェイトビットが0であり、待ちリクエストが存在しない場合、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のコア20の欄におけるウェイトビットを1にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部204は、強制アボートの実行の指示を行わない。
また、監視モードが低速資源競合モードで且つリクエストが監視対象である場合、待ちリクエスト管理部204は、NC低速リクエストについての待ちリクエストの判定依頼をモード管理部202から受ける。次に、待ちリクエスト管理部204は、リクエストの情報から送信元のコア20の情報を取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のコア20の欄における完了ビットの値を確認する。そして、待ちリクエスト管理部204は、そのコア20から出力されたNC低速リクエストの要求処理が完了済みか否かを判定する。
要求処理が完了済みの場合、待ちリクエスト管理部204は、投入されたNC低速リクエストに対する強制アボートの実行をパイプライン制御部206に指示する。これに対して、要求処理が完了していない場合、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のコア20の欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
ウェイトビットが1であり、既に待ちリクエストが存在し待ちリクエストの保持が困難な場合、待ちリクエスト管理部204は、投入されたNC低速リクエストに対する強制アボートの実行をパイプライン制御部206に指示する。これに対して、ウェイトビットが0であり、待ちリクエストが存在しない場合、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元のコア20の欄におけるウェイトビットを1にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部204は、強制アボートの実行の指示を行わない。
また、リクエストが動作中の監視モードの監視対象にあたらない場合、待ちリクエスト管理部204は、判定処理を終了する。この場合、待ちリクエスト管理部204は、強制アボートの実行の指示を行わない。
キャッシュ制御パイプライン132による投入されたリクエストに対するパイプライン処理が完了すると、待ちリクエスト管理部204は、処理応答の入力をパイプライン制御部206から受ける。キャッシュ制御パイプラインによる投入されたリクエストに対するパイプライン処理は、要求処理の実行又はアボート処理のいずれかである。
次に、待ちリクエスト管理部204は、リクエストの送信元の情報及びエントリIDを処理応答から取得する。そして、待ちリクエスト管理部204は、送信元の情報及びエントリIDが一致する情報が待ちリクエストリスト305に存在するか否か、すなわちパイプライン処理完了したリクエストが待ちリクエストか否かを判定する。リクエストが待ちリクエストでない場合、待ちリクエスト管理部204は、パイプライン処理完了時の処理を終了させる。
これに対して、リクエストが待ちリクエストの場合、待ちリクエスト管理部204は、処理応答がアボート通知か否かを判定する。処理応答が要求処理の完了通知の場合、待ちリクエスト管理部204は、要求処理が完了したリクエストがオーダーか否かを判定する。リクエストがオーダー以外の場合、待ちリクエスト管理部204は、待ちリクエストリスト305における要求処理が完了したリクエストに対応する欄の完了ビットを1に設定して完了フラグを追加する。これに対して、リクエストがオーダーの場合、待ちリクエスト管理部204は、待ちリクエストリスト305におけるオーダーポートのウェイトビットを0にして待ちリクエストを無くす。
次に、待ちリクエスト管理部204は、待ちリクエストリスト305に登録されたローカルリクエストの待ちリクエストが全て完了したか否かを判定する。待ちリクエストリスト305に登録されたローカルリクエストの待ちリクエストが全て完了した場合、待ちリクエスト管理部204は、クラスタ10が監視対象のリクエストが要求するデータのホームか否かを判定する。
クラスタ10が監視対象のリクエストが要求するデータのホームの場合、待ちリクエスト管理部204は、アドレスマッチ有効状態情報303のリセットを外部リクエストポート管理部207に指示する。これに対して、クラスタ10が監視対象のリクエストが要求するデータのホームでない場合、待ちリクエスト管理部204は、アドレスマッチ有効状態情報303のリセットをオーダーポート管理部208に指示する。これに対して、ローカルリクエストで処理されていない待ちリクエストが残っている場合、待ちリクエスト管理部204は、アドレスマッチ有効状態情報303の状態を維持する。
その後、待ちリクエスト管理部204は、待ちリクエストリスト305に登録された全ての待ちリクエストの要求処理が完了したが否かを判定する。全ての待ちリクエストの要求処理が完了した場合、待ちリクエスト管理部204は、監視の終了を全体動作管理部201に通知する。これに対して、要求した処理が完了していない待ちリクエストが残っている場合、待ちリクエスト管理部204は、リクエストの監視を継続する。
一方、処理応答がアボート処理の場合、待ちリクエスト管理部204は、パイプライン処理が完了したリクエストがオーダーか否かを判定する。リクエストがオーダーでない場合、待ちリクエスト管理部204は、そのままリクエストの監視を継続する。
これに対して、リクエストがオーダーの場合、待ちリクエスト管理部204は、オーダーのアボートをオーダーポート管理部208へ通知する。その後、待ちリクエスト管理部204は、リクエストの監視を継続する。
オーダーを受信する可能性があるクラスタ10は、投入されたリクエストのホームである。そして、オーダーポート管理部208は、リクエストがキャッシャブルリクエストの場合、初回登録処理時に、オーダー有効フラグの設定指示を待ちリクエスト管理部204から受ける。そして、オーダーポート管理部208は、アドレスマッチ有効状態情報303におけるオーダー有効フラグを1に設定する。これにより、オーダー監視が有効になる。さらに、オーダーポート管理部208は、アボートカウンタ209を初期化して、カウンタ値を0に設定する。
後続リクエスト処理において、投入されたリクエストがオーダーの場合、オーダーポート管理部208は、オーダー有効フラグの設定処理の実行指示を待ちリクエスト管理部204から受ける。次に、オーダーポート管理部208は、アドレスマッチ有効状態情報303を参照してオーダー監視が有効か否かを判定する。オーダー監視が有効の場合、オーダーポート管理部208は、オーダーの判定依頼を待ちリクエスト管理部204へ出力する。
これに対して、オーダー監視が無効の場合、オーダーポート管理部208は、ホームのクラスタ10から応答されたデータをキャッシュに格納する際に、アドレスマッチ有効状態情報303においてオーダー有効フラグを1に設定する。これによりオーダー監視が有効となる。オーダーポート管理部208は、アボートカウンタ209を初期化して、カウンタ値を0にする。その後、オーダーポート管理部208は、オーダーの判定依頼を待ちリクエスト管理部204へ出力する。
リクエストの要求処理が完了し、クラスタ10が監視対象のリクエストが要求するデータのホームでない場合、オーダーポート管理部208は、アドレスマッチ有効状態情報303のリセットの指示を待ちリクエスト管理部204から受ける。そして、オーダーポート管理部208は、アドレスマッチ有効状態情報303のオーダー有効フラグを0に設定する。これにより、オーダー監視が無効となる。
パイプライン処理でオーダーのアボート処理が行われた場合、オーダーポート管理部208は、オーダーのアボートの通知を待ちリクエスト管理部204から受ける。そして、オーダーポート管理部208は、アボートカウンタ209のカウンタ値を1つインクリメントする。
次に、オーダーポート管理部208は、アボートカウンタ209のカウンタ値が閾値以上であるか否かを判定する。アボートカウンタ209のカウンタ値が閾値以上の場合、アドレスマッチ有効状態情報303におけるオーダー有効フラグを0に設定して、オーダー監視を無効にする。アボートカウンタ209のカウンタ値の閾値は、オーダーの要求処理の実行を停止することで処理が進まない状態に陥っていることを検出できる値であればよい。例えば、オーダーのアボートが9回行われた場合にCPU1のキャッシャブルリクエストの処理が停滞している可能性が高いと考えられるならば、閾値を9に設定することができる。
外部リクエストポート管理部207は、リクエストがキャッシャブルリクエストの場合、クラスタ10が投入されたリクエストのホームであれば、初回登録処理時に、外部リクエスト有効フラグの設定処理の実行指示を待ちリクエスト管理部204から受ける。さらに、外部リクエストポート管理部207は、リクエストの情報を待ちリクエスト管理部204から取得する。そして、外部リクエストポート管理部207は、リクエスト情報を用いてリクエストが排他性を有するローカルリクエストか否かを判定する。
リクエストが排他性を有するリクエストの場合、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303における外部リクエスト有効フラグを1に設定する。これにより、外部リクエスト監視が有効になる。これに対して、リクエストが排他性を有するリクエストでない場合、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303における外部リクエスト有効フラグを0に設定する。これにより、外部リクエスト監視は無効となる。
後続リクエスト処理において、投入されたリクエストがローカルリクエストであり、外部リクエスト監視が無効の場合、外部リクエストポート管理部207は、外部リクエスト監視開始の判定処理の実行の指示を待ちリクエスト管理部204から受ける。そして、外部リクエストポート管理部207は、以下の外部リクエスト監視開始の判定処理を実行する。
外部リクエストポート管理部207は、投入されたリクエストが排他性を有するローカルリクエストか否かを判定する。リクエストが排他性を有するローカルリクエストの場合、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303において外部リクエスト有効フラグを1に設定する。これにより、外部リクエスト監視が有効になる。
これに対して、リクエストが排他性を有するローカルリクエストでない場合、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303である外部リクエスト有効フラグを0のまま維持する。この場合、外部リクエスト監視は無効のままとなる。
また、後続リクエスト処理において、投入されたリクエストが外部リクエストであり、外部リクエスト監視が無効の場合、外部リクエストポート管理部207は、外部リクエスト監視開始の判定処理の実行の指示を待ちリクエスト管理部204から受ける。そして、外部リクエストポート管理部207は、外部リクエスト監視開始の判定処理を実行する。
パイプライン処理が完了し、クラスタ10が監視対象のリクエストが要求するデータのホームの場合、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303のリセットの指示を待ちリクエスト管理部204から受ける。そして、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303における外部リクエスト有効フラグを0に設定する。これにより、外部リクエスト監視が無効となる。
初回登録処理時には、パイプライン制御部206は、キャッシュ制御パイプライン132に対して強制アボート処理を指示せず、キャッシュ制御パイプライン132に投入されたリクエストに対しての通常のパイプライン処理を継続させる。
後続リクエスト処理時には、パイプライン制御部206は、投入されたリクエストに対する強制アボートの実行の指示を待ちリクエスト管理部204から受ける。そして、パイプライン制御部206は、強制アボートをキャッシュ制御パイプライン132に指示する。これにより、キャッシュ制御パイプライン132は、投入されたリクエストのアボート処理を行う。
パイプライン制御部206は、パイプライン処理のステージnのタイミング、すなわちパイプライン処理が完了すると処理の結果により要求処理の完了通知又はアボート処理の通知のいずれかの処理応答をキャッシュ制御パイプライン132から受ける。処理応答には、リクエストの送信元の情報及びエントリIDが含まれる。そして、パイプライン制御部206は、受信した処理応答を待ちリクエスト管理部204へ出力する。
次に、図5を参照して、リクエスト投入時のCPU1の処理開始動作を説明する。図5は、リクエスト投入時の処理開始動作を表すフローチャートである。
全体動作管理部201は、キャッシュ制御パイプライン132に投入されたリクエストの情報をプライオリティ回路131から取得する(ステップS1)。リクエストの情報には、アドレスなどが含まれる。
次に、全体動作管理部201は、全体動作情報301が表す全体有効フラグを確認して、リクエストの処理順の監視が実行中か否かを判定する(ステップS2)。
監視が実行中でない場合(ステップS2:否定)、全体動作管理部201は、モード管理部202及び待ちリクエスト管理部024にリクエストの情報を送るとともに初回登録の実行を指示する。これにより、処理順調整回路200は、初回登録処理を実行する(ステップS3)。
これに対して、監視が実行中の場合(ステップS2:肯定)、全体動作管理部201は、モード管理部202及び待ちリクエスト管理部024にリクエストの情報を送るとともに後続リクエスト処理の実行を指示する。これにより、処理順調整回路200は、後続リクエスト処理を実行する(ステップS4)。
次に、図6を参照して、初回登録処理の流れを説明する。図6は、初回登録処理のフローチャートである。図6に示すフローは、図5におけるステップS3で実行される処理の一例にあたる。
モード管理部202は、リクエストの情報を全体動作管理部201から取得する。そして、モード管理部202は、取得したリクエストの情報からリクエスト種別を取得する(ステップS101)。
次に、モード管理部202は、取得したリクエスト種別から、アドレス競合モードで動作するか否かを判定する(ステップS102)。具体的には、モード管理部202は、リクエスト種別がローカルリクエストの場合にアドレス競合モードによる監視を実行すると判定する。
アドレス競合モードで動作する場合(ステップS102:肯定)、モード管理部202は、モード識別情報302をアドレス競合モードに設定する。次に、モード管理部202は、アドレス競合モードによる監視開始を全体動作管理部201に通知する。全体動作管理部201は、全体動作情報301が表す全体有効フラグを監視実行中に変更し、監視動作を開始する(ステップS103)。
次に、モード管理部202は、アドレス競合モードによる監視開始の指示を待ちリクエスト管理部204に通知する。待ちリクエスト管理部204は、アドレス競合モードによる監視開始の指示をモード管理部202から受けて、全体動作管理部201から取得したリクエストの情報から送信元のコア20及びエントリIDを取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305の取得したコア20に対応する欄のウェイトビットを1にし、且つ、エントリIDを表す値を登録して待ちリクエスト情報を追加する(ステップS104)。
また、モード管理部202は、リクエストの情報に含まれるアドレスを対象アドレス保持部203に通知する。そして、対象アドレス保持部203は、モード管理部202から通知されたアドレスを記憶して保持する(ステップS105)。
さらに、待ちリクエスト管理部204、外部リクエストポート管理部207及びオーダーポート管理部208は、アドレスマッチ有効状態情報設定処理を実行する(ステップS106)。アドレスマッチ有効状態情報設定処理については、後で詳細に説明する。
この場合、待ちリクエスト管理部204は、強制アボート処理の通知をパイプライン制御部206に対して行わない。そのため、パイプライン制御部206は、キャッシュ制御パイプライン132に対して強制アボート処理を指示しない。そこで、キャッシュ制御パイプライン132は、投入されたリクエストに対して通常のパイプライン処理を継続する(ステップS107)。
一方、アドレス競合モードで動作しない場合(ステップS102:否定)、モード管理部202は、通常資源競合モードで動作するか否かを判定する(ステップS108)。具体的には、モード管理部202は、リクエスト種別が通常NCリクエストの場合に通常資源競合モードによる監視を実行すると判定する。
通常資源競合モードで動作する場合(ステップS108:肯定)、モード管理部202は、モード識別情報302を通常資源競合モードに設定する。次に、モード管理部202は、アドレス競合モードによる監視開始を全体動作管理部201に通知する。全体動作管理部201は、全体動作情報301が表す全体有効フラグを監視実行中に変更し、監視動作を開始する(ステップS109)。
次に、モード管理部202は、通常資源競合モードによる監視開始の指示を待ちリクエスト管理部204に通知する。待ちリクエスト管理部204は、通常資源競合モードによる監視開始の指示をモード管理部202から受けて、全体動作管理部201から取得したリクエストの情報から送信元のコア20の情報及びエントリIDを取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305の取得したコア20に対応する欄のウェイトビットを1にし、且つ、エントリIDを表す値を登録して待ちリクエスト情報を追加する(ステップS110)。
この場合も、待ちリクエスト管理部204は、強制アボート処理の通知をパイプライン制御部206に対して行わない。そのため、パイプライン制御部206は、キャッシュ制御パイプライン132に対して強制アボート処理を指示しない。そこで、キャッシュ制御パイプライン132は、投入されたリクエストに対して通常のパイプライン処理を継続する(ステップS111)。
一方、通常資源競合モードで動作しない場合(ステップS108:否定)、モード管理部202は、低速資源競合モードで動作するか否かを判定する(ステップS112)。具体的には、モード管理部202は、リクエスト種別が低速NCリクエストの場合に低速資源競合モードによる監視を実行すると判定する。
低速資源競合モードで動作する場合(ステップS112:肯定)、モード管理部202は、モード識別情報302を低速資源競合モードに設定する。次に、モード管理部202は、低速資源競合モードによる監視開始を全体動作管理部201に通知する。全体動作管理部201は、全体動作情報301が表す全体有効フラグを監視実行中に変更し、監視動作を開始する(ステップS113)。
次に、モード管理部202は、低速資源競合モードによる監視開始の指示を待ちリクエスト管理部204に通知する。待ちリクエスト管理部204は、低速資源競合モードによる監視開始の指示をモード管理部202から受けて、全体動作管理部201から取得したリクエストの情報から送信元のコア20の情報及びエントリIDを取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305の取得したコア20に対応する欄のウェイトビットを1にし、且つ、エントリIDを表す値を登録して待ちリクエスト情報を追加する(ステップS114)。
この場合も、待ちリクエスト管理部204は、強制アボート処理の通知をパイプライン制御部206に対して行わない。そのため、パイプライン制御部206は、キャッシュ制御パイプライン132に対して強制アボート処理を指示しない。そこで、キャッシュ制御パイプライン132は、投入されたリクエストに対して通常のパイプライン処理を継続する(ステップS115)。
一方、低速資源競合モードで動作しない場合(ステップS112:否定)、モード管理部202は、監視を行わないと判定する。そして、モード管理部202は、全体動作管理部201に監視動作の停止を指示し、登録処理を終了する。
次に、図7を参照して、アドレスマッチ有効状態情報設定処理の流れについて説明する。図7は、アドレスマッチ有効状態情報設定処理のフローチャートである。図7に示すフローは、図6におけるステップS106で実行される処理の一例にあたる。
待ちリクエスト管理部204は、リクエストが要求するデータのホームは自クラスタか否かを判定する(ステップS161)。
自クラスタがホームでない場合(ステップS161:否定)、待ちリクエスト管理部204は、オーダー有効フラグの設定処理の実行をオーダーポート管理部208に指示する。オーダーポート管理部208は、待ちリクエスト管理部204からのオーダー有効フラグの設定指示を受けて、アドレスマッチ有効状態情報303におけるオーダー有効フラグを1に設定する(ステップS162)。これにより、オーダー監視が有効になる。
その後、オーダーポート管理部208は、アボートカウンタ209を初期化して、カウンタ値を0に設定する(ステップS163)。
一方、自クラスタがホームの場合(ステップS161:肯定)、待ちリクエスト管理部204は、外部リクエスト有効フラグの設定処理の実行を外部リクエストポート管理部207に指示するとともにリクエストの情報を送信する。外部リクエストポート管理部207は、待ちリクエスト管理部204から受信したリクエストの情報を用いてリクエストが排他性を有するローカルリクエストか否かを判定する(ステップS164)。
リクエストが排他性を有するリクエストの場合(ステップS164:肯定)、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303における外部リクエスト有効フラグを1に設定する(ステップS165)。これにより、外部リクエスト監視が有効になる。
これに対して、リクエストが排他性を有するリクエストでない場合(ステップS164:否定)、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303における外部リクエスト有効フラグを0に設定する(ステップS166)。これにより、外部リクエスト監視は無効となる。
次に、図8を参照して、既にリクエストの監視が開始された後の後続リクエスト処理の流れについて説明する。図8は、後続リクエスト処理のフローチャートである。図8におけるステップS4で実行される処理の一例にあたる。
モード管理部202は、キャッシュ制御パイプライン132に投入されたリクエストの情報を全体動作管理部201から取得する。そして、モード管理部202は、取得したリクエストの情報からリクエスト種別を取得する(ステップS201)。また、モード管理部202は、モード識別情報302を確認し、現在の監視モードを特定する。
次に、モード管理部202は、現在の監視モードがアドレス競合モードであり、且つ、取得したリクエストがアドレス競合モードにおける監視対象であるか否かを判定する(ステップS202)。
監視モードがアドレス競合モードであり且つリクエストが監視対象の場合(ステップS202:肯定)、モード管理部202は、リクエストの情報とともにアドレスの確認依頼をアドレスマッチ判定部205へ出力する。アドレスマッチ判定部205は、リクエストの情報からリクエストが指定するアドレスを取得する。そして、アドレスマッチ判定部205は、対象アドレス情報306から監視対象のアドレスを取得し、リクエストが指定するアドレスと一致するか否かを判定する(ステップS203)。
アドレスが一致しない場合(ステップS203:否定)、アドレスマッチ判定部205は、アドレスの不一致を待ちリクエスト管理部204は通知する。そして、処理はステップS210へ進む。
これに対して、アドレスが一致した場合(ステップS203:肯定)、アドレスマッチ判定部205は、リクエストの情報とともに待ちリクエストの判定依頼を待ちリクエスト管理部204へ出力する。待ちリクエスト管理部204は、リクエストの情報を用いて、リクエストがローカルリクエストか否かを判定する(ステップS204)。
リクエストがローカルリクエストの場合(ステップS204:肯定)、待ちリクエスト管理部204及び外部リクエストポート管理部207は、外部リクエスト有効フラグ設定処理を実行する(ステップS205)。この外部リクエスト有効フラグ設定処理については後で詳細に説明する。
次に、待ちリクエスト管理部204は、リクエストの情報から送信元の情報を取得する。そして、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元に対応する欄における完了ビットの値を確認する。そして、待ちリクエスト管理部204は、その送信元から出力されたリクエストと同じアドレスに対するローカルリクエストの要求処理が完了済みか否かを判定する(ステップS206)。
要求処理が完了済みの場合(ステップS206:肯定)、待ちリクエスト管理部204は、投入されたリクエストに対する強制アボートの実行をパイプライン制御部206に指示する。そして、パイプライン制御部206は、強制アボートをキャッシュ制御パイプライン132に指示する(ステップS207)。
これに対して、要求処理が完了していない場合(ステップS206:否定)、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元に対応する欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する(ステップS208)。
ウェイトビットが0であり、待ちリクエストが存在しない場合(ステップS208:肯定)、待ちリクエスト管理部204は、待ちリクエストリスト305における送信元に対応する欄におけるウェイトビットを1にして待ちリクエストを追加する(ステップS209)。
この場合、待ちリクエスト管理部204による強制アボートの実行の指示は行われず、パイプライン制御部206は、投入されたリクエストに対する通常のパイプライン処理をキャッシュ制御パイプライン132に実行させる(ステップS210)。
これに対して、ウェイトビットが1であり、既に待ちリクエストが存在する場合(ステップS208:否定)、待ちリクエスト管理部204は、待ちリクエストリスト305を参照して、リクエストが投入されたポートが待ちリクエストを保持しており且つパイプライン処理が完了していないポートか否かを判定する(ステップS211)。
リクエストが投入されたポートが待ちリクエストを保持しており且つパイプライン処理が完了していないポートの場合(ステップS211:肯定)、処理はステップS210へ遷移する。これに対して、リクエストが投入されたポートが待ちリクエストを保持していない又はパイプライン処理が完了したポートの場合(ステップS211:否定)、処理はステップS207へ遷移する。
一方、リクエストがローカルリクエストでない場合(ステップS204:否定)、待ちリクエスト管理部204は、リクエストの情報を用いて、リクエストが外部リクエストか否かを判定する(ステップS212)。
リクエストが外部リクエストの場合(ステップS212:肯定)、待ちリクエスト管理部204は、アドレスマッチ有効状態情報303を確認して、外部リクエスト監視が有効か否かを判定する(ステップS213)。外部リクエスト監視が有効の場合(ステップS213:肯定)、処理は、ステップS206へ移る。
これに対して、外部リクエスト監視が無効の場合(ステップS213:否定)、待ちリクエスト管理部204及び外部リクエストポート管理部207は、外部リクエスト有効フラグ設定処理を実行する(ステップS214)。この外部リクエスト有効フラグ設定処理については後で詳細に説明する。その後、処理は、ステップS210へ移る。
一方、リクエストが外部リクエストでない場合(ステップS212:否定)、待ちリクエスト管理部204は、リクエストがオーダーか否かを判定する(ステップS215)。リクエストがオーダーの場合(ステップS215:肯定)、待ちリクエスト管理部204は、オーダー有効フラグの設定処理の実行指示をオーダーポート管理部208へ出力する。オーダーポート管理部208は、オーダー有効フラグの設定処理の実行指示の入力を受けて、アドレスマッチ有効状態情報303を参照してオーダー監視が有効か否かを判定する(ステップS216)。オーダー監視が有効の場合(ステップS216:肯定)、処理は、ステップS208へ遷移する。
これに対して、オーダー監視が無効の場合(ステップS216:否定)、処理は、ステップS210へ遷移する。
一方、リクエストがオーダーでない場合(ステップS215:否定)、オーダーポート管理部208は、リクエストがキャッシュフィルリクエストか否かを判定する(ステップS217)。リクエストがキャッシュフィルリクエストでない場合(ステップS217:否定)、処理は、ステップS210へ遷移する。
これに対して、リクエストがキャッシュフィルリクエストの場合(ステップS217:肯定)、オーダーポート管理部208は、アドレスマッチ有効状態情報303においてオーダー有効フラグを1に設定する(ステップS218)。これにより、オーダー監視が有効となる。
その後、オーダーポート管理部208は、アボートカウンタ209を初期化して、カウンタ値を0にする(ステップS219)。その後、処理は、ステップS210へ遷移する。
一方、監視モードがアドレス競合モードでなくリクエストが監視対象でない場合(ステップS202:否定)、モード管理部202は、監視モードが通常資源競合モードで且つリクエストが監視対象か否かを判定する(ステップS220)。監視モードが通常資源競合モードで且つリクエストが監視対象の場合(ステップS220:肯定)、処理は、ステップS206へ進む。
これに対して、監視モードが通常資源競合モードでなくリクエストが監視対象でない場合(ステップS220:否定)、モード管理部202は、監視モードが低速資源競合モードで且つリクエストが監視対象か否かを判定する(ステップS221)。監視モードが低速資源競合モードで且つリクエストが監視対象の場合(ステップS221:肯定)、処理は、ステップS206へ進む。
これに対して、監視モードが低速資源競合モードなくリクエストが監視対象でない場合(ステップS221:否定)、リクエストは監視の対象となっていないため、処理は、ステップS210へ進む。
次に、図9を参照して、外部リクエスト有効フラグ設定処理の流れについて説明する。図9は、外部リクエスト有効フラグ設定処理のフローチャートである。図9に示すフローは、図8におけるステップS205で実行される処理の一例にあたる。
ステップS205における処理の場合、待ちリクエスト管理部204は、アドレスマッチ有効状態情報303を用いて外部リクエスト監視が有効か否かを判定し、外部リクエスト監視が有効であれば外部リクエスト有効フラグ設定処理を終了する。外部リクエスト監視が無効であれば、待ちリクエスト管理部204は、外部リクエストポート管理部207に以下の処理を行わせる。また、ステップS213における処理の場合、ただちに以下の処理が行われる。
外部リクエストポート管理部207は、投入されたリクエストが排他性を有するローカルリクエストか否かを判定する(ステップS251)。
リクエストが排他性を有するローカルリクエストの場合(ステップS251:肯定)、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303において外部リクエスト有効フラグを1に設定する(ステップS252)。これにより、外部リクエスト監視が有効になる。
これに対して、リクエストが排他性を有するローカルリクエストでない場合(ステップS251:否定)、外部リクエストポート管理部207は、アドレスマッチ有効状態情報303である外部リクエスト有効フラグを0のまま維持する(ステップS253)。
次に、図10を参照して、パイプライン処理完了時の動作の流れについて説明する。図10は、パイプライン処理完了時の動作のフローチャートである。
パイプライン制御部206は、処理応答をキャッシュ制御パイプライン132から受信する(ステップS301)。そして、パイプライン制御部206は、処理応答を待ちリクエスト管理部204へ出力する。
待ちリクエスト管理部204は、処理応答の入力をパイプライン制御部206から受ける。次に、待ちリクエスト管理部204は、リクエストの送信元の情報及びエントリIDを処理応答から取得する。そして、待ちリクエスト管理部204は、送信元の情報及びエントリIDが一致する情報が待ちリクエストリスト305に存在するか否か、すなわちパイプライン処理完了したリクエストが待ちリクエストか否かを判定する(ステップS302)。リクエストが待ちリクエストでない場合(ステップS302:否定)、待ちリクエスト管理部204は、パイプライン処理完了時の処理を終了させる。
これに対して、リクエストが待ちリクエストの場合(ステップS302:肯定)、待ちリクエスト管理部204は処理応答がアボート通知か否かを判定する(ステップS303)。
処理応答がアボート通知でない場合(ステップS303:否定)、待ちリクエスト管理部204は、待ちリクエストリスト305におけるパイプライン処理が完了したリクエストに対応する欄の完了ビットを1に設定して完了フラグを追加する(ステップS304)。ただし、リクエストがオーダーの場合、待ちリクエスト管理部204は、待ちリクエストリスト305におけるオーダーポートのウェイトビットを0にして待ちリクエストを無くすことで、オーダーの処理完了を表す。
その後、待ちリクエスト管理部204、外部リクエストポート管理部207及びオーダーポート管理部208は、アドレスマッチ有効状態情報リセット処理を実行する(ステップS305)。
次に、待ちリクエスト管理部204は、待ちリクエストリスト305に登録された全ての待ちリクエストの要求処理が完了したが否かを判定する(ステップS306)。全ての待ちリクエストの要求処理が完了した場合(ステップS306:肯定)、待ちリクエスト管理部204は、監視の終了を全体動作管理部201に通知する。そして、全体動作管理部201は、全体動作情報301における全体有効フラグを監視動作無効を表す状態に変更して監視動作を終了する(ステップS307)。
これに対して、要求処理が完了していない待ちリクエストが残っている場合(ステップS306:否定)、処理はステップS312へ進む。
一方、処理応答がアボート処理の場合(ステップS303:肯定)、待ちリクエスト管理部204は、パイプライン処理が完了したリクエストがオーダーか否かを判定する(ステップS308)。リクエストがオーダーでない場合(ステップS308:否定)、処理はステップ312へ進む。
これに対して、リクエストがオーダーの場合(ステップS308:肯定)、待ちリクエスト管理部204は、オーダーのアボートをオーダーポート管理部208へ通知する。オーダーポート管理部208は、オーダー処理のアボートの通知を受けて、アボートカウンタ209のカウンタ値を1つインクリメントする(ステップS309)。
次に、オーダーポート管理部208は、アボートカウンタ209のカウンタ値が閾値以上であるか否かを判定する(ステップS310)。アボートカウンタ209のカウンタ値が閾値未満の場合(ステップS310:否定)、ステップS312へ進む。
これに対して、アボートカウンタ209のカウンタ値が閾値以上の場合(ステップS310:肯定)、アドレスマッチ有効状態情報303におけるオーダー有効フラグを0に設定して、オーダー監視を無効にする(ステップS311)。
その後、処理順調整回路200の各部は、監視を継続する(ステップS312)。
次に、図11を参照して、アドレスマッチ有効状態情報リセット処理の流れについて説明する。図11は、アドレスマッチ有効状態情報リセット処理のフローチャートである。図11に示すフローチャートは、図10におけるステップS305で実行される処理の一例にあたる。
待ちリクエスト管理部204は、待ちリクエストリスト305に登録されたローカルリクエストの待ちリクエストが全て完了したか否かを判定する(ステップS351)。ローカルリクエストの全ての待ちリクエストが完了した場合(ステップS351:肯定)、自クラスタがホームであれば、外部リクエストポート管理部207がアドレスマッチ有効状態情報303における外部リクエスト有効フラグを0に設定する。また、自クラスタがホームでなければ、オーダーポート管理部208が、オーダー有効フラグを0に設定する(ステップS352)。これにより、外部リクエスト監視又はオーダー監視が無効となる。
これに対して、ローカルリクエストで処理されていない待ちリクエストが残っている場合(ステップS351:否定)、自クラスタがホームであれば、外部リクエストポート管理部207がアドレスマッチ有効状態情報303における外部リクエスト有効フラグを1のまま維持する。また、自クラスタがホームでなければ、オーダーポート管理部208が、オーダー有効フラグを1のまま維持する(ステップS353)。これにより、外部リクエスト監視又はオーダー監視が有効のまま維持される。
次に、図12及び13を参照して、本実施例に係るCPU1を用いた場合と従来のCPUを用いた場合のデータ処理の速度の比較について説明する。図12は、従来のCPUによるデータ処理の一例のシーケンス図である。また、図13は、実施例に係るCPUによるデータ処理の一例のシーケンス図である。
ここでは、監視するリクエストが要求したデータのホームがクラスタ10であり、クラスタ10~13のいずれにおいてもコア#00とコア#01とがアドレスが同一のローカルリクエストを発行した場合で説明する。
図12に示すローカルリクエスト401は、クラスタ10において、LLC100が、コア#00が発行したリクエストとアドレスが同じコア#01が発行したリクエストである。その後、コア#00が発行したリクエストを処理する間に、クラスタ10のLLC100は、クラスタ11~13のLLC100から外部リクエスト402~404を受ける。
従来のCPUでは、ローカルリクエストの処理が完了していない場合でも、外部リクエストがローカルリクエストに優先される場合がある。その場合、クラスタ10においてコア#01が発行したリクエストが処理されずに、データ転送405で示すようにデータがクラスタ11のLLC100へ送られる。
クラスタ11のLLC100は、コア#00が発行したリクエストを処理する間に、クラスタ10のLLC100からクラスタ12へのオーダー408の入力を受ける。ここでも、従来のCPUでは、ローカルリクエストの処理が完了していない場合でも、オーダーがローカルリクエストに優先される場合がある。その場合、クラスタ11においてコア#01が発行したリクエストが処理されずに、データ転送407で示すようにデータがクラスタ12のLLC100へ送られる。
クラスタ12のLLC100は、コア#00が発行したリクエストを処理する間に、クラスタ10のLLC100からクラスタ13へのオーダー408の入力を受ける。ここでも、クラスタ12においてコア#01が発行したリクエストが処理されずに、データ転送409で示すようにデータがクラスタ13のLLC100へ送られる。
クラスタ13のLLC100は、コア#00が発行したリクエストを処理する間に、クラスタ10のLLC100からデータをホームへ戻すオーダー410の入力を受ける。ここでも、クラスタ13においてコア#01が発行したリクエストが処理されずに、データ転送411で示すようにデータがクラスタ11のLLC100へ送られる。
以上の処理により、期間412の間に、各クラスタ10~13においてコア#00のリクエストは処理されたが、コア#01のリクエストは処理されずにデータがクラスタ10~13の間を移動する。
その後、期間413において、クラスタ10~13のそれぞれのコア#01のリクエストを処理するように順にデータが移動されて処理が行われる。このように、従来のCPUでは、データ処理の全体の時間として、期間412と期間413を合わせた時間がかかる。
これに対して、本実施例に係るCPU1であれば図13に示すように処理を行う。すなわち、コア#00及び#01からリクエストを受けた、クラスタ10のLLC100が、クラスタ11~13のLLC100から外部リクエスト501~503を受ける。本実施例に係るCPU1の処理順調整回路200は、外部リクエスト及びオーダーに優先させてローカルリクエストをキャッシュ制御パイプライン132に処理させ、ローカルリクエストの待ちリクエストが無くなってから外部リクエスト又はオーダーを実行させる。
そのため、クラスタ10のLLC100は、コア#00及び#01からのリクエストを処理した後に、クラスタ11へリクエストコンプリートを送信する。すなわち、クラスタ10のLLC100は、外部リクエスト501の応答としてデータをクラスタ11へ送信する。これにより、期間504の間にクラスタ10のコア#00及び#01が発行したリクエストの処理が完了する。その後、クラスタ10のLLC100は、外部リクエスト502に基づいてクラスタ12へのデータの転送を指示するオーダー505をクラスタ11へ送信する。
クラスタ11のLLC100は、オーダー505を受信しても、コア#00及び#01のリクエストの処理を継続し、コア#00及び#01からのリクエストを処理した後に、クラスタ12へオーダーコンプリートを送信する。すなわち、クラスタ11のLLC100は、データ転送507に示すようにデータをクラスタ12へ送信する。これにより、期間506の間にクラスタ11のコア#00及び#01が発行したリクエストの処理が完了する。
その後、クラスタ10のLLC100は、クラスタ11からの処理完了の応答を受けて、オーダー508をクラスタ12へ送信する。クラスタ12のLLC100は、オーダー508を受信しても、コア#00及び#01のリクエストの処理を継続し、コア#00及び#01からのリクエストを処理した後に、クラスタ13へオーダーコンプリートを送信する。すなわち、クラスタ12のLLC100は、データ転送510に示すようにデータをクラスタ13へ送信する。これにより、期間509の間にクラスタ12のコア#00及び#01が発行したリクエストの処理が完了する。
その後、クラスタ10のLLC100は、クラスタ12からの処理完了の応答を受けて、データをホームへ戻すオーダー511をクラスタ13へ送信する。クラスタ13のLLC100は、オーダー511を受信しても、コア#00及び#01のリクエストの処理を継続し、コア#00及び#01からのリクエストを処理した後に、データ転送513に示すようにデータをクラスタ10へ戻す。これにより、期間512の間にクラスタ12のコア#00及び#01が発行したリクエストの処理が完了する。
以上の処理により、本実施例に係るCPU1は、期間504、506、509及び512を合わせた期間でデータ処理が完了する。このように、本実施例に係るCPU1は、各クラスタ10~13においてローカルリクエストをまとめて処理し、その後にデータを移動させることで、データ処理の全体の時間を短縮して処理速度を向上させることができる。
以上に説明したように、本実施例に係るCPUは、アドレスが競合するキャッシャブルのリクエストの場合、外部リクエスト及びオーダーに対してローカルリクエストを優先して処理する。これにより、全クラスタで共有が完了するまでに必要なクラスタ間ネットワーク通信に係るレイテンシコストを削減することができる。また、本実施例に係るCPUは、既に発行したリクエストを処理したリクエストポートのリクエストに優先させて、処理が完了していないリクエストポートを優先させる。これにより、キャッシャブルのリクエストが競合した場合にリクエスト間で均衡が取れた処理を実行することができる。これにより、未処理のコアのリクエストが待機しているにもかかわらず一度リクエストが処理されたコアからのリクエストが再び受理されることを防止でき、特定のコアの処理が進み、処理の進まないコアが発生すること軽減することができる。
また、本実施例に係るCPUは、ノンキャッシャブルのリクエストについても既に発行したリクエストを処理したリクエストポートのリクエストに優先させて、処理が完了していないリクエストポートを優先させる。これにより、ノンキャッシャブルのリクエストが競合した場合にもリクエスト間で均衡が取れた処理を実行することができる。さらに、本実施例に係るCPUは、処理に時間が掛かるリクエストと、それ以外のリクエストとを分けることで、処理に時間がかかるリクエストが滞留しても、それ以外のリクエストの発行が可能であり、処理効率を向上させることができる。また、特に処理に時間がかかるリクエストにおいて順序不平等が発生すると追い抜かれたコアは非常に長い待ち時間が発生してしまうが、本実施例に係るCPUは、リクエスト間で均衡が取れた処理を実行することで、コアの待ち時間を短縮することができる。
また、以上の説明では同一のCPU内のクラスタ間でのリクエストの処理順の調整について説明したが、他のCPUのクラスタから送られてきたリクエストも外部リクエスト及びオーダーと同様に処理することで、順序の公平性を保つことが可能である。