(57)【特許請求の範囲】
【請求項１】
主記憶装置を制御する主記憶制御装置を有する第１の演算処理装置と、前記第１の演算処理装置と接続される第２の演算処理装置とを備える情報処理装置において、
前記第１の演算処理装置は
前記主記憶装置から前記第２の演算処理装置に持ち出されたデータの変更の有無を含む管理状態を示す管理情報を保持する管理情報格納部と、
前記管理情報の更新を要求する更新要求を受信する受信部と、
前記管理情報が示す管理状態と前記受信した更新要求とが所定の関係を満たすか否かを判定するチェック部と、
前記更新要求にリトライを示す情報が付与され、前記受信した更新要求が前記管理状態を第１の状態から第２の状態に更新し、かつ、前記管理情報が既に第２の状態に更新済みを表す場合、前記第２の演算処理装置に前記更新要求が正常に終了したことを示す完了応答を送信する応答パケット送信部と、
を有する情報処理装置。
【請求項２】
前記チェック部によるチェックの結果、前記管理状態と前記受信した更新要求とが所定の基準により整合する関係にある場合、前記応答パケット送信部は、前記更新要求にリトライを示す情報が付与されているか否かに拘わらず、前記第２の演算処理装置に前記更新要求が正常に終了したことを示す完了応答を送信する請求項１に記載の情報処理装置。
【請求項３】
前記チェック部によるチェックの結果、前記管理状態と前記受信した更新要求とが前記所定の基準により整合する関係になく、かつ、前記受信した更新要求にリトライを示す情報が付与されていない場合には、前記応答パケット送信部は、所定の通知先にエラーを通知する請求項２に記載の情報処理装置。
【請求項４】
前記チェック部によるチェックの結果、前記管理状態と前記受信した更新要求とが前記所定の基準により整合する関係になく、前記更新要求にリトライを示す情報が付与されており、かつ、前記管理情報がすでに第２の状態に更新済みとなっていない場合には、前記応答パケット送信部は、所定の通知先にエラーを通知する請求項２または３に記載の情報処理装置。
【請求項５】
第２の演算処理装置と接続される第１の演算処理装置として動作する演算処理装置において、
主記憶装置を制御する主記憶制御装置と、
前記主記憶装置から前記第２の演算処理装置に持ち出されたデータの変更の有無を含む管理状態を示す管理情報を保持する管理情報格納部と、
前記管理情報の更新を要求する更新要求を受信する受信部と、
前記管理情報が示す管理状態と前記受信した更新要求とが所定の関係を満たすか否かを判定するチェック部と、
前記更新要求にリトライを示す情報が付与され、前記受信した更新要求が前記管理状態を第１の状態から第２の状態に更新し、かつ、前記管理情報がすでに第２の状態に更新済みを表す場合、前記第２の演算処理装置に前記更新要求が正常に終了したことを示す完了応答を送信する応答パケット送信部と、
を有する演算処理装置。
【請求項６】
主記憶装置を制御する主記憶制御装置を有する第１の演算処理装置と、前記第１の演算処理装置と接続される第２の演算処理装置とを備える情報処理装置の制御方法において、前記第１の演算処理装置が、
前記主記憶装置から前記第２の演算処理装置に持ち出されたデータの変更の有無を含む
管理状態を示す管理情報を保持し、
前記管理情報の更新を要求する更新要求を受信し、
前記管理情報が示す管理状態と前記受信した更新要求とが所定の関係を満たすか否かを判定し、
前記更新要求にリトライを示す情報が付与され、前記受信した更新要求が前記管理状態を第１の状態から第２の状態に更新し、かつ、前記管理情報がすでに第２の状態に更新済みを表す場合、前記第２の演算処理装置に前記更新要求が正常に終了したことを示す完了応答を送信する情報処理装置の制御方法。
【請求項７】
前記第２の演算処理装置は、前記状態情報を更新するための更新要求を前記第１の演算処理装置に送信し、前記送信した更新要求に対する完了応答が前記第１の演算処理から得られない場合、リトライを示す情報を設定した次の更新要求を前記第１の演算処理に送信するリトライ処理を所定の限度まで繰り返す請求項６に記載の情報処理装置の制御方法。
【請求項８】
前記所定の限度は、前記リトライの回数、および前記第１の演算処理装置と前記第２の演算処理装置との接続状態を含む前記情報処理装置の稼働状態の少なくとも一方により判定される請求項７に記載の情報処理装置の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、演算処理装置、および情報処理装置の制御方法に関する。
【背景技術】
【０００２】
情報処理装置、コンピュータ等は、演算処理を実行するＣＰＵ（演算処理装置ともいう）と、Ｄｕａｌ  Ｉｎｌｉｎｅ  Ｍｅｍｏｒｙ  Ｍｏｄｕｌｅ（ＤＩＭＭ）等のメインメモリを有する。コンピュータシステムでは、メインメモリはデータを格納し、ＣＰＵがメインメモリにアクセスし、データの参照、あるいはデータの書き換えを行う。
【０００３】
メインメモリとして使用されるＤＩＭＭは読み書きが遅いため、ＣＰＵは内部にキャッシュと呼ばれる記憶媒体を備える。ＣＰＵはメインメモリのデータの一部をキャッシュに格納することで、処理対象のデータがキャッシュに存在する場合には、メインメモリまでアクセスせずにキャッシュからデータを読み、データへのアクセスを高速化する。
【０００４】
ＣＰＵからの読み出し要求がキャッシュミスした時に、要求対象のデータはキャッシュに新規登録される。しかし、キャッシュに空きがない場合、すでにキャッシュに格納されていたデータがリプレースのためムーブアウトされる。データがリプレースのためムーブアウトされるとき、キャッシュ制御部は、そのデータと制御信号を一時的に格納し、Ｈｏｍｅ−ＣＰＵへ送出する制御を行う。ここで、Ｈｏｍｅ−ＣＰＵは、配下にムーブアウト対象のメインメモリを持つＣＰＵである。なお、キャッシュからデータがムーブアウトされるのは、キャッシュに空きがない時に限るものではなく、キャッシュに空きがある場合でも明示的にムーブアウトが実行されるケースがある。以下のムーブアウトは、キャッシュに空きがない場合と、キャッシュに空きがあって明示的に実行される場合の両者を含む。
【０００５】
図１に、マルチプロセッサシステムにおけるキャッシュの制御を例示する。図１のマルチプロセッサシステムは、Ｌｏｃａｌ−ＣＰＵとＨｏｍｅ−ＣＰＵを有する。また、図１の例では、Ｌｏｃａｌ−ＣＰＵがリクエスト元であり、Ｈｏｍｅ−ＣＰＵとは異なるＣＰＵであるとする。Ｈｏｍｅ−ＣＰＵは、ムーブアウト対象のデータが格納されたメインメモリを管理するＣＰＵである。なお、図１では、省略されているが、図２のＨｏｍｅ−ＣＰＵもＬｏｃａｌ−ＣＰＵと同様、キャッシュ制御部を有してもよい。また、図２のＬｏｃａｌ−ＣＰＵも、Ｈｏｍｅ−ＣＰＵと同様、自身のメインメモリを管理してもよい。
【０００６】
リクエスト元であるＬｏｃａｌ−ＣＰＵのキャッシュ制御部は、ムーブアウトされるデータが変更済みであれば、Ｈｏｍｅ−ＣＰＵに対してデータ付きのライトバック（ＷＲＢＫ）のリクエストパケットを送出する。一方、ムーブアウトされるデータが変更されていなければ、Ｌｏｃａｌ−ＣＰＵのキャッシュ制御部は、Ｈｏｍｅ−ＣＰＵに対してデータ無しのフラッシュバック（ＦＬＢＫ）のリクエストパケットを送出する。
【０００７】
図１のように、Ｈｏｍｅ−ＣＰＵは、ライトバック（ＷＲＢＫ）あるいはフラッシュバック（ＦＬＢＫ）のリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受けると、プロトコルチェックを行い、管理情報を更新し、ライトバック（ＷＲＢＫ）あるいはフラッシュバック（ＦＬＢＫ）のコンプリート（ＣＰＬＴ）パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）をＬｏｃａｌ−ＣＰＵに送出する。
【０００８】
図２に、Ｌｏｃａｌ−ＣＰＵによるＷＲＢＫ／ＦＬＢＫの制御を例示する。cache-coherent NonUniform Memory Access（ｃｃ−ＮＵＭＡ）に代表されるマルチプロセッサシス
テムにおいては、メインメモリとして使用されるＤＩＭＭ上に、データと付随する形でキャッシュ持ち出し情報（ディレクトリ）が保持される。そして、Ｈｏｍｅ−ＣＰＵは、メモリアクセスの際にデータとともにディレクトリを読み出してキャッシュ一貫性（キャッシュコヒーレンシ）をチェックする。このようなキャッシュの制御は、ディレクトリ方式のキャッシュ一貫性制御と呼ばれる。
【０００９】
図２の処理では、Ｌｏｃａｌ−ＣＰＵは、Ｈｏｍｅ−ＣＰＵに対して、ＷＲＢＫ／ＦＬＢＫを発行し、タイマーを起動する（Ａ１）。そして、Ｌｏｃａｌ−ＣＰＵは、タイマーが閾値に達するまでに、Ｈｏｍｅ−ＣＰＵから応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を受信したか否かを判定する（Ａ２）。Ａ２の判定がＹＥＳの場合には、Ｌｏｃａｌ−ＣＰＵは、ＷＲＢＫ／ＦＬＢＫの制御を正常終了する。一方、Ａ２の判定がＮＯの場合には、Ｌｏｃａｌ−ＣＰＵは、Ｆａｔａｌエラーを検出したことをエラー制御部へ通知する（Ａ３）。ここで、Ｆａｔａｌエラーは動作継続不可能なエラーである。エラー制御部は、例えば、ＣＰＵごとに設けられるＣＰＵ監視用の専用プロセッサ、あるいはファームウェア等である。エラー制御部は、Ｆａｔａｌエラーが検出された通知を受けると、さらにＣＰＵ外部の管理装置にＦａｔａｌエラーを報告する。
【００１０】
図３に、ＷＲＢＫ／ＦＬＢＫのリクエストパケットを処理するＨｏｍｅ−ＣＰＵのフローチャートを例示する。この処理では、Ｈｏｍｅ−ＣＰＵは、Ｌｏｃａｌ−ＣＰＵからＷＲＢＫ／ＦＬＢＫのリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受信する（Ｂ１）。Ｈｏｍｅ−ＣＰＵは、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受信すると、Ｈｏｍｅ−ＣＰＵ上やＤＩＭＭ上に格納している管理情報（ディレクトリ等）に基づくプロトコルチェックを行う（Ｂ２）。そして、プロトコルチェックでエラーがない場合には、Ｈｏｍｅ−ＣＰＵはリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対応する処理を実行する。例えば、Ｈｏｍｅ−ＣＰＵはライトバックリクエストの場合には、Ｈｏｍｅ−ＣＰＵはメインメモリのデータを更新し、管理情報を更新する（Ｂ３）。さらに、Ｈｏｍｅ−ＣＰＵは、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対する処理を完了すると、Ｌｏｃａｌ−ＣＰＵへ応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を返す（Ｂ４）。一方、プロトコルチェックでエラーがある場合には、Ｈｏｍｅ−ＣＰＵはＦａｔａｌエラーを検出したことをエラー制御部へ通知する（Ｂ５）。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特表平１１−５１１６３４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
ところで、マルチプロセッサシステムにおいて、演算処理装置間の間欠故障等により、送信されたパケットが消失することがあり得る。これをパケットロストと呼ぶ。上記従来の技術では、データを持ち出した演算処理装置がメインメモリを管理する演算処理装置にリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を送信する際、または、メインメモリを管理する演算処理装置がデータを持ち出した演算処理装置に応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を送信する際、パケットロストへの対応が十分でなく、下記の問題点がある。
（１）メインメモリの管理情報が更新されないため、キャッシュの制御に矛盾が生じ演算処理装置は、動作を継続させることができない。
（２）メインメモリのデータを管理する演算処理装置において、メインメモリへライトバックするムーブアウトデータが失われ、演算処理装置がデータ更新に失敗する。
このうち、（２）の問題に対しては、故障が固定故障ではなく間欠故障等の場合には、データを持ち出した演算処理装置が再度リクエストパケットを送信するリトライにより解決
が図られる。一方、（１）の問題については、対応が十分でない場合がある。
【００１３】
本発明は、メインメモリを管理する演算処理装置（Ｈｏｍｅ−ＣＰＵ）とメインメモリのデータを持ち出している演算処理装置（Ｌｏｃａｌ−ＣＰＵ）との間で間欠故障等により、キャッシュの制御に矛盾が生じた場合でも、メインメモリの管理情報を更新し、動作を継続できる可能性を高めることを目的とする。
【課題を解決するための手段】
【００１４】
本発明の一側面は、以下の情報処理装置によって例示される。すなわち、本情報処理装置は、主記憶装置を制御する主記憶制御装置を有する第１の演算処理装置と、前記第１の演算処理装置と接続される第２の演算処理装置とを備える。この第１の演算処理装置は前記主記憶装置から前記第２の演算処理装置に持ち出されたデータの変更の有無を含む管理状態を示す管理情報を保持する管理情報格納部と、前記管理情報の更新を要求する更新要求を受信する受信部と、前記管理情報が示す管理状態と前記受信した更新要求とが所定の関係を満たすか否かを判定するチェック部と、前記更新要求にリトライを示す情報が付与され、前記受信した更新要求が前記管理状態を第１の状態から第２の状態に更新し、かつ、前記管理情報が既に第２の状態に更新済みを表す場合、前記第２の演算処理装置に前記更新要求が正常に終了したことを示す完了応答を送信する応答パケット送信部と、を有する。
【発明の効果】
【００１５】
本演算処理装置によれば、メインメモリを管理する演算処理装置とメインメモリのデータを持ち出している演算処理装置との間で間欠故障等により、キャッシュの制御に矛盾が生じた場合でも、メインメモリの管理情報を更新し、動作を継続できる可能性を高めることができる。
【図面の簡単な説明】
【００１６】
【図１】マルチプロセッサシステムにおけるキャッシュの制御を例示する図である。
【図２】Ｌｏｃａｌ−ＣＰＵによるＷＲＢＫ／ＦＬＢＫの制御を例示する図である。
【図３】リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を処理するＨｏｍｅ−ＣＰＵの処理を例示するフローチャートである。
【図４】Ｌｏｃａｌ-ＣＰＵからＨｏｍｅ-ＣＰＵへの経路でのパケットロストとリトライによる解決方法を例示する図である。
【図５】Ｈｏｍｅ-ＣＰＵからＬｏｃａｌ-ＣＰＵへの経路でのパケットロストとリトライ時の課題を例示する図である。
【図６】比較例のＨｏｍｅ-ＣＰＵでの処理のフローチャートである。
【図７】リクエストパケット処理時のエラーの有無のケースおよびエラーの分類を例示する図である。
【図８】情報処理装置の構成を例示する図である。
【図９】ＷＲＢＫ／ＦＬＢＫロストケースの処理を例示する図である。
【図１０】ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴロストケースの処理を例示する図である。
【図１１】Ｌｏｃａｌ−ＣＰＵとＨｏｍｅ−ＣＰＵを含む情報処理装置の処理のフローチャートを例示する図である。
【図１２】Ｌｏｃａｌ−ＣＰＵの処理のフローチャートを例示する図である。
【図１３】Ｈｏｍｅ−ＣＰＵの処理のフローチャートを例示する図である。
【図１４】エラーの分類を例示する図である。
【図１５】Ｌｏｃａｌ−ＣＰＵの処理を実行する制御回路を例示する図である。
【図１６】Ｈｏｍｅ−ＣＰＵの処理を実行する制御回路を例示する図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照して一実施形態に係る情報処理装置について説明する。
【００１８】
［比較例］
図４から図７により、比較例に係るコンピュータについて説明する。比較例では、コンピュータは、Ｌｏｃａｌ−ＣＰＵと、Ｈｏｍｅ−ＣＰＵを有する。図４の例では、Ｈｏｍｅ−ＣＰＵは、ムーブアウト対象のデータが格納されたメインメモリを管理するＣＰＵである。また、Ｌｏｃａｌ−ＣＰＵは、Ｈｏｍｅ−ＣＰＵが管理するメインメモリから、データを持ち出し、Ｌｏｃａｌ−ＣＰＵ内のキャッシュに保持していると仮定する。さらに、図４以下では、省略されているが、Ｈｏｍｅ−ＣＰＵもＬｏｃａｌ−ＣＰＵと同様、キャッシュ制御部を有する。また、図４以下のＬｏｃａｌ−ＣＰＵも、Ｈｏｍｅ−ＣＰＵと同様、自身のメインメモリを管理する。従来の構成では、Ｌｏｃａｌ−ＣＰＵがリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）をＨｏｍｅ−ＣＰＵに送信する際、または、Ｈｏｍｅ−ＣＰＵが応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）をＬｏｃａｌ−ＣＰＵに送信する際、パケットロストへの対応が十分でない。パケットロストへの改善として、送信したパケットを単純にもう一度送信（リトライ）することが考えられる。なお、ＷＲＢＫ／ＦＬＢＫは、ライトバックまたはフラッシュバックを表す。
【００１９】
図４は、Ｌｏｃａｌ-ＣＰＵからＨｏｍｅ-ＣＰＵへの経路でのパケットロスト（以下、ＷＲＢＫ／ＦＬＢＫロストケース）とリトライによる解決方法を例示する図である。図４では、Ｌｏｃａｌ-ＣＰＵのキャッシュ制御部は、ＷＲＢＫのリクエストパケットまたは
ＦＬＢＫのリクエストパケットをＨｏｍｅ−ＣＰＵに送信する。しかし、図４では、Ｌｏｃａｌ-ＣＰＵからＨｏｍｅ-ＣＰＵに至る経路上で、ＷＲＢＫ／ＦＬＢＫのリクエストパケットが消失、すなわち、パケットロストが発生している。
【００２０】
図４の例では、Ｈｏｍｅ-ＣＰＵには、リクエストパケットが届かないため、Ｈｏｍｅ-ＣＰＵは何も実行しない。すなわち、Ｈｏｍｅ-ＣＰＵは、管理情報を用いたプロコトル
チェック等の処理、あるいは、プロコトルチェックの結果に基づく応答パケットの送信等を実行しない。一方、Ｌｏｃａｌ-ＣＰＵのキャッシュ制御部は、タイマーを起動し、応
答パケットを待つ。しかし、Ｈｏｍｅ-ＣＰＵからは応答パケットが送信されないため、
Ｌｏｃａｌ-ＣＰＵでは、タイムアウトが発生する。
【００２１】
比較例のコンピュータでは、リクエストパケットに対するタイムアウトが発生すると、Ｌｏｃａｌ-ＣＰＵのキャッシュ制御部はリトライを実行する。すなわち、キャッシュ制
御部は、再度ＷＲＢＫ／ＦＬＢＫのリクエストパケットにリトライフラグを設定して送信する。リトライフラグは、例えば、初回発行時：０、リトライ発行時：１等のような１ｂｉｔの情報である。
【００２２】
仮に、タイムアウトを発生させたリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）のパケットロストの原因が間欠的なもの、あるいは、一時的なものである場合には、リトライにより、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）がＨｏｍｅ-ＣＰＵに到達する。
【００２３】
すると、Ｈｏｍｅ-ＣＰＵは、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受け取る
。Ｈｏｍｅ-ＣＰＵは、Ｌｏｃａｌ-ＣＰＵにおいてタイムアウトが発生した時のリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受け取っていないため、リトライによるリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）にしたがって、プロトコルチェックを行い、メインメモリの更新あるいは管理情報の更新等の処理を実行すればよい。そして、Ｈｏｍｅ-ＣＰＵ
は、処理完了後に、応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）をＬｏｃａｌ−ＣＰＵに送信すればよい。
【００２４】
図５は、Ｈｏｍｅ-ＣＰＵからＬｏｃａｌ-ＣＰＵへの経路でのパケットロスト（以下、
ＷＲＢＫ／ＦＬＢＫ-ＣＰＬＴロストケース）とリトライ時の課題を例示する図である。
図５の例では、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）がＨｏｍｅ-ＣＰＵに到達し
、Ｈｏｍｅ-ＣＰＵは、プロトコルチェックを行い、メインメモリの更新あるいは管理情
報を更新し、応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）をＬｏｃａｌ-ＣＰＵに送
信している。しかし、Ｈｏｍｅ-ＣＰＵからＬｏｃａｌ-ＣＰＵに至る経路上で、応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）が消失し、応答パケットのパケットロストが発生している。図５の場合も、図４の場合と同様、Ｌｏｃａｌ-ＣＰＵでは、タイムアウトが
発生する。
【００２５】
応答パケットが消失した場合にも、Ｌｏｃａｌ-ＣＰＵのキャッシュ制御部は、再度リ
クエストパケット（ＷＲＢＫ／ＦＬＢＫ）を送信する。ただし、Ｈｏｍｅ-ＣＰＵでは、
リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対する処理がすでに完了している。このため、Ｈｏｍｅ-ＣＰＵは、リトライによるリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を
受け取っても、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）と現在の管理情報との間に矛盾があり、プロトコルチェックを正常に実行できない。したがって、ＷＲＢＫ／ＦＬＢＫ-ＣＰＬＴロストケースケースでは、プロトコルチェックを正常に実行し、管理情報を本
来の正常な状態に戻す上で、課題がある。
【００２６】
図６に、比較例のＨｏｍｅ-ＣＰＵでの処理のフローチャートを例示する。この処理で
は、Ｈｏｍｅ-ＣＰＵは、Ｌｏｃａｌ-ＣＰＵからリトライではない、通常処理のリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受信する（Ｃ１）。次に、Ｈｏｍｅ-ＣＰＵは、管
理情報に基づくプロトコルチェックでエラーの有無を判定する（Ｃ２）。なお、Ｃ２の判定は、従来から行われている、プロトコルチェックであり、例えば、Ｍｏｄｉｆｉｅｄ、Ｅｘｃｌｕｓｉｖｅ、Ｓｈａｒｅｄ、Ｉｎｖａｌｉｄ（ＭＥＳＩ）プロトコルによるチェックをいう。ＭＥＳＩプロトコルによるチェックでは、例えば、Ｈｏｍｅ-ＣＰＵで、Ｌ
ｏｃａｌ-ＣＰＵがキャッシュにＳｈａｒｅｄ（Ｓ）で持ち出したデータに対して、ＷＲ
ＢＫによるライトバック要求を受信するとエラーと判断できる。なお、本実施形態において、従来から行われているプロトコルチェックは、ＭＥＳＩプロトコルによるチェックに限定されない。例えば、従来のプロトコルチェックは、Ｅｘｃｌｕｓｉｖｅ状態を持たないキャッシュプロトコルであるＭＳＩプロトコルによるチェックでもよい。また、従来のプロトコルチェックは、ＭＳＩプロトコルにＯｗｎｅｄ状態を加えたＭＯＳＩプロトコルによるチェックでもよい。さらに、従来のプロトコルチェックは、ＭＥＳＩプロトコルにＯｗｎｅｄ状態を加えたＭＯＥＳＩプロトコルによるチェックでもよい。本実施形態においては、以上例示したようなＣ２の判定で用いられるプロトコルチェックを従来のプロトコルチェックと呼ぶ。
【００２７】
Ｃ２の判定で、プロトコルチェックにエラーがない場合、Ｈｏｍｅ-ＣＰＵは、リトラ
イフラグの値に依存せず、ＷＲＢＫ／ＦＬＢＫにしたがって処理を実行すればよい（Ｃ３）。すなわち、Ｈｏｍｅ-ＣＰＵは、ＷＲＢＫのリクエストパケットに対して、メインメ
モリのデータと、管理情報を更新する。また、Ｈｏｍｅ-ＣＰＵは、ＦＬＢＫリクエスト
パケットに対して、メインメモリのデータを更新しないで、管理情報を更新する。さらに、Ｈｏｍｅ-ＣＰＵは、Ｌｏｃａｌ-ＣＰＵへ応答パケット（ＷＲＢＫ／ＦＬＢＫ-ＣＰＬ
Ｔ）を送信する（Ｃ４）。Ｃ４では、Ｈｏｍｅ-ＣＰＵは、受信したリクエストパケット
（ＷＲＢＫ／ＦＬＢＫ）のリトライフラグ（０、１）と同じ値のリトライフラグを付与して、応答パケット（ＷＲＢＫ／ＦＬＢＫ-ＣＰＬＴ）を送信する。したがって、Ｃ２の判
定でプロトコルエラーがない場合には、リトライフラグの設定いかんによらず、処理は正常終了となる。
【００２８】
一方、Ｃ２の判定で、プロトコルチェックにエラーがある場合、Ｈｏｍｅ-ＣＰＵは、
リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）のリトライフラグが０か否かを判定する（Ｃ
５）。Ｃ５の判定でリトライフラグが０、すなわち、リクエストパケットがリトライではない場合には、Ｈｏｍｅ-ＣＰＵは、Ｆａｔａｌエラーを検出したことをエラー制御部へ
通知する（Ｃ６）。エラー制御部はＦａｔａｌエラーに対応する報告を例えば、管理コンピュータに送信する。したがって、Ｃ５でリトライフラグが０ある場合には、処理はＦａｔａｌエラーの送信という結果となる。
さらに、Ｃ５の判定で、リトライフラグが１、すなわち、リクエストパケットがリトライである場合には、Ｈｏｍｅ-ＣＰＵは、Ｆａｔａｌエラーか否かの判定ができない（Ｃ７
）。本実施の形態において、Ｆａｔａｌエラーではないエラーとは、救済可能なエラーであり、擬似エラーと呼ぶ。仮に、Ｈｏｍｅ-ＣＰＵは、Ｆａｔａｌエラーを検知できれば
、Ｃ６の処理に進めればよい。また、Ｈｏｍｅ-ＣＰＵは、擬似エラーを検知できれば、
リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対応する処理を実行し（Ｃ８）、Ｌｏｃａｌ-ＣＰＵへ応答パケット（ＷＲＢＫ／ＦＬＢＫ-ＣＰＬＴ）を送信すればよい。
【００２９】
図７は、リクエストパケット処理時のエラーの有無のケースおよびエラーの分類を例示する図である。従来のＭＥＳＩプロトコル等にしたがったプロトコルチェックでエラーがない場合には、比較例のＬｏｃａｌ-ＣＰＵとＨｏｍｅ-ＣＰＵとの間のリクエストパケットにおいても、エラー無しとなる。ただし、エラー無しであっても、比較例のコンピュータでは、リトライフラグ＝０の場合（リトライでない場合）と、リトライフラグ＝１の場合（リトライである場合）があり得る。すなわち、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）がＬｏｃａｌ-ＣＰＵからＨｏｍｅ-ＣＰＵに至る経路でパケットロストとなると、リクエストパケットはＨｏｍｅ-ＣＰＵには到達しない。したがって、Ｌｏｃａｌ-ＣＰＵがリトライでリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を再度送信し、リクエストパケットがＨｏｍｅ-ＣＰＵに到達すると、リクエストパケットは、Ｈｏｍｅ-ＣＰＵにとっては、リトライフラグが設定されている点を除外して、正常なパケットである。したがって、従来のプロトコルチェックでエラー無しのリクエストパケットは、リトライの有無によらず、正常なものとして処理される。
【００３０】
一方、従来のＭＥＳＩ等のプロトコルチェックでエラー有りの場合には、エラーがＦａｔａｌエラーである場合と、救済可能な擬似エラーの場合があり得る。従来のＭＥＳＩ等のプロトコルチェックでエラー有りの場合とは、例えば、現在、Ｈｏｍｅ-ＣＰＵに保持
されているＭＥＳＩの情報に対して、整合性のとれないリクエストパケットをＨｏｍｅ-
ＣＰＵが受信した場合である。以下、擬似エラーとＦａｔａｌエラーを個別に検討する。（Ａ）応答パケットのロストによるエラー（擬似エラー）
整合性のとれないリクエストパケットが発生する例としては、すでに、Ｈｏｍｅ-ＣＰ
Ｕにおいて処理済みのリクエストパケットに対する応答パケット（ＷＲＢＫ／ＦＬＢＫ-
ＣＰＬＴ）がＨｏｍｅ-ＣＰＵからＬｏｃａｌ-ＣＰＵ至る経路でパケットロストとなった場合が想定できる。
【００３１】
このような応答パケットのロストでは、Ｈｏｍｅ-ＣＰＵにおいてリクエストパケット
に対する処理が正常に終了しているにも拘わらず、応答パケットがＬｏｃａｌ-ＣＰＵに
到達していない。このため、Ｌｏｃａｌ-ＣＰＵは、Ｈｏｍｅ-ＣＰＵでの状態が不明なまま、リトライ処理を実行することになる。この場合には、Ｈｏｍｅ-ＣＰＵでのリクエス
トパケットの処理が正常に終了したにも拘わらず、次のリクエストパケットの処理で、リクエストパケットと管理情報との矛盾が生じることがある。このようなエラーは、過去のリクエストパケットに対するＨｏｍｅ-ＣＰＵでの処理が正常に完了していることから、
擬似エラーと呼ぶことができる。
【００３２】
しかし、比較例のコンピュータのように、単に、リトライフラグを設定して、Ｌｏｃａｌ-ＣＰＵがリクエストパケットを送信しただけでは、リクエストパケットと管理情報と
の矛盾は解消できない。したがって、比較例の処理では、応答パケットのロストによる管
理情報の不整合は解消できない。
（Ｂ）応答パケットのロスト以外の原因によるエラー（Ｆａｔａｌエラー）
応答パケットのロスト以外にも様々な原因でプロトコルチェックのエラーは発生し得る。例えば、Ｉ（Ｉｎｖａｌｉｄ）、Ｓ（Ｓｈａｒｅｄ）等の状態でキャッシュに持ち出しているＬｏｃａｌ-ＣＰＵが、Ｈｏｍｅ−ＣＰＵに対してライトバック（ＷＲＢＫ）パケ
ットを送信した場合である。このような応答パケットのロスト以外の原因によるエラーの場合には、比較例のＨｏｍｅ-ＣＰＵは、Ｆａｔａｌエラーを検出する。
【００３３】
しかしながら、比較例のＨｏｍｅ-ＣＰＵは、上記（Ａ）応答パケットのロストによる
エラーと（Ｂ）応答パケットのロスト以外の原因によるエラーを区別することができない。
【００３４】
［実施形態］
以下、実施形態に係る情報処理装置について説明する。本実施形態では、Ｌｏｃａｌ−ＣＰＵのキャッシュ制御部がリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）にリトライフラグ（１ｂｉｔ）を設定し、Ｈｏｍｅ-ＣＰＵに発行するとともにタイマーを起動する。発
行されたリクエストパケットへの応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）の受信前にタイマーが規定値を超えた場合、Ｌｏｃａｌ−ＣＰＵはパケットロストが発生したと判断する。さらに、Ｌｏｃａｌ−ＣＰＵは、パケットロストの原因がＨｏｍｅ-ＣＰＵの
固定故障、あるいは経路の固定故障等であるか否かを判定する。そして、Ｌｏｃａｌ−ＣＰＵは、パケットロストが固定故障によるものではなく、一時的な間欠故障等によるものであると判断した場合には、リクエストパケットを再発行する。リクエストパケットの再発行は、リトライとも呼ばれる。なお、パケットロストが固定故障によるものであるとＬｏｃａｌ−ＣＰＵが判断した場合、リトライは行わない。固定故障時は、リトライしても再び失敗するからである。
【００３５】
リトライによるリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）が送信される場合、Ｈｏｍｅ−ＣＰＵのリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対応する処理が既に実行済みのケースと未実行のケースがある。Ｈｏｍｅ−ＣＰＵは、Ｌｏｃａｌ−ＣＰＵから受信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）と管理情報とのプロトコルチェックにより、上記処理が実行済みか否かを区別して、実行済みの場合にはリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対応する処理を実行せず、未実行の場合はリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対応する処理を実行する。Ｈｏｍｅ−ＣＰＵは第１の演算処理装置の一例である。Ｌｏｃａｌ−ＣＰＵは、第２の演算処理装置の一例である。
【００３６】
図８に、本実施形態に係る情報処理装置の構成を例示する。本情報処理装置は、マルチプロセッサシステムということができる。本情報処理装置は、複数のＣＰＵ１と、複数のメインメモリ２を有する。ＣＰＵ１が演算処理装置の一例である。複数のＣＰＵ１と、複数のメインメモリ２は、個別には、ＣＰＵ１−０、１−１、．．．、１−ｎ、メインメモリ２−０、２−１、．．．、２−ｎ等のように呼ぶことにする。メインメモリ２は、例えば、複数のDual Inline Memory Module（ＤＩＭＭ）を含む。ＣＰＵ１間は、クロスバＬ
ＳＩ等のネットワーク、インターコネクトで接続される。図８では、複数のＣＰＵ１は直列的に接続されているが、ＣＰＵ１間のトポロジーは線状に限定される訳ではない。トポロジーとしては、バス、メッシュ、トーラス等様々なものが適用可能である。ＣＰＵ１−０、１−１、．．．、１−ｎのいずれか１つが第１の演算処理装置、第２の演算処理装置の一例である。例えば、ＣＰＵ１−１は、第１の演算処理装置と接続される第２の演算処理装置の一例である。メインメモリ２−１は、主記憶装置の一例である。
【００３７】
各ＣＰＵ１は、コア１１、キャッシュ１２、キャッシュ制御部１３、メモリ制御部１４を有する。また、コア１１、キャッシュ１２、キャッシュ制御部１３、メモリ制御部１４
は、個別には、コア１１−０、１１−１、．．．、１１−ｎ、キャッシュ１２−０、１２−１、．．．、１２−ｎ、キャッシュ制御部１３−０、１３−１、．．．、１３−ｎ、メモリ制御部１４−０、１４−１、．．．、１４−ｎ等のように呼ぶことにする。コア１１またはＣＰＵ１は、プロセッサ、演算処理装置とも呼ばれる。
【００３８】
コア１１は、ＣＰＵ１の制御、データ処理を実行する。キャッシュ１２は、メインメモリ２上のデータを一時的に格納する。キャッシュ制御部１３は、キャッシュ１２のデータを管理し、他のＣＰＵ１とデータを授受する。メモリ制御部１４は、メインメモリ２にアクセスし、メインメモリ２との間でデータの読み書きを実行する。なお、以下の実施形態では、ＣＰＵ１−０、１−１、．．．、１−ｎのいずれかがＬｏｃａｌ−ＣＰＵとＨｏｍｅ−ＣＰＵになり得る。メモリ制御部１４−１は、主記憶制御装置の一例である。
【００３９】
図９に、ＷＲＢＫ／ＦＬＢＫロストケースの処理を例示する。ＷＲＢＫ／ＦＬＢＫロストケースは、Ｌｏｃａｌ−ＣＰＵからＨｏｍｅ−ＣＰＵに至る経路でパケットロストが発生した場合である。ＷＲＢＫ／ＦＬＢＫロストケースでは、Ｈｏｍｅ−ＣＰＵはリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受信していないため、比較例の場合（図４）の場合と同様、何も実行しない。したがって、Ｌｏｃａｌ−ＣＰＵではタイムアウトが発生する。すると、Ｌｏｃａｌ−ＣＰＵはパケットロストが発生したと判断する。さらに、Ｌｏｃａｌ−ＣＰＵはパケットロストの原因が固定故障か、一時的な間欠故障かを判定する。そして、Ｌｏｃａｌ−ＣＰＵはパケットロストの原因が一時的な間欠故障であると判断した場合には、リトライを実行する。Ｈｏｍｅ−ＣＰＵはリトライによるリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受信すると、通常ケースと同じ動作を実行し、Ｌｏｃａｌ−ＣＰＵへ応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を送信する。
【００４０】
図１０に、ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴロストケースの処理を例示する。ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴロストケースは、Ｈｏｍｅ−ＣＰＵからＬｏｃａｌ−ＣＰＵに至る経路でパケットロストが発生した場合である。ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴロストケースでは、Ｈｏｍｅ−ＣＰＵはリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受信しているため、通常ケースと同じ動作を正常に実行済みである。
【００４１】
本実施形態では、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対する処理を実行済みであるにも拘わらず、Ｈｏｍｅ−ＣＰＵがリトライパケットを受信すると、Ｈｏｍｅ−ＣＰＵは、通常ケースと同じ動作を実行しない。すなわち、Ｈｏｍｅ−ＣＰＵはリクエストパケットに対応する処理を実行せずに、Ｌｏｃａｌ−ＣＰＵへ応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を送信する。
【００４２】
図１１に、Ｌｏｃａｌ−ＣＰＵとＨｏｍｅ−ＣＰＵを含む情報処理装置の処理のフローチャートを例示する。以下、図１１、図１２、図１３は、情報処理装置の処理の手順を例示するが、本実施形態の情報処理装置において、各処理は、基本的には専用のハードウェア回路（図１５、図１６参照）が実行する。ただし、図１１、図１２、図１３の一部をプロセッサがコンピュータプログラムにしたがって実行してもよい。
【００４３】
図１１の処理では、Ｌｏｃａｌ−ＣＰＵは、リトライフラグを設定し、Ｈｏｍｅ−ＣＰＵに対して、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を発行する。さらに、Ｌｏｃａｌ−ＣＰＵは、タイマーを起動する（Ｌ０）。第1回目のリクエストパケット（ＷＲＢＫ
／ＦＬＢＫ）発行時には、Ｌｏｃａｌ−ＣＰＵは、リトライフラグを０に設定する。また、第1回目のリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）においてタイムアウトが発生し
た後の次のリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）発行時には、Ｌｏｃａｌ−ＣＰＵは、リトライフラグを１に設定する
Ｈｏｍｅ−ＣＰＵは、Ｌｏｃａｌ−ＣＰＵからリクエストパケット（ＷＲＢＫ／ＦＬＢ
Ｋ）を受信する（Ｈ１）。そして、Ｈｏｍｅ−ＣＰＵは、Ｈｏｍｅ−ＣＰＵの管理情報に基づいてＬｏｃａｌ−ＣＰＵから受信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）のプロトコルチェックを行う（Ｈ２）。Ｈ２のプロトコルチェックとは、従来のプロトコルチェックであり、例えば、ＭＥＳＩプロトコルによるチェック、ＭＳＩプロトコルによるチェック、ＭＯＳＩプロトコルによるチェック、ＭＯＥＳＩプロトコルによるチェック等である。
【００４４】
Ｈ２のプロトコルチェックでエラー無しの場合、Ｈｏｍｅ−ＣＰＵは、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対応する処理を実行する（Ｈ３）。例えば、Ｈｏｍｅ−ＣＰＵは、ＷＲＢＫリクエストに対してメインメモリ上のデータと管理情報を更新する。また、例えば、Ｈｏｍｅ−ＣＰＵは、ＦＬＢＫリクエストに対して管理情報を更新する。Ｈ２のプロトコルチェックでエラー無しは、チェック部によるチェックの結果、前記管理状態と前記受信した更新要求とが所定の基準により整合する関係にあることの一例である。Ｈ３の処理は、主記憶装置のデータ書き換え指示を含むときに、前記主記憶装置のデータを書き換えるデータ更新部の処理の一例である。
【００４５】
そして、Ｈｏｍｅ−ＣＰＵは、Ｌｏｃａｌ−ＣＰＵへ応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を送信する（Ｈ４）。応答パケットのリトライフラグには、受信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）と同じ値が設定される。そして、Ｈｏｍｅ−ＣＰＵは、処理を正常終了する。Ｈ４の処理は、第２の演算処理装置に前記更新要求が正常に終了したことを示す完了応答を送信することの一例である。また、Ｈ４の処理は、応答パケット送信部が前記更新要求にリトライを示す情報が付与されているか否かに拘わらず、前記第２の演算処理装置に前記更新要求が正常に終了したことを示す完了応答を送信することの一例でもある。
【００４６】
一方、Ｈ２のプロトコルチェックでエラー有りの場合で（Ｈ２でＮＯ）、かつ、Ｌｏｃａｌ−ＣＰＵから受信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）内のリトライフラグが０の場合には（Ｈ５でＹＥＳ）、Ｈｏｍｅ−ＣＰＵは、致命的なプロトコル矛盾が生じたと判断し、Ｆａｔａｌエラーをエラー制御部へ通知し、処理を異常終了する。ここで、Ｆａｔａｌエラーは動作継続不可能なエラーである。Ｈ２のプロトコルチェックでエラー有りの場合は、チェック部によるチェックの結果、前記管理状態と前記受信した更新要求とが前記所定の基準により整合する関係にないことの一例である。Ｈ５でＹＥＳの場合が、受信した更新要求にリトライを示す情報が付与されていない場合の一例である。
【００４７】
さらに、Ｈ２のプロトコルチェックでエラー有りの場合で（Ｈ２でＮＯ）、かつ、Ｌｏｃａｌ−ＣＰＵから受信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）内のリトライフラグが１の場合には（Ｈ５でＮＯ）、ＦａｔａｌエラーとＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴロストケースによる擬似エラーの２通りが考えられる。Ｈ５でＮＯの場合は、更新要求にリトライを示す情報が付与されていることの一例である。
【００４８】
本実施形態では、Ｈｏｍｅ−ＣＰＵは、初回パケット受信時のリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対する処理が処理済みか否かを判定する（Ｈ６）。初回パケットとは、現在処理中のリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）が第２回目以降のリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）受信であった場合の前回以前に受信済みの同一リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）をいう。
【００４９】
Ｈ６の判定で処理済みの状態であれば、Ｈｏｍｅ−ＣＰＵは、「ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴロストケース」であると判断する。すなわち、Ｈｏｍｅ−ＣＰＵは、（ａ）Ｈ２のプロトコルチェックでエラーがある（ｂ）Ｌｏｃａｌ−ＣＰＵから受信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）内のリトライフラグが１である（ｃ）初回パケット受信
による処理が完了済みである、という３つの条件が充足されると、検出したエラーは実際には問題がないので無視する。エラーを無視する場合、Ｈｏｍｅ−ＣＰＵは何も実行せずに、Ｌｏｃａｌ−ＣＰＵへ応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を送信する（Ｈ４）。応答パケットのリトライフラグは、受信したＷＲＢＫ／ＦＬＢＫと同じ値が設定される。そして、Ｈｏｍｅ−ＣＰＵは処理を正常終了とする。ここで、上記（ａ）（ｂ）（ｃ）の条件が充足される場合のエラーは、疑似エラーと呼ぶことにする。Ｈ６の判定で処理済みの状態であることは、受信した更新要求が前記管理状態を第１の状態から第２の状態に更新するものであり、かつ、管理情報がすでに第２の状態に更新済みとなっている場合の一例である。
【００５０】
一方、Ｈ６の処理で初回パケット受信時のリクエストパケットに対する処理が処理済みでない場合（Ｈ６でＮＯ）、Ｈｏｍｅ−ＣＰＵは、検出したエラーは想定外の事象であると判定する。そして、Ｈｏｍｅ−ＣＰＵは、Ｆａｔａｌエラーをエラー制御部へ通知して、処理を異常終了する。異常終了を含むＨｏｍｅ−ＣＰＵの処理の詳細は図１４にしたがって後述する。
【００５１】
Ｌｏｃａｌ−ＣＰＵは、タイマーが閾値に達するまでに、Ｈｏｍｅ−ＣＰＵから応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を受信したか否かを判定する（Ｌ３）。Ｌｏｃａｌ−ＣＰＵは、応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を受信できなかった場合、エラー処理を実行する（Ｌ２）。そして、リトライ可能な場合には、Ｌｏｃａｌ−ＣＰＵは、制御をＬ０に戻す。一方、Ｌ３の判定で、Ｌｏｃａｌ−ＣＰＵは、応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を受信できた場合には、終了処理を実行する（Ｌ４）。Ｌ２およびＬ４の処理を含むＬｏｃａｌ−ＣＰＵの処理の詳細は図１２にしたがって後述する。
【００５２】
図１２に、Ｌｏｃａｌ−ＣＰＵの処理のフローチャートを例示する。この処理では、Ｌｏｃａｌ−ＣＰＵは、まず、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）内のリトライフラグを値０に設定する（Ｌ１１）。次に、Ｌｏｃａｌ−ＣＰＵは、Ｈｏｍｅ−ＣＰＵに対して、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を発行するとともに、タイマーを起動する（Ｌ１２）。そして、図１１で説明したように、Ｌｏｃａｌ−ＣＰＵは、タイマーが閾値に達するまでに、Ｈｏｍｅ−ＣＰＵから応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を受信したか否かを判定する（Ｌ１３）。
【００５３】
Ｈｏｍｅ−ＣＰＵから応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を受信できた場合、Ｌｏｃａｌ−ＣＰＵは、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に設定したリトライフラグと応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）から得られたリトライフラグが一致しているか否かを判定する（Ｌ１４）。そして、Ｌ１４の判定で、両方のリトライフラグが一致する場合には、Ｌｏｃａｌ−ＣＰＵは、処理を正常終了する。一方、Ｌ１４の判定で、両方のリトライフラグが一致しない場合には、Ｌｏｃａｌ−ＣＰＵは、Ｆａｔａｌエラーを検出したことをエラー制御部（図１５参照）へ通知し、処理を異常終了する（Ｌ１７）。
【００５４】
Ｈｏｍｅ−ＣＰＵから応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を受信していない場合、Ｌｏｃａｌ−ＣＰＵは、パケットロストの原因を判定する（Ｌ１５）。すなわち、（ｉ）パケットロストの原因はＨｏｍｅ−ＣＰＵの固定故障、経路の固定故障等である、（ｉｉ）パケットロストの原因は一時的な間欠故障であって、故障はリトライで復帰可能なものである、という２つを選択的に判断する。
【００５５】
ＣＰＵ間経路の断線やＣＰＵ故障等、リトライしても解決しないケースがあるので、リトライで復帰可能なケースか否かが判定される。判定方法には様々な方法が考えられるが
、例えば、Ｌｏｃａｌ−ＣＰＵは、下記の条件（１）から（３）のいずれかに該当する時にはリトライを実行すればよい。
（１）第１は新規にエラー検出した場合である。
（２）第２はリトライ回数をカウントし、閾値に達するまでのエラーの場合である。
（３）第３はＣＰＵ間経路が冗長化されている場合で、現時点が冗長経路の縮退シーケンス実行時に該当する場合である。縮退シーケンス実行時には、一時的にパケットロストが起きる可能性があるからである。
【００５６】
リトライか否かに応じて、Ｈｏｍｅ−ＣＰＵが動作を変更することを可能にするために、Ｌｏｃａｌ−ＣＰＵは、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）にリトライフラグを設定する。すなわち、Ｌｏｃａｌ−ＣＰＵは、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を第１回目に送信する時には、リトライフラグを０とし、リトライで送信する時にはリトライフラグを１に設定する。
【００５７】
以上の判断の結果、Ｌｏｃａｌ−ＣＰＵは、（ｉｉ）のように、パケットロストの原因が一時的な間欠故障であると判断した場合には、リトライフラグを１に設定し（Ｌ１６）、処理をＬ１２に戻す。Ｌｏｃａｌ−ＣＰＵが、Ｌ１５の判定で、リトライで復帰可能なケースと判定し、Ｌ１６の処理を実行することが、リトライを示す情報を設定した次の更新要求を前記第１の演算処理に送信するリトライ処理を所定の限度まで繰り返すことの一例である。また、Ｌ１５の判定で、上記（１）から（３）を判定することが、リトライの回数、および前記第１の演算処理装置と第２の演算処理装置との接続状態を含む前記情報処理装置の稼働状態の少なくとも一方により判定することの一例である。上記「縮退シーケンス実行」は、第１の演算処理装置と第２の演算処理装置との接続状態を含む前記情報処理装置の稼働状態の一例である。一方、Ｌｏｃａｌ−ＣＰＵは、（ｉ）のように、パケットロストの原因が固定故障であると判断した場合には、例えば、Ｈｏｍｅ−ＣＰＵが固定故障したことをエラー制御部へ通知し（Ｌ１８）、処理を異常終了する。
【００５８】
図１３に、Ｈｏｍｅ−ＣＰＵの処理のフローチャートを例示する。図１３において、Ｈ１からＨ６の処理は、図１１のＨ１からＨ６と同様であるので、その説明を省略する。Ｈ５の判定で、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に設定されたリトライフラグが０の場合には、Ｈｏｍｅ−ＣＰＵは、Ｆａｔａｌエラーを検出したことをエラー制御部（図１６参照）へ通知し（Ｈ７）、処理を異常終了する。リトライフラグが０の場合は、受信した更新要求にリトライを示す情報が付与されていない場合の一例である。Ｈ７の処理は、所定の通知先にエラーを通知することの一例である。
【００５９】
また、Ｈ２のプロトコルチェックでエラー有りの場合で（Ｈ２でＮＯ）、かつ、Ｌｏｃａｌ−ＣＰＵから受信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）内のリトライフラグが１の場合で（Ｈ５でＮＯ）には、Ｈｏｍｅ−ＣＰＵはＨ６の判定を実行する。すなわち、Ｈ６の判定で初回パケット受信時のリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対する処理が処理済みでない場合（Ｈ６でＮＯ）、図１１で説明したように、Ｈｏｍｅ−ＣＰＵは、検出したエラーは想定外の事象であると判定する。そして、Ｈｏｍｅ−ＣＰＵは、Ｆａｔａｌエラーをエラー制御部へ通知して（Ｈ７）、処理を異常終了する。Ｈ７の処理は、応答パケット送信部が所定の通知先にエラーを通知することの一例である。
【００６０】
一方、Ｈ６の判定で初回パケット受信時のリクエストパケットに対する処理が処理済みである場合（Ｈ６でＹＥＳ）、Ｈｏｍｅ−ＣＰＵは、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）に対応する処理の実行をスキップする。すなわち、Ｈｏｍｅ−ＣＰＵは、メインメモリ上のデータの更新、管理情報の更新等をスキップする（Ｈ８）。そして、Ｈｏｍｅ−ＣＰＵは、応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）のリトライフラグに受信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）と同じ値を設定し、Ｌｏｃａｌ−ＣＰＵに
送信し（Ｈ９）、処理を正常終了する。Ｈ９の処理は、第２の演算処理装置に前記更新要求が正常に終了したことを示す完了応答を送信することの一例である。
【００６１】
図１４に、本実施形態のエラーの分類を例示する。図１４では、図７の分類において「従来のプロトコルチェックでエラー有り」とされていた分類がさらに２分類されている。すなわち、図１４の分類では、新たに、「パケット受信では起こり得ない状態」が追加されている。ここで、「パケット受信では起こり得ない状態」とは、上記「（２）応答パケットのロスト以外の原因によるエラー（Ｆａｔａｌエラー）」で例示した状態である。例えば、Ｉ（Ｉｎｖａｌｉｄ）、Ｓ（Ｓｈａｒｅｄ）等の状態でメモリ２のデータをキャッシュ１２に持ち出しているＬｏｃａｌ-ＣＰＵがライトバック（ＷＲＢＫ）パケットを送
信した場合である。このようなＦａｔａｌエラーは、リトライフラグの値（０、１）のいずれにおいても発生し得る。また、このようなＦａｔａｌエラーは、Ｈｏｍｅ−ＣＰＵが初回のリクエストパケットを受信した場合、リトライによる再度のリクエストパケットを受信した場合の両方で生じ得る。なお、ＷＲＢＫロストケースの場合には、Ｈｏｍｅ−ＣＰＵは初回のリクエストパケットをリトライフラグ＝１の設定で受信することが有り得る。
【００６２】
また、「従来のプロトコルチェックでエラー有り」とされていた分類で、「パケット受信では起こりえない状態」以外の分類では、さらに２つの場合を含む。すなわち、第１はリトライフラグ：０のときのＦａｔａｌエラーである。また、第２はリトライフラグ：１のときの擬似エラーである。リトライフラグ：１のときの擬似エラーは、応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）ロストケースで発生する。本実施形態のＨｏｍｅ−ＣＰＵは、リトライフラグ：１のときの擬似エラーを検出できる。すなわち、ＭＥＳＩプロトコル等の従来のプロトコルチェックでエラー有りの場合、本実施形態のＨｏｍｅ−ＣＰＵは、図１３のＨ６の判定で例示したように、リトライフラグ＝１の場合に、Ｆａｔａｌエラーと疑似エラー（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴロストケース）を区別できる。
【００６３】
図１５に、Ｌｏｃａｌ−ＣＰＵの処理を実行する制御回路を例示する。また、図１６に、Ｈｏｍｅ−ＣＰＵの処理を実行する制御回路を例示する。ただし、図８で説明したように、ＣＰＵ１は、Ｌｏｃａｌ−ＣＰＵにも、Ｈｏｍｅ−ＣＰＵにもなり得るため、各ＣＰＵ１は、図１５と図１６の両方の回路を有してよい。すなわち、図１５は、ＣＰＵ１の処理回路のうち、Ｌｏｃａｌ−ＣＰＵの処理を実行する制御回路の部分を例示したものである。また、図１６は、ＣＰＵ１の処理回路のうち、Ｈｏｍｅ−ＣＰＵの処理を実行する制御回路の部分を例示したものである。
【００６４】
図１５では、Ｌｏｃａｌ−ＣＰＵのキャッシュ制御部１３とエラー制御部３―Ｌが例示されている。キャッシュ制御部１３は、制御情報格納部１３１、データ格納部１３２、リクエストパケット送信部１３３、応答パケット受信部１３４、タイムアウト検出部１３５、プロトコルチェック部１３６、リトライ可否判定部１３７、固定故障通知部１３８を有する。
【００６５】
制御情報格納部１３１は、コア１１からの指令にしたがったキャッシュ制御を実行するための制御情報を格納する。データ格納部１３２は、例えばメインメモリ２へ書き戻すキャッシュのデータを格納する。リクエストパケット送信部１３３は、制御情報格納部１３１からリトライフラグを含む制御情報を取り出す。また、リクエストパケット送信部１３３は、Ｈｏｍｅ−ＣＰＵに送信するリクエストパケットがＷＲＢＫ等のＨｏｍｅ−ＣＰＵのメインメモリ２へのデータを伴うリクエストパケットの場合には、データ格納部１３２からデータを取り出す。そして、リクエストパケット送信部１３３は、リトライフラグを含むリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を生成し、Ｈｏｍｅ−ＣＰＵへ送信する。
【００６６】
応答パケット受信部１３４は、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受信したＨｏｍｅ−ＣＰＵが生成する応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を受信する。
【００６７】
タイムアウト検出部１３５は、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を送信すると、タイマーを起動し、応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を受信するとタイマーをクリアする。応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）受信前にタイマーが設定されている閾値に達すると、タイムアウト検出部１３５は、タイムアウトを検出する。
【００６８】
プロトコルチェック部１３６は、Ｈｏｍｅ−ＣＰＵから受信した応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）のリトライフラグと制御情報格納部１３１のリトライフラグを比較してプロトコルチェックを行う。そしてプロトコルチェックの結果、２つのリトライフラグが一致する場合には、プロトコルチェック部１３６は、エラー無し、と判定する。また、２つのリトライフラグが不一致の場合には、プロトコルチェック部１３６は、Ｆａｔａｌエラーと判定し、Ｆａｔａｌエラーをエラー制御部３−Ｌへ通知する。例えば、プロトコルチェック部１３６は、エラー制御部３−Ｌの所定のレジスタへエラービットをセットする。
【００６９】
リトライ可否判定部１３７はタイムアウト検出時、リトライ可否判定情報を参照する。リトライ可否判定情報とは、例えば、ＣＰＵ毎の固定故障を示すレジスタ、ＣＰＵ間で故障が発生したことを示す外部からの通知信号等のことである。宛先となるＨｏｍｅ−ＣＰＵの固定故障あるいは経路の固定故障のためリトライ不可能と判定すると、リトライ可否判定部１３７は、宛先となるＨｏｍｅ−ＣＰＵが固定故障したことを固定故障通知部１３８に伝達する。リトライ可否判定部１３７はリトライ可能と判定すると、制御情報格納部にリトライフラグをセットし、パケット再発行制御を開始する。固定故障通知部１３８は、リトライ不可能の場合、Ｈｏｍｅ−ＣＰＵが固定故障したものと判定し、Ｈｏｍｅ−ＣＰＵが固定故障したことをエラー制御部３−Ｌへ通知する。
【００７０】
エラー制御部３−Ｌは、キャッシュ制御部１３を含むＬｏｃａｌ−ＣＰＵ内全体でハードウェアが検出したエラーを収集し、エラー制御を行う。例えば、エラー制御部３―Ｌは、複数のＣＰＵ１を含む情報処理装置を管理する管理装置にエラーの発生、エラーの発生箇所、エラーの種別、エラーの原因等を通知する。
【００７１】
図１６では、Ｈｏｍｅ−ＣＰＵのメモリ制御部１４とエラー制御部３―Ｈが例示されている。メモリ制御部１４は、リクエストパケット受信部１４１、管理情報格納部１４２、プロトコルチェック部１４３、管理情報更新部１４４、メインメモリデータ更新部１４５、および応答パケット送信部１４６を有する。
【００７２】
リクエストパケット受信部１４１は、Ｌｏｃａｌ−ＣＰＵが送信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）を受信する。リクエストパケット受信部１４１は、管理情報の更新を要求する更新要求を受信する受信部の一例である。管理情報格納部１４２は、メインメモリ２のデータの持ち出しに関する管理情報を格納する。管理情報格納部１４２は、第２の演算処理装置に持ち出されたデータの変更の有無を含む管理状態を示す管理情報を保持する管理情報格納部の一例である。プロトコルチェック部１４３は、Ｌｏｃａｌ−ＣＰＵから受信したリクエストパケット（ＷＲＢＫ／ＦＬＢＫ）と管理情報格納部１４２の管理情報を比較してプロトコルチェックを行う。プロトコルチェック部１４３は、プロトコルチェックにより、Ｆａｔａｌエラー、リトライパケットにおける疑似エラー、エラー無し、のいずれかを判定する。プロトコルチェック部１４３は、管理情報が示す管理状態
と前記受信した更新要求とが所定の関係を満たすか否かを判定するチェック部の一例である。
【００７３】
管理情報更新部１４４は、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）がプロトコルチェック部１４３でエラー無しの場合、管理情報を更新する。メインメモリデータ更新部１４５は、データ付きのリクエストパケット（ＷＲＢＫ）がプロトコルチェック部１４３でエラー無しの場合、メインメモリ上のデータを更新する。管理情報更新部１４４は、「所定の基準により整合する関係にある前記更新要求が前記主記憶装置のデータ書き換え指示（ＷＲＢＫ）を含むときに、前記主記憶装置のデータを書き換えるデータ更新部」の一例である。応答パケット送信部１４６は、リクエストパケット（ＷＲＢＫ／ＦＬＢＫ）がプロトコルチェック部１４３でエラー無し、またはリトライパケットでの疑似エラーの場合、リトライフラグを含む応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）を生成し、Ｌｏｃａｌ−ＣＰＵへ送信する。応答パケット送信部１４６は、第２の演算処理装置に前記更新要求が正常に終了したことを示す完了応答を送信する応答パケット送信部の一例である。
【００７４】
エラー制御部３−Ｈは、メモリ制御部１４を含むＨｏｍｅ−ＣＰＵ内全体でハードウェアが検出したエラーを収集し、エラー制御を行う。エラー制御部３−Ｈの処理は、図１４のエラー制御部３−Ｌと同様である。
【００７５】
なお、図８に例示のように、複数のＣＰＵ１間には、クロスバＬＳＩ等のインターコネクトが設けられている。すなわち、Ｌｏｃａｌ−ＣＰＵとＨｏｍｅ−ＣＰＵとはインターコネクトで接続することが想定されている。この場合に、Ｌｏｃａｌ−ＣＰＵとＨｏｍｅ−ＣＰＵとは、別の筐体内に実装されてもよいし、同一の筐体に実装されてもよい。すなわち、Ｌｏｃａｌ−ＣＰＵとＨｏｍｅ−ＣＰＵとが、別の筐体内に実装された場合で、同一の筐体に実装された場合にも、図１５、図１６の構成により、情報処理装置は、本実施形態によるプロトコルチェックおよび疑似エラーの検出を実行できる。
【００７６】
以上のような機構とすることで、本情報処理装置は、応答パケット（ＷＲＢＫ／ＦＬＢＫ−ＣＰＬＴ）ロストケースにおいても、管理情報の制御矛盾やデータ消失を生じさせる可能性を低減し、疑似エラーを検出できる。すなわち、Ｌｏｃａｌ−ＣＰＵのキャッシュ１２に持ち出されたデータのメインメモリへの書き戻し制御（ＷＲＢＫ／ＦＬＢＫ）において、本情報処理装置は、ＣＰＵ間の間欠故障等によりリクエストパケットを正しく転送できなかった場合に、制御矛盾やデータ消失を生じさせることなく正常動作に復帰する可能性を高めることができる。
【００７７】
また、本情報処理装置は、図１１または図１３のＨ２の判定において、管理情報に基づく従来のプロトコルチェックでエラーがない場合には、リトライフラグの示す状態によらず、正常と判断することで、ＷＲＢＫ／ＦＬＢＫロストケースにおいて、Ｈｏｍｅ−ＣＰＵは、処理を正常終了することができる（図１１のＨ４、図１３のＨ９）。
【００７８】
また、本情報処理装置は、図１１または図１３のＨ２の判定において、管理情報に基づく従来のプロトコルチェックでエラーがあり、かつ、リトライフラグがリトライでないことを示す場合には、Ｆａｔａｌエラーが発生したと判定できる。
【００７９】
また、本情報処理装置は、図１１または図１３のＨ２の判定において、管理情報に基づく従来のプロトコルチェックでエラーがあり、かつ、リトライフラグがリトライを示す場合で、初回のパケット受信による処理が処理済みでない場合には（Ｈ６でＮＯ）、Ｆａｔａｌエラーが発生したと判定できる。
【００８０】
また、本情報処理装置で、Ｌｏｃａｌ−ＣＰＵは、図１２のＬ１５のように、パケットロストの原因を判定することで、適正にリトライを実施できる。また、Ｌｏｃａｌ−ＣＰＵは、リトライ処理を所定の限度まで繰り返すことができる。
【００８１】
また、本情報処理装置のＬｏｃａｌ−ＣＰＵは、図１２のＬ１５のように、新規にエラー検出時、リトライ回数が閾値に達するまでの間、あるいは、ＣＰＵ間経路が冗長化されている等が判断できた場合には、適正にリトライを実施できる。
【符号の説明】
【００８２】
１    ＣＰＵ
２    メインメモリ
１１    コア
１２    キャッシュ
１３    キャッシュ制御部
１４    メモリ制御部
１３１  制御情報格納部
１３２  データ格納部
１３３  リクエストパケット送信部
１３４  応答パケット送信部
１３５  タイムアウト検出部
１３６  プロトコルチェック部
１３７  リトライ可否判定部
１３８  固定故障検知部
１４１  リクエストパケット受信部
１４２  管理情報格納部
１４３  プロトコルチェック部
１４４  管理情報更新部
１４５  メインメモリデータ更新部
１４６  応答パケット送信部
【図１】
0006493193.tif 000002
【図２】
0006493193.tif 000003
【図３】
0006493193.tif 000004
【図４】
0006493193.tif 000005
【図５】
0006493193.tif 000006
【図６】
0006493193.tif 000007
【図７】
0006493193.tif 000008
【図８】
0006493193.tif 000009
【図９】
0006493193.tif 000010
【図１０】
0006493193.tif 000011
【図１１】
0006493193.tif 000012
【図１２】
0006493193.tif 000013
【図１３】
0006493193.tif 000014
【図１４】
0006493193.tif 000015
【図１５】
0006493193.tif 000016
【図１６】
0006493193.tif 000017