JP4144986B2 - 情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法 - Google Patents
情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法 Download PDFInfo
- Publication number
- JP4144986B2 JP4144986B2 JP35372899A JP35372899A JP4144986B2 JP 4144986 B2 JP4144986 B2 JP 4144986B2 JP 35372899 A JP35372899 A JP 35372899A JP 35372899 A JP35372899 A JP 35372899A JP 4144986 B2 JP4144986 B2 JP 4144986B2
- Authority
- JP
- Japan
- Prior art keywords
- transaction
- retry
- address
- excessive
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Bus Control (AREA)
- Memory System (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法に係り、特に、トランザクションリトライを行なう情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法に関する。近年、大規模サーバの需要が高まっているにしたがって、大量のデータ処理能力と高い信頼性をもつ、マルチプロセッサシステムの出現が望まれている。
【０００２】
マルチプロセッサシステムの性能を向上するための最も重要な要素の一つとしてシステムバスの高速化がある。システムバスを高速化するための手法としてシステムバスのパイプライン化がある。
システムバスのパイプライン化は、バスのスループットを向上させることができる。一方、エラーが発生した場合、処理の流れが滞るので性能低下が著しい。このため、エラーが発生した場合の性能低下を避ける手法が提案されている。
【０００３】
この手法の一つとしてリトライ処理がある。リトライ処理は、エラーを起こしたアドレストランザクションを再び発行して失敗した処理を再開する処理である。リトライ処理は、マルチプロセッサシステムの性能に大きく影響する重要な要素である。したがって、このようなリトライ処理には、高性能、高信頼性が望まれている。
【０００４】
【従来の技術】
パイプイン化されたシステムバスは、アドレストランザクションを複数の段階に分けて、それぞれの段階に対応するバスが独立に異なるトランザクションを処理できるように構成されている。すなわち、パイプライン化されていた。
また、マルチプロセッサシステムでは、共有メモリ型マルチプロセッサシステムが主流を占めている。共有メモリ型マルチプロセッサシステムは、複数のプロセッサが共通のメモリにアクセスするため、システム全体でアドレススヌープを行なって、コヒーレンスを保つようにしていた。
【０００５】
上記のようなシステムでは、大別して二種類のエラーが存在する。一つは、システム故障等によるエラー、もう一つはアドレス競合などによる通常動作時に頻繁に起こるエラーである。
後者のアドレス競合は、同一アドレスに対して連続してトランザクションが発行された場合に、先行して発行されたトランザクションの処理結果の反映が後に発行されたトランザクションの参照に間に合わない場合に生じる。
【０００６】
このようなエラーの対処方法は、２つある。一つは、後に発行されたトランザクションが処理可能になるまでのバスを一時的に停止する方法である。もう一つは、後に発行されたトランザクションを打ち切り、再度同一のアドレスをバスに発行する方法である。
後者の対処方法は、アドレスリトライと呼ばれている。このアドレスリトライを実現する機構は、アドレスリトライ機構と呼ばれている。従来のマルチプロセッサシステムの多くは、システムの能力低下を防ぐためにアドレスリトライ機構が搭載されていた。
【０００７】
図１はマルチプロセッサシステムのブロック構成図を示す。
マルチプロセッサシステム１は、プロセッサ２−１〜２−Ｎ、共有メモリ３、入出力装置４、バス制御部５、システムバス６から構成される。
プロセッサ２−１〜２−Ｎは、命令に応じた演算を実行する。
メモリ３は、Ｎ個のプロセッサ２−１〜２−Ｎとシステムバス６を介して接続されており、Ｎ個のプロセッサ２−１〜２−Ｎからアクセス可能とされており、Ｎ個のプロセッサ２−１〜２−Ｎで共有して用いられる。
【０００８】
入出力装置４は、キーボード、マウス、ディスプレイ、プリンタ、通信装置などから構成される。入出力装置４は、データの入出力、処理の指示入力、処理結果の入出力が行なわれる。
バス制御部５は、Ｎ個のプロセッサ２−１〜２−Ｎ、入出力装置４に接続され、バス６の使用権を制御する。バス６は、Ｎ個のプロセッサ２−１〜２−Ｎ、メモリ３、入出力装置４間のデータの伝送に用いられる。
【０００９】
図２は従来の一例の要部の構成図を示す。
プロセッサ２−Ｘは、Ｎ個のプロセッサ２−１〜２−Ｎのうち、一つのプロセッサを示す。プロセッサ２−Ｘとバス制御部５とは、バス６により接続されている。バス６は、アドレスバス１１、１２、ステータスバス１３、１４、データバス１５から供給される。
【００１０】
アドレスバス１１は、プロセッサ２−Ｘからバス制御部５にアドレスを伝送する。アドレスバス１１で伝送されるアドレスは、例えば、プロセッサ２−Ｘで発行されたトランザクションのアドレスである。
アドレスバス１２は、バス制御部５からプロセッサ２−Ｘにアドレスを伝送する。アドレスバス１２で伝送されるアドレスは、例えば、バス制御部５で調停され、バス６の使用が許可されたアドレスである。
【００１１】
ステータスバス１３は、プロセッサ２−Ｘからバス制御部５にプロセッサ２−Ｘのステータスを供給する。ステータスバス１３を伝送されるステータスは、プロセッサ２−Ｘでキャッシュスヌープを行なった結果を伝送する。
ステータスバス１４は、バス制御部５からプロセッサ２−Ｘにテータスを供給する。ステータスバス１４を伝送されるステータスは、Ｎ個のプロセッサ２−１〜２−Ｎでのキャッシュスヌープの結果を合成したものが伝送される。データバス１５は、キャッシュスヌープ結果に応じてデータを転送する。
【００１２】
次に、従来のアドレストランザクション処理の動作について説明する。
プロセッサ２−Ｘは、演算部２１、アドレス制御部２２、スヌープ制御部２３から構成される。
演算部２１は、データ処理を行ない、データ処理の結果に応じてアドレストランザクションを要求する。アドレス制御部２２は、演算部２１からのアドレストランザクションの要求に応じてアドレスを発行する。
アドレス制御部２２は、キュー発行部２２ａ、リトライ制御部２２ｂ、カウント部２２ｃを有する。キュー発行部２２ａは、アドレストランザクションに応じてアドレスを発行する。
【００１３】
リトライ制御部２２ｂは、演算部２１、スヌープ制御部２３、バス制御部５に接続されている。リトライ制御部２２ｂは、スヌープ制御部２３からのリトライ指示に応じてキュー発行部２２ａを制御する。
このとき、リトライ制御部２２ｂには、演算部２１からのリトライ回数、タイムアウト時間が設定され、カウント部２２ｃからは、リトライ回数、タイムアウト時間が供給される。リトライ制御部２２ｂは、カウント部２２ｃのからのリトライ回数又はタイムアウト時間が演算部２１によって設定されたリトライ回数又はタイムアウト時間になるまで、リトライを繰り返す。
【００１４】
また、リトライ制御部２２ｂには、バス制御部５からバス６の使用状況に関する情報が供給される。リトライ制御部２２ｂは、バス制御部５からの情報に応じてリトライ頻度を制御する。
カウント部２２ｃは、リトライ回数、タイムアウト時間をカウントする。リトライ制御部２２ｂは、カウント部２２ｃからのリトライ回数、タイムアウト時間を参照して、所定の回数並びに所定の時間に制限する。
【００１５】
スヌープ制御部２３は、バス制御部５からアドレスに応じてキャッシュステータスを求める。また、スヌープ制御部２３は、バス制御部５からのシステム全体のキャッシュステータスに応じてデータの転送を制御するとともに、アドレスリトライの指示を発行する。
次に、アドレストランザクションの発生時の動作を図面とともに説明する。
ステップＳ１で、プロセッサ２−Ｘの演算部２１からアドレストランザクションが発生される。演算部２１からのアドレストランザクションは、アドレス制御部２２のキュー発行部２２ａに供給される。
【００１６】
ステップＳ2 で、キュー発行部２２ａから演算部２１からのアドレストランザクションに応じたアドレスが発行される。キュー発行部２２ａから発行されたアドレスは、バス制御部５にアドレスを供給される。
ステップＳ3 で、バス制御部５によりプロセッサ２−Ｘからのアドレスがプロセッサ２−１〜２−Ｎのアドレスバス１２に供給される。
【００１７】
ステップＳ4 では、プロセッサ２−１〜２−Ｎにより、バス制御部５からのアドレスに対してキャッシュステータスが求められる。
プロセッサ２−１〜２−Ｎは、キャッシュステータスをバス制御部５に供給する。
ステップＳ5 は、バス制御部５での処理であり、プロセッサ２−１〜２−Ｎからのキャッシュステータスを合成してシステム全体のキャッシュステータスが求められる。
【００１８】
ステップＳ６は、バス制御部５の処理であり、システム全体のキャッシュステータスをプロセッサ２−１〜２−Ｎに供給する。プロセッサ２−Ｘは、バス制御部５からシステム全体のキャッシュステータスを受信する。
ステップＳ７は、プロセッサ２−Ｘでの処理であり、バス制御部５からのシステム全体のキャッシュステータスに基づいてデータの転送制御が行なわれる。
【００１９】
なお、上記ステップS １〜Ｓ７は、プロセッサ２−１〜２−Ｎで発生される各トランザクションに対して行なわれる。ステップS １〜Ｓ７をパイプライン的に処理することにより処理の多重度を向上でき、高速化が可能となる。
図３は従来の一例のパイプライン処理の動作説明図を示す。
図３において、ＡＴ１〜ＡＴ３はトランザクションを示す。トランザクションＡＴ１は、時刻ｔ１でステップＳ２、次の時刻ｔ２でステップＳ３、次の時刻ｔ３でステップＳ４、次の時刻ｔ４でステップＳ５、次の時刻ｔ５でステップＳ６、次の時刻ｔ６でステップＳ７が実行される。トランザクションＡＴ２は、時刻ｔ２でステップＳ２、次の時刻ｔ３でステップＳ３、次の時刻ｔ４でステップＳ４、次の時刻ｔ５でステップＳ５、次の時刻ｔ６でステップＳ６、次の時刻ｔ７でステップＳ７が実行される。トランザクションＡＴ３は、時刻ｔ３でステップＳ２、次の時刻ｔ４でステップＳ３、次の時刻ｔ５でステップＳ４、次の時刻ｔ６でステップＳ５、次の時刻ｔ７でステップＳ６、次の時刻ｔ８でステップＳ７が実行される。
【００２０】
このように異なるトランザクションＡＴ１〜ＡＴ３は、同一ステップが異なる時刻で処理される。よって、バスを一つのトランザクションで占有することがないので、効率よく処理を行なうことができる。このパイプライン処理の利点を生かすため、アドレスリトライ機構が用いられている。
【００２１】
【発明が解決しようとする課題】
しかしながら、上記システムでは、アドレストランザクションがアドレスリトライ機構によって、リトライされ続けると、処理の時間が長くなり、処理効率が低下する。また、規定のリトライ回数、タイムアウト時間が経過すると、システムに異常があると判定され、システムが停止してしまう等の問題点があった。
【００２２】
本発明は上記の点に鑑みてなされたもので、システムを効率よく、かつ、高い信頼性を持って運用できる情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法を提供することを目的とする。
【００２３】
【課題を解決するための手段】
本発明は、バスに接続された処理手段を有し、該処理手段により前記バスに対してトランザクションの発行を行う情報処理装置において、処理手段は前記処理手段は、検査用トランザクションを発行して、前記トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態を検出する過剰リトライ状態検出手段と、過剰リトライ検出手段により過剰リトライ状態が検出された場合にはバスに対して、過剰リトライ状態でないトランザクションの発行を抑制する処理制御手段とを有することを特徴とする。
本発明によれば、トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態が検出された場合にはバスに対して、過剰リトライ状態でない他のトランザクションの発行を抑制することにより、処理を一定時間内に終了させることを保証でき、よって、処理がタイムアウトし、システムダウンすることを防止できる。
【００２４】
また、本発明によれば、通常処理への影響を低減できる。
【００２５】
さらに、処理制御手段は、複数のトランザクションを複数のグループに分類し、所定のトランザクションが属するグループに含まれる他のトランザクションの要求を抑止することを特徴とする。本発明によれば、処理の要求の抑制を影響が大きい処理だけに限定することができ、関係のない処理への影響は低減できる。
【００２６】
【発明の実施の形態】
図４は本発明の第１実施例のブロック構成図を示す。同図中、図２と同一構成部分には同一符号を付し、その説明は省略する。
本実施例は、リトライ制御部２２ｂの処理が図２とは相違する。また、スヌープ制御部２３にリトライ監視部２３ａを設けてなる。
【００２７】
図５は本発明の第１実施例のリトライ制御部の処理フローチャートを示す。
リトライ制御部２２ｂは、ステップＳ１−１〜Ｓ１−５の処理を実行する。
ステップＳ１−１は、カウント部２２ｃからのリトライ回数が所定のリトライ回数以上になったか否かを判定する。なお、所定のリトライ回数は、演算部２１によって、設定された規定のリトライ回数以下の回数に設定されている。このため、所定のリトライ回数となってもタイムアウトとならず、システムダウンはしない。ステップＳ１−１の判断は、複数の条件の組み合わせで行なわれる。
【００２８】
例えば、第１の条件は、経過時間が演算部２１によって設定されたタイムアウト時間の８０パーセントを越えた場合とする。第２の条件は、プロセッサ数が３２個未満の場合に、リトライ回数が４０回以上になった場合とする。第３の条件は、プロセッサ数が３２個以上の場合に、２０回以上になった場合とする。
ステップＳ１−１で、リトライ回数が規定の回数以上であれば、次に、ステップＳ１−２、Ｓ１−３が実行され、規定の回数以下であれば、次に、ステップＳ１−４が実行される。
【００２９】
ステップＳ１−２は、過剰にリトライされたアドレストランザクションにマーキングを行う。図６は本発明の第１実施例の動作を説明するための図を示す。図６（Ａ）は通常時に発行されるアドレストランザクションの状態、図６（Ｂ）は過剰にリトライされたときに発行されるアドレストランザクションの状態を示す。キュー発行部２２ａは、通常は図６（Ａ）に示すようにアドレストランザクション５１を出力する。また、キュー発行部２２ａは、リトライ制御部２２ｂで過剰リトライが検出されると、リトライ制御部２２ｂからの指示により図６（Ｂ）に示すようにアドレストランザクション５１にマーク６１を発行する。
【００３０】
ステップＳ１−３は、ステップＳ１−２でマークが付与されたアドレスをバス制御部５に通知する。
ステップＳ１−４は、システム過剰リトライ状態か否かを判定する。
ステップＳ１−４でシステムが過剰リトライ状態でなければ、そのまま処理を終了し、アドレスリトライが解消されるまで、リトライを継続する。
【００３１】
また、ステップＳ１−４で、システムが過剰リトライ状態であれば、ステップＳ１−５が実行される。ステップＳ１−５は、リトライ制御部２２ｂを制御して、過剰リトライ状態でない他のトランザクションの発行を抑制する。
ステップＳ１―５で、過剰リトライ状態でないトランザクションの発行を抑制させることに過剰リトライ状態のトランザクションを優先して実行させることができる。よって、タイムアウトを抑制できる。
【００３２】
次に、リトライ監視部２３ａの動作について説明する。
図７は本発明の第１実施例のリトライ監視部の処理フローチャートを示す。
リトライ監視部２３ａは、ステップＳ２−１〜Ｓ２−６を実行する。ステップＳ２−１は、リトライ回数が所定の回数か否かを判定する。ステップＳ２−１でリトライ回数が所定の回数以上になると、次に、ステップＳ２−２が実行される。
【００３３】
ステップＳ２−２は、過剰リトライ状態が検出されていない他のトランザクションのスヌープ結果を強制的リトライ状態にする。
ステップＳ２−３は、強制的リトライ状態か否かを判定する。ステップＳ２−３で、強制リトライ状態と判定された場合には、次に、ステップＳ２−４が実行される。
【００３４】
ステップＳ２−４は、リトライ制御部２２ａに過剰リトライ状態である旨の通知を行なう。
ステップＳ２−５は、過剰リトライ状態が解消したか否かが判断される。ステップＳ２−５で過剰リトライ状態である旨判断されると、次に、ステップＳ２−６が実行される。
【００３５】
ステップＳ２−６は、ステップＳ２−４でリトライ制御部２２ａに通知した過剰リトライ状態である旨の通知を解除する。
リトライ監視部２３ａにより、過剰でないリトライ状態のアドレストランザクションについては、強制的にリトライ状態とされる。よって、過剰なリトライ状態のアドレストランザクションが優先して実行される。このため、システムがタイムアウトしてシステムダウンする確率を低減することができる。
【００３６】
ここで、過剰ステップＳ２−１の過剰リトライ状態の判定方法について説明する。
過剰リトライ状態の判定は、リトライ制御部２２ｂに設けられたカウンタC ０１及びカウンタC ０２のカウント値により実行される。カウンタC ０１は、リトライ制御部２２ｂに設けられており、過剰にリトライ状態となったアドレストランザクションをカウントする。カウンタC ０２は、リトライ監視部２３a に設けられており、システムが過剰リトライ状態のときにキャッシュスヌープが成功またはエラーで終了したアドレストランザクションをカウントする。
【００３７】
図８は本発明の第１実施例のリトライ制御部の過剰リトライ状態を判定する処理のフローチャートを示す。
リトライ制御部２２ｂは、ステップＳ３−１〜Ｓ３−８を実行する。ステップＳ３−１は、トランザクションがリトライされたか否かを判定する。ステップＳ３−１で、トランザクションがリトライされたと判断された場合には、ステップＳ３−２を実行する。
ス テップＳ３−２は、リトライされたトランザクションが過剰にリトライされているか否かを判定する。ステップＳ３−２で、過剰にリトライされている場合には、ステップＳ３−３が実行される。
【００３８】
ステップＳ３−３は、過剰にリトライされたトランザクションが既にカウンタＣ０１によりカウント済みか否かを判定する。ステップＳ３−３で、過剰にリトライされたトランザクションがカウンタＣ０１によりカウント済みでなければ、ステップＳ３−４を実行する。ステップＳ３−４は、カウンタＣ０１の値を１増加させる。
【００３９】
ステップＳ３−５は、トランザクションが自装置の制御下に存在するか否かを判定する。ステップＳ３−５でトランザクションが自装置の制御下に存在すれば、ステップＳ３−６を実行する。ステップＳ３−６は、トランザクションにカウント済みの情報を。
ステップＳ３−７は、カウント値ｃ０１とカウント値ｃ０２とが一致するか否かを判定する。ステップＳ３−７でカウント値ｃ０１とカウント値ｃ０２とが一致すれば、過剰にリトライされたトランザクションは、解消されたと判断できるので、次にステップＳ３−８を実行する。ステップＳ３−８は、カウンタＣ０１のカウント値ｃ０１を「０」にする。
【００４０】
図９は本発明の第１実施例のリトライ監視部の過剰リトライ状態を判定する処理のフローチャートを示す。
リトライ監視部２３ａは、ステップＳ４−１〜Ｓ４−５を実行する。
ステップS ４−１は、システムが過剰リトライ状態か否かを判定する。ステップS ４−１で、システムが過剰リトライ状態であれば、次に、ステップS ４−２の判断を行なう。
【００４１】
ステップS ４−２は、過剰リトライされたトランザクションの処理が終了したか否かを判定する。ステップＳ４−２で過剰リトライされたトランザクションが処理されると、ステップＳ４−３が実行される。
ステップＳ４−３は、カウンタＣ０２のカウント値ｃ０２を「１」増加させる。
【００４２】
ステップＳ４−４は、カウンタＣ０２のカウント値ｃ０２とリトライ制御部２２ｂのカウンタＣ０１からのカウント値ｃ０１とが同一か否かを判定する。ステップＳ４−４で、カウント値ｃ０１とカウント値Ｃ０２とが同一になった場合には、ステップＳ４−５を実行する。ステップＳ４−５は、過剰リトライのトランザクションがないと判断できるので、カウンタＣ０２のカウント値ｃ０２を「０」にする。
【００４３】
以上のように過剰リトライとなったトランザクションの数をカウントすることにより過剰リトライ状態の判定が可能となる。
なお、上記の過剰リトライ状態の判定方法では、過剰リトライとされたトランザクションの数をカウントしたが、リトライ監視部２３ａに過剰リトライとなったトランザクションに対応したフラグを設けフラグをオン／オフすることにより過剰リトライ状態を判定するようにしてもよい。
【００４４】
図１０は本発明の第１実施例の過剰リトライ状態を判定する方法を説明するための図を示す。
リトライ監視部２３ａに、複数のフラグＦＬＡＧ１〜ＦＬＡＧｍを設ける。フラグの数ｍは、システムに現れる過剰にリトライされたアドレスの最大数と同じだけの数とする。
【００４５】
過剰にリトライされたアドレスが現れると、該当するフラグをオンする。また、過剰にリトライされたアドレスが処理されると、該当するフラグをオフする。すべてのフラグがオフになると、リトライ制御部２２ｂへの過剰リトライ状態の通知を停止する。
また、検査用のトランザクションを発行することにより、過剰リトライ状態か否かを判定するようにしてもよい。
【００４６】
図１１は本発明の第１実施例のリトライ制御部の過剰リトライ判定処理の変形例のフローチャートを示す。
本変形例では、リトライ制御部２２ｂは、ステップＳ５−１〜Ｓ５−５を実行する。
ステップＳ５−１は、システムが過剰リトライ状態か否かを判定する。ステップＳ５−１で、システムが過剰リトライ状態であると判定されると、ステップＳ５−２が実行される。また、ステップＳ５−１でシステムが過剰リトライ状態でないと判定された場合には、処理を終了する。
【００４７】
ステップＳ５−２は、リトライ制御部２２ｂに予め設定された所定時間が経過したかを判定する。
ステップＳ５−２で、所定時間経過すると、ステップＳ５−３を実行させる。ステップＳ５−３は、キュー発行部２２ａから検査用トランザクションをバス制御部５に発行させる。
【００４８】
図１２は本発明の第１実施例の過剰リトライ判定処理の変形例に用いられる検査用トランザクションを説明するための図を示す。
検査用トランザクションは、図１２（Ｂ）に７１で示すように１ビットのアドレストランザクションから構成される。
ステップＳ５−４は、検査用トランザクションが強制的リトライ通知を受けたか否かを判定する。ステップＳ５−４で検査用トランザクションが強制的リトライ通知を受けない場合には、過剰リトライ状態が解消されたと判断できるため、ステップＳ５−５が実行される。ステップＳ５−５は、過剰リトライ通知を停止する。
【００４９】
以上のように１ビットの検査用トランザクションを用いることによりバス６を混雑させることがない。
なお、上記変形例では、１ビットの検査用トランザクションを用いたが、これに限定されるものではなく、過剰リトライ状態でない、他のアドレストランザクションを試験用トランザクションとして発行するようにするようにしてもよい。
【００５０】
また、図１２（Ｃ）に示すアドレス５１の一部８１を検査用アドレストランザクションとして用いるようにしてもよい。
なお、上記の試験用トランザクションの発行は、システムバス６を混雑させない程度の頻度で発行される。
また、上記実施例では、通常のアドレストランザクションの処理について説明した。しかし、アドレストランザクションには、特殊なトランザクションが存在する。特殊なアドレストランザクションとは、抑制を受ける必要がないもの、抑制を受けてはいけないトランザクションである。
【００５１】
次に本発明の第２実施例について説明する。
本実施例の構成は第１実施例と同一であり、リトライ制御部２２ｂ及びリトライ監視部２３ａの処理動作が異なる。よって、構成の説明は省略する。
まず、本実施例におけるリトライ制御部２２ｂの動作を説明する。図１３は本発明の第２実施例のリトライ制御部のフローチャートを示す。
【００５２】
リトライ制御部２２ｂは、ステップＳ６−１〜Ｓ６−７を実行する。ステップＳ６−１は、リトライ制御部２２ｂの制御下のアドレストランザクションが過剰にリトライされているか否かを判定する。ステップＳ６−１で制御下のトランザクションが過剰にリトライされていると、判断された場合には、ステップＳ６−２が実行される。また、ステップＳ６−１で制御下のアドレストランザクションが過剰にリトライされていない場合には、次にステップＳ６−４が実行される。
【００５３】
ステップＳ６−２は、過剰にリトライされたトランザクションの存在をリトライ監視部２３ａに通知する。ステップＳ６−３は、発行するアドレスに図６（Ｂ）に示すように過剰リトライ状態であるマークを発行する。次に、ステップＳ６−４が実行される。
ステップＳ６−４は、システムが過剰リトライ状態か否かを判定する。ステップＳ６−４でシステムが過剰リトライ状態の場合には、ステップＳ６−５が実行される。
【００５４】
ステップＳ６−５は、制御下のアドレストランザクションが特殊なトランザクションが否かを判定する。ステップＳ６−５で制御下のトランザクションが特殊なアドレストランザクションの場合には、ステップＳ６−６が実行され、ステップＳ６−５で制御下のアドレストランザクションが特殊なトランザクションではない場合には、ステップＳ６−７が実行される。
ステップＳ６−６は、特殊なトランザクションの発行頻度を低下させる。ステップＳ６−７は、他のトランザクションの発行を抑制する。
【００５５】
次に本実施例におけるリトライ監視部２３ａの動作を説明する。
図１４は本発明の第２実施例のリトライ監視部の処理フローチャートを示す。
リトライ監視部２３ａは、ステップＳ７−１〜ステップＳ７−７を実行する。ステップＳ７−１は、制御下のアドレストランザクションが過剰リトライ状態か否かを判定する。ステップＳ７−１で制御下のアドレストランザクションが過剰リトライ状態であれば、次にステップＳ７−２が実行される。ステップＳ７−１で、過剰リトライ状態でなければ、次に、ステップＳ７−４が実行される。
【００５６】
ステップＳ７−２は、バス制御部５からのアドレストランザクションが特殊なアドレストランザクションか否かを判定させる。ステップＳ７−２でバス制御部５からのアドレストランザクションが特殊なアドレストランザクション場合には、次にステップＳ７−４が実行され、バス制御部５からのアドレストランザクションが通常のアドレストランザクションの場合には、ステップＳ７−３が実行された後、ステップＳ７−４が実行される。
【００５７】
ステップＳ７−３は、他のアドレストランザクションのスヌープ結果を強制リトライ状態に設定させる。ステップＳ７−４は、アドレストランザクションが強制リトライ状態か否かを判定する。
ステップＳ７−４でアドレストランザクションが強制リトライ状態の場合には、ステップＳ７−５が実行された後ステップＳ７−６が実行され、ステップＳ７−４でアドレストランザクションが強制リトライ状態ではない場合には、ステップＳ７−６が実行される。
【００５８】
ステップＳ７−５は、リトライ制御部２２ｂに過剰リトライ状態である旨を通知する。
ステップＳ７−６は、過剰リトライ状態が解消したか否か判定する。
ステップＳ７−６で、過剰リトライ状態が解消したと判断された場合には、ステップＳ７−７が実行される。
【００５９】
ステップＳ７−７は、リトライ制御部２２ｂへの過剰リトライ状態の通知を停止する。
リトライ監視部２３ａでは、上記ステップＳ７−１〜Ｓ７−７が繰り返される。
本実施例によれば、特殊なアドレストランザクションの存在を許しつつも、過剰リトライ状態のアドレストランザクションを効率的に処理できる。
【００６０】
次に、本発明の第３実施例について説明する。
本実施例は、アドレストランザクションをグループ分けして制御する場合の実装例を示す。なお、本実施例の構成は、第１実施例と同一であり、リトライ制御部２２ｂ及びリトライ監視部２３ａでの処理が相違するだけであるので、構成についての説明は省略する。
【００６１】
図１５は本発明の第３実施例のアドレストランザクションのデータ構成図を示す。
本実施例のアドレストランザクションは、図１５（A ）に示すようにトランザクション情報Ｔ１〜Ｔｎ及びアドレス９１から構成される。
図１５（Ｂ）に示すようにアドレス９１の上位ビット９１−１は、アドレスのキャッシュライン毎のグループ分けに用いられる。
【００６２】
また、図１５（Ｃ）に示すようにトランザクション情報Ｔｘ及びアドレスの上位ビット９１−２は、アドレスが含まれるプロセッサのグループ分けに用いられる。なお、トランザクション情報Ｔｘは、トランザクション情報Ｔ１〜Ｔｎのうちの任意のトランザクション情報を示す。
次に、リトライ制御部２２ｂの動作について説明する。
【００６３】
図１６は本発明の第３実施例のリトライ制御部の処理フローチャートを示す。リトライ制御部２２ｂは、ステップＳ８−１〜Ｓ８−７を実行する。ステップＳ８−１は、制御下のアドレストランザクションが過剰のリトライ状態か否かを判定する。ステップＳ８−１でアドレストランザクションが過剰リトライ状態である場合には、ステップＳ８−２、Ｓ８−３が実行された後ステップＳ８−４が実行される。また、ステップＳ８―１でアドレストランザクションが過剰リトライ状態でない場合には、次にステップＳ８−４が実行される。
【００６４】
ステップＳ８−２は、過剰にリトライされたアドレストランザクションの存在をリトライ監視部２３ａに通知する。ステップＳ８−３は、発行するアドレストランザクションに過剰にリトライされたアドレストランザクションである旨のマークを付ける。
ステップＳ８−４は、システムの配下のアドレストランザクションが属するグループが過剰リトライ状態か否かを判定する。アドレストランザクションが属するグループは、例えば、図１５（Ｂ）に示すアドレス９１の上位ビット９１−１や図１５（Ｃ）に示すトランザクション情報Ｔｘ及びアドレス９１の上記ビット９１−２により判定できる。
【００６５】
ステップＳ８−４で、システムの配下のグループが過剰リトライ状態である場合には、ステップＳ８―５が実行される。ステップＳ８−５は、特殊なアドレストランザクションか否かを判定する。ステップＳ８−５で特殊なアドレストランザクションであると判断された場合には、ステップＳ８−６が実行され、特殊なアドレストランザクションでなないと判断された場合には、ステップＳ８−７が実行される。
【００６６】
ステップＳ８−６は、特殊なアドレストランザクションの発行頻度を低下させる。ステップＳ８−７は、他のアドレストランザクションの発行を抑制する
次に、リトライ監視部２３ａの動作を説明する。
図１７は本発明の第３実施例のリトライ監視部の動作フローチャートを示す。
リトライ監視部２３ａは、ステップＳ９−１〜Ｓ９−７の処理を実行する。
【００６７】
ステップＳ９−１は、制御下のアドレストランザクションは過剰リトライ状態か否かを判定する。ステップＳ９−１で制御下のアドレストランザクションが過剰リトライ状態である場合には、ステップＳ９−２〜Ｓ９−４が実行された後ステップＳ９−５が実行される。また、ステップＳ９−１で、制御下のアドレストランザクションが過剰リトライ状態ではない場合には、次にステップＳ９−５が実行される。
【００６８】
ステップＳ９−２は、バス制御部５からのアドレストランザクションが制御下のグループと同一のグループか否かを判定する。ステップＳ９−２で、同一グループである場合には、次にステップＳ９−３が実行され、同一グループでない場合には、次にステップＳ９−５が実行される。
ステップＳ９−３は、バス制御部５からのトランザクションが特殊なトランザクションか否かを判定する。ステップＳ９−３で特殊なトランザクションであると判定された場合には、次にステップＳ９−５が実行され、特殊なトランザクションではないと判定された場合には、次にステップＳ９−４が実行される。
【００６９】
ステップＳ９−４は、他のトランザクションを強制的リトライ状態にする。
ステップＳ９−５は、スヌープ結果が強制的リトライ状態か否かを判定する。ステップＳ９−５で、スヌープ結果が強制的リトライ状態であると判定された場合には、次にステップＳ９−７が実行され、スヌープ結果が強制的リトライ状態ではないと判定された場合には、次にステップＳ９−６が実行された後ステップＳ９−７が実行される。
【００７０】
ステップＳ９−６は、リトライ制御部２２ｂにグループ情報の通知及び過剰リトライ状態である旨の通知を行なう。
ステップＳ９−７は、過剰リトライ状態が解消したが否かが判定される。ステップＳ９−７で、過剰リトライ状態が解消していないと判断された場合には、そのまま処理を終了する。また、ステップＳ９−７で過剰リトライ状態が解消したと判断された場合には、次にステップＳ９−８が実行される。
【００７１】
ステップＳ９−８は、リトライ制御部２２ｂへのグループ情報の通知及び過剰リトライ状態である旨の通知を停止する。
リトライ監視部２３ａは、上記ステップＳ９−１〜Ｓ９−７の処理をバス制御部５からアドレストランザクションが供給される毎に実行する。
なお、アドレストランザクションのグループ分けは、複数のグループで過剰リトライ状態が干渉しないように行なわれる。
【００７２】
グループの分類方法としては、アドレスのキャッシュライン毎、及びアドレスの対象が含まれるプロセッサ毎などの分類方法がある。
また、過剰なリトライが発生したアドレストランザクションのグループ分類を切り換えることにより、優先してリトライが行なわれるようにしてもよい。
図１８は本発明の第３実施例の変形例のリトライ制御部の動作フローチャートを示す。
【００７３】
グループ分類を切り換える処理は、ステップＳ１０−１〜Ｓ１０−５から構成される。
ステップＳ１０−１は、制御下の所定のアドレストランザクションが過剰にリトライされているか否かを判定する。ステップＳ１０−１で過剰にリトライされた状態であると判定された場合には、次に、ステップＳ１０−２が実行される。また、ステップＳ１０−１で過剰にリトライされた状態ではないと判定された場合には、そのまま処理を終了する。
【００７４】
ステップＳ１０−２は、所定のアドレストランザクションが別のグループ分類でも新たに過剰リトライ状態とされたか否かがが判定される。ステップＳ１０−２で、別のグループ分類でも過剰リトライ状態とされた場合には、次にステップＳ１０−３が実行された後、Ｓ１０−４が実行される。また、ステップＳ１０−２で、別のグループ分類では過剰リトライ状態とされていない場合には、そのまま処理を終了する。
【００７５】
ステップＳ１０−３は、所定のアドレストランザクションが属する複数のグループ分類を比較する。
ステップＳ１０−４は、新たなグループ分類の優先順位が別のグループ分類より高いか否かを判定する。ステップＳ１０−４で、新たに過剰リトライ状態とされたグループ分類の優先順位が高い場合には、ステップＳ１０−５を実行する。また、ステップＳ１０−４で、新たに過剰リトライ状態とされたグループ分類の優先順位が元のグループ分類より低い場合には、そのまま処理を終了する。
ステップＳ１０−５は、制御対象とするグループ分類を新たなグループ分類に設定する。
【００７６】
本変形例によれば、グループ分類の設定を優先順位の高いグループ分類に切り換えることにより、優先してリトライ処理が行なわれ、過剰リトライ状態を解消できる。
なお、本実施例では、図１に示すようにＮ個のプロセッサ２−１〜２−Ｎをシステムバス６に接続してメモリ３を共有する場合について説明したが、複数のプロセッサとメモリからなるシステムボードをシステムバス６に接続するようにしてもよい。
【００７７】
図１９は本発明の他の適用例のブロック構成図を示す。同図中、図１と同一構成部分には同一符号を付し、その説明は省略する。
本適用例のシステム１００は、Ｍ個のシステムボード１０１−１〜
１０１−Ｍをシステムバス６に接続してなる。システムボード１０１−１〜１０１−Ｍは、Ｎ個のプロセッサ１０２−１〜１０２−Ｎ及びメモリ１０３から構成される。システムバス６には、Ｍ×Ｎ個のプロセッサが接続される。各プロセッサは、アドレストランザクションにエラーが発生した場合には、上記のような処理によってリトライ処理が実行される。
【００７８】
【発明の効果】
上述の如く、本発明によれば、トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態が検出された場合にはバスに対する他のトランザクションの発行を抑止することにより、処理を一定時間内に終了させることを保証でき、よって、処理がタイムアウトし、システムダウンすることを防止できる等の特長を有する。
【００７９】
また、本発明によれば、所定の条件に基づいて過剰リトライ状態が解消したか否かの検査を行うための検査用トランザクションの要求を行い、検査用トランザクションが抑制されない場合には過剰リトライ状態が解消したものと判断することにより、通常処理への影響を低減できる等の特長を有する。
さらに、本発明によれば、複数のトランザクションを複数のグループに分類し、所定のトランザクションが属するグループに含まれる他のトランザクションの要求を抑止することにより、処理の要求の抑制を影響が大きい処理だけに限定することができ、関係のない処理への影響は低減できる等の特長を有する。
【図面の簡単な説明】
【図１】マルチプロセッサシステムのブロック構成図である。
【図２】従来の一例の要部の構成図である。
【図３】従来の一例のパイプライン処理の動作説明図である。
【図４】本発明の第１実施例のブロック構成図である。
【図５】本発明の第１実施例のリトライ制御部の処理フローチャートである。
【図６】本発明の第１実施例の動作を説明するための図である。
【図７】本発明の第１実施例のリトライ監視部の処理フローチャートである。
【図８】本発明の第１実施例のリトライ制御部の過剰リトライ状態を判定する処理のフローチャートである。
【図９】本発明の第１実施例のリトライ監視部の過剰リトライ状態を判定する処理のフローチャートである。
【図１０】本発明の第１実施例の過剰リトライ状態を判定する方法を説明するための図である。
【図１１】本発明の第１実施例のリトライ制御部の過剰リトライ判定処理の変形例のフローチャートである。
【図１２】本発明の第１実施例の過剰リトライ判定処理の変形例に用いられる検査用トランザクションを説明するための図である。
【図１３】本発明の第２実施例のリトライ制御部のフローチャートである。
【図１４】本発明の第２実施例のリトライ監視部の処理フローチャートである。
【図１５】本発明の第３実施例のアドレストランザクションのデータ構成図である。
【図１６】本発明の第３実施例のリトライ制御部の処理フローチャートである。
【図１７】本発明の第３実施例のリトライ監視部の動作フローチャートである。
【図１８】本発明の第３実施例の変形例のリトライ制御部の動作フローチャートである。
【図１９】本発明の他の適用例のブロック構成図である。
【符号の説明】
１ マルチプロセッサシステム
２−１〜２−Ｎ プロセッサ
３ メモリ
４ 入出力装置
５ バス制御部
６ システムバス
２１ 演算部
２２ アドレス制御部
２２ａ キュー発行部
２２ｂ リトライ制御部
２２ｃ カウント部
２３ スヌープ制御部
２３ａ リトライ監視部
Ｃ０１、Ｃ０２ カウンタ
【発明の属する技術分野】
本発明は情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法に係り、特に、トランザクションリトライを行なう情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法に関する。近年、大規模サーバの需要が高まっているにしたがって、大量のデータ処理能力と高い信頼性をもつ、マルチプロセッサシステムの出現が望まれている。
【０００２】
マルチプロセッサシステムの性能を向上するための最も重要な要素の一つとしてシステムバスの高速化がある。システムバスを高速化するための手法としてシステムバスのパイプライン化がある。
システムバスのパイプライン化は、バスのスループットを向上させることができる。一方、エラーが発生した場合、処理の流れが滞るので性能低下が著しい。このため、エラーが発生した場合の性能低下を避ける手法が提案されている。
【０００３】
この手法の一つとしてリトライ処理がある。リトライ処理は、エラーを起こしたアドレストランザクションを再び発行して失敗した処理を再開する処理である。リトライ処理は、マルチプロセッサシステムの性能に大きく影響する重要な要素である。したがって、このようなリトライ処理には、高性能、高信頼性が望まれている。
【０００４】
【従来の技術】
パイプイン化されたシステムバスは、アドレストランザクションを複数の段階に分けて、それぞれの段階に対応するバスが独立に異なるトランザクションを処理できるように構成されている。すなわち、パイプライン化されていた。
また、マルチプロセッサシステムでは、共有メモリ型マルチプロセッサシステムが主流を占めている。共有メモリ型マルチプロセッサシステムは、複数のプロセッサが共通のメモリにアクセスするため、システム全体でアドレススヌープを行なって、コヒーレンスを保つようにしていた。
【０００５】
上記のようなシステムでは、大別して二種類のエラーが存在する。一つは、システム故障等によるエラー、もう一つはアドレス競合などによる通常動作時に頻繁に起こるエラーである。
後者のアドレス競合は、同一アドレスに対して連続してトランザクションが発行された場合に、先行して発行されたトランザクションの処理結果の反映が後に発行されたトランザクションの参照に間に合わない場合に生じる。
【０００６】
このようなエラーの対処方法は、２つある。一つは、後に発行されたトランザクションが処理可能になるまでのバスを一時的に停止する方法である。もう一つは、後に発行されたトランザクションを打ち切り、再度同一のアドレスをバスに発行する方法である。
後者の対処方法は、アドレスリトライと呼ばれている。このアドレスリトライを実現する機構は、アドレスリトライ機構と呼ばれている。従来のマルチプロセッサシステムの多くは、システムの能力低下を防ぐためにアドレスリトライ機構が搭載されていた。
【０００７】
図１はマルチプロセッサシステムのブロック構成図を示す。
マルチプロセッサシステム１は、プロセッサ２−１〜２−Ｎ、共有メモリ３、入出力装置４、バス制御部５、システムバス６から構成される。
プロセッサ２−１〜２−Ｎは、命令に応じた演算を実行する。
メモリ３は、Ｎ個のプロセッサ２−１〜２−Ｎとシステムバス６を介して接続されており、Ｎ個のプロセッサ２−１〜２−Ｎからアクセス可能とされており、Ｎ個のプロセッサ２−１〜２−Ｎで共有して用いられる。
【０００８】
入出力装置４は、キーボード、マウス、ディスプレイ、プリンタ、通信装置などから構成される。入出力装置４は、データの入出力、処理の指示入力、処理結果の入出力が行なわれる。
バス制御部５は、Ｎ個のプロセッサ２−１〜２−Ｎ、入出力装置４に接続され、バス６の使用権を制御する。バス６は、Ｎ個のプロセッサ２−１〜２−Ｎ、メモリ３、入出力装置４間のデータの伝送に用いられる。
【０００９】
図２は従来の一例の要部の構成図を示す。
プロセッサ２−Ｘは、Ｎ個のプロセッサ２−１〜２−Ｎのうち、一つのプロセッサを示す。プロセッサ２−Ｘとバス制御部５とは、バス６により接続されている。バス６は、アドレスバス１１、１２、ステータスバス１３、１４、データバス１５から供給される。
【００１０】
アドレスバス１１は、プロセッサ２−Ｘからバス制御部５にアドレスを伝送する。アドレスバス１１で伝送されるアドレスは、例えば、プロセッサ２−Ｘで発行されたトランザクションのアドレスである。
アドレスバス１２は、バス制御部５からプロセッサ２−Ｘにアドレスを伝送する。アドレスバス１２で伝送されるアドレスは、例えば、バス制御部５で調停され、バス６の使用が許可されたアドレスである。
【００１１】
ステータスバス１３は、プロセッサ２−Ｘからバス制御部５にプロセッサ２−Ｘのステータスを供給する。ステータスバス１３を伝送されるステータスは、プロセッサ２−Ｘでキャッシュスヌープを行なった結果を伝送する。
ステータスバス１４は、バス制御部５からプロセッサ２−Ｘにテータスを供給する。ステータスバス１４を伝送されるステータスは、Ｎ個のプロセッサ２−１〜２−Ｎでのキャッシュスヌープの結果を合成したものが伝送される。データバス１５は、キャッシュスヌープ結果に応じてデータを転送する。
【００１２】
次に、従来のアドレストランザクション処理の動作について説明する。
プロセッサ２−Ｘは、演算部２１、アドレス制御部２２、スヌープ制御部２３から構成される。
演算部２１は、データ処理を行ない、データ処理の結果に応じてアドレストランザクションを要求する。アドレス制御部２２は、演算部２１からのアドレストランザクションの要求に応じてアドレスを発行する。
アドレス制御部２２は、キュー発行部２２ａ、リトライ制御部２２ｂ、カウント部２２ｃを有する。キュー発行部２２ａは、アドレストランザクションに応じてアドレスを発行する。
【００１３】
リトライ制御部２２ｂは、演算部２１、スヌープ制御部２３、バス制御部５に接続されている。リトライ制御部２２ｂは、スヌープ制御部２３からのリトライ指示に応じてキュー発行部２２ａを制御する。
このとき、リトライ制御部２２ｂには、演算部２１からのリトライ回数、タイムアウト時間が設定され、カウント部２２ｃからは、リトライ回数、タイムアウト時間が供給される。リトライ制御部２２ｂは、カウント部２２ｃのからのリトライ回数又はタイムアウト時間が演算部２１によって設定されたリトライ回数又はタイムアウト時間になるまで、リトライを繰り返す。
【００１４】
また、リトライ制御部２２ｂには、バス制御部５からバス６の使用状況に関する情報が供給される。リトライ制御部２２ｂは、バス制御部５からの情報に応じてリトライ頻度を制御する。
カウント部２２ｃは、リトライ回数、タイムアウト時間をカウントする。リトライ制御部２２ｂは、カウント部２２ｃからのリトライ回数、タイムアウト時間を参照して、所定の回数並びに所定の時間に制限する。
【００１５】
スヌープ制御部２３は、バス制御部５からアドレスに応じてキャッシュステータスを求める。また、スヌープ制御部２３は、バス制御部５からのシステム全体のキャッシュステータスに応じてデータの転送を制御するとともに、アドレスリトライの指示を発行する。
次に、アドレストランザクションの発生時の動作を図面とともに説明する。
ステップＳ１で、プロセッサ２−Ｘの演算部２１からアドレストランザクションが発生される。演算部２１からのアドレストランザクションは、アドレス制御部２２のキュー発行部２２ａに供給される。
【００１６】
ステップＳ2 で、キュー発行部２２ａから演算部２１からのアドレストランザクションに応じたアドレスが発行される。キュー発行部２２ａから発行されたアドレスは、バス制御部５にアドレスを供給される。
ステップＳ3 で、バス制御部５によりプロセッサ２−Ｘからのアドレスがプロセッサ２−１〜２−Ｎのアドレスバス１２に供給される。
【００１７】
ステップＳ4 では、プロセッサ２−１〜２−Ｎにより、バス制御部５からのアドレスに対してキャッシュステータスが求められる。
プロセッサ２−１〜２−Ｎは、キャッシュステータスをバス制御部５に供給する。
ステップＳ5 は、バス制御部５での処理であり、プロセッサ２−１〜２−Ｎからのキャッシュステータスを合成してシステム全体のキャッシュステータスが求められる。
【００１８】
ステップＳ６は、バス制御部５の処理であり、システム全体のキャッシュステータスをプロセッサ２−１〜２−Ｎに供給する。プロセッサ２−Ｘは、バス制御部５からシステム全体のキャッシュステータスを受信する。
ステップＳ７は、プロセッサ２−Ｘでの処理であり、バス制御部５からのシステム全体のキャッシュステータスに基づいてデータの転送制御が行なわれる。
【００１９】
なお、上記ステップS １〜Ｓ７は、プロセッサ２−１〜２−Ｎで発生される各トランザクションに対して行なわれる。ステップS １〜Ｓ７をパイプライン的に処理することにより処理の多重度を向上でき、高速化が可能となる。
図３は従来の一例のパイプライン処理の動作説明図を示す。
図３において、ＡＴ１〜ＡＴ３はトランザクションを示す。トランザクションＡＴ１は、時刻ｔ１でステップＳ２、次の時刻ｔ２でステップＳ３、次の時刻ｔ３でステップＳ４、次の時刻ｔ４でステップＳ５、次の時刻ｔ５でステップＳ６、次の時刻ｔ６でステップＳ７が実行される。トランザクションＡＴ２は、時刻ｔ２でステップＳ２、次の時刻ｔ３でステップＳ３、次の時刻ｔ４でステップＳ４、次の時刻ｔ５でステップＳ５、次の時刻ｔ６でステップＳ６、次の時刻ｔ７でステップＳ７が実行される。トランザクションＡＴ３は、時刻ｔ３でステップＳ２、次の時刻ｔ４でステップＳ３、次の時刻ｔ５でステップＳ４、次の時刻ｔ６でステップＳ５、次の時刻ｔ７でステップＳ６、次の時刻ｔ８でステップＳ７が実行される。
【００２０】
このように異なるトランザクションＡＴ１〜ＡＴ３は、同一ステップが異なる時刻で処理される。よって、バスを一つのトランザクションで占有することがないので、効率よく処理を行なうことができる。このパイプライン処理の利点を生かすため、アドレスリトライ機構が用いられている。
【００２１】
【発明が解決しようとする課題】
しかしながら、上記システムでは、アドレストランザクションがアドレスリトライ機構によって、リトライされ続けると、処理の時間が長くなり、処理効率が低下する。また、規定のリトライ回数、タイムアウト時間が経過すると、システムに異常があると判定され、システムが停止してしまう等の問題点があった。
【００２２】
本発明は上記の点に鑑みてなされたもので、システムを効率よく、かつ、高い信頼性を持って運用できる情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法を提供することを目的とする。
【００２３】
【課題を解決するための手段】
本発明は、バスに接続された処理手段を有し、該処理手段により前記バスに対してトランザクションの発行を行う情報処理装置において、処理手段は前記処理手段は、検査用トランザクションを発行して、前記トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態を検出する過剰リトライ状態検出手段と、過剰リトライ検出手段により過剰リトライ状態が検出された場合にはバスに対して、過剰リトライ状態でないトランザクションの発行を抑制する処理制御手段とを有することを特徴とする。
本発明によれば、トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態が検出された場合にはバスに対して、過剰リトライ状態でない他のトランザクションの発行を抑制することにより、処理を一定時間内に終了させることを保証でき、よって、処理がタイムアウトし、システムダウンすることを防止できる。
【００２４】
また、本発明によれば、通常処理への影響を低減できる。
【００２５】
さらに、処理制御手段は、複数のトランザクションを複数のグループに分類し、所定のトランザクションが属するグループに含まれる他のトランザクションの要求を抑止することを特徴とする。本発明によれば、処理の要求の抑制を影響が大きい処理だけに限定することができ、関係のない処理への影響は低減できる。
【００２６】
【発明の実施の形態】
図４は本発明の第１実施例のブロック構成図を示す。同図中、図２と同一構成部分には同一符号を付し、その説明は省略する。
本実施例は、リトライ制御部２２ｂの処理が図２とは相違する。また、スヌープ制御部２３にリトライ監視部２３ａを設けてなる。
【００２７】
図５は本発明の第１実施例のリトライ制御部の処理フローチャートを示す。
リトライ制御部２２ｂは、ステップＳ１−１〜Ｓ１−５の処理を実行する。
ステップＳ１−１は、カウント部２２ｃからのリトライ回数が所定のリトライ回数以上になったか否かを判定する。なお、所定のリトライ回数は、演算部２１によって、設定された規定のリトライ回数以下の回数に設定されている。このため、所定のリトライ回数となってもタイムアウトとならず、システムダウンはしない。ステップＳ１−１の判断は、複数の条件の組み合わせで行なわれる。
【００２８】
例えば、第１の条件は、経過時間が演算部２１によって設定されたタイムアウト時間の８０パーセントを越えた場合とする。第２の条件は、プロセッサ数が３２個未満の場合に、リトライ回数が４０回以上になった場合とする。第３の条件は、プロセッサ数が３２個以上の場合に、２０回以上になった場合とする。
ステップＳ１−１で、リトライ回数が規定の回数以上であれば、次に、ステップＳ１−２、Ｓ１−３が実行され、規定の回数以下であれば、次に、ステップＳ１−４が実行される。
【００２９】
ステップＳ１−２は、過剰にリトライされたアドレストランザクションにマーキングを行う。図６は本発明の第１実施例の動作を説明するための図を示す。図６（Ａ）は通常時に発行されるアドレストランザクションの状態、図６（Ｂ）は過剰にリトライされたときに発行されるアドレストランザクションの状態を示す。キュー発行部２２ａは、通常は図６（Ａ）に示すようにアドレストランザクション５１を出力する。また、キュー発行部２２ａは、リトライ制御部２２ｂで過剰リトライが検出されると、リトライ制御部２２ｂからの指示により図６（Ｂ）に示すようにアドレストランザクション５１にマーク６１を発行する。
【００３０】
ステップＳ１−３は、ステップＳ１−２でマークが付与されたアドレスをバス制御部５に通知する。
ステップＳ１−４は、システム過剰リトライ状態か否かを判定する。
ステップＳ１−４でシステムが過剰リトライ状態でなければ、そのまま処理を終了し、アドレスリトライが解消されるまで、リトライを継続する。
【００３１】
また、ステップＳ１−４で、システムが過剰リトライ状態であれば、ステップＳ１−５が実行される。ステップＳ１−５は、リトライ制御部２２ｂを制御して、過剰リトライ状態でない他のトランザクションの発行を抑制する。
ステップＳ１―５で、過剰リトライ状態でないトランザクションの発行を抑制させることに過剰リトライ状態のトランザクションを優先して実行させることができる。よって、タイムアウトを抑制できる。
【００３２】
次に、リトライ監視部２３ａの動作について説明する。
図７は本発明の第１実施例のリトライ監視部の処理フローチャートを示す。
リトライ監視部２３ａは、ステップＳ２−１〜Ｓ２−６を実行する。ステップＳ２−１は、リトライ回数が所定の回数か否かを判定する。ステップＳ２−１でリトライ回数が所定の回数以上になると、次に、ステップＳ２−２が実行される。
【００３３】
ステップＳ２−２は、過剰リトライ状態が検出されていない他のトランザクションのスヌープ結果を強制的リトライ状態にする。
ステップＳ２−３は、強制的リトライ状態か否かを判定する。ステップＳ２−３で、強制リトライ状態と判定された場合には、次に、ステップＳ２−４が実行される。
【００３４】
ステップＳ２−４は、リトライ制御部２２ａに過剰リトライ状態である旨の通知を行なう。
ステップＳ２−５は、過剰リトライ状態が解消したか否かが判断される。ステップＳ２−５で過剰リトライ状態である旨判断されると、次に、ステップＳ２−６が実行される。
【００３５】
ステップＳ２−６は、ステップＳ２−４でリトライ制御部２２ａに通知した過剰リトライ状態である旨の通知を解除する。
リトライ監視部２３ａにより、過剰でないリトライ状態のアドレストランザクションについては、強制的にリトライ状態とされる。よって、過剰なリトライ状態のアドレストランザクションが優先して実行される。このため、システムがタイムアウトしてシステムダウンする確率を低減することができる。
【００３６】
ここで、過剰ステップＳ２−１の過剰リトライ状態の判定方法について説明する。
過剰リトライ状態の判定は、リトライ制御部２２ｂに設けられたカウンタC ０１及びカウンタC ０２のカウント値により実行される。カウンタC ０１は、リトライ制御部２２ｂに設けられており、過剰にリトライ状態となったアドレストランザクションをカウントする。カウンタC ０２は、リトライ監視部２３a に設けられており、システムが過剰リトライ状態のときにキャッシュスヌープが成功またはエラーで終了したアドレストランザクションをカウントする。
【００３７】
図８は本発明の第１実施例のリトライ制御部の過剰リトライ状態を判定する処理のフローチャートを示す。
リトライ制御部２２ｂは、ステップＳ３−１〜Ｓ３−８を実行する。ステップＳ３−１は、トランザクションがリトライされたか否かを判定する。ステップＳ３−１で、トランザクションがリトライされたと判断された場合には、ステップＳ３−２を実行する。
ス テップＳ３−２は、リトライされたトランザクションが過剰にリトライされているか否かを判定する。ステップＳ３−２で、過剰にリトライされている場合には、ステップＳ３−３が実行される。
【００３８】
ステップＳ３−３は、過剰にリトライされたトランザクションが既にカウンタＣ０１によりカウント済みか否かを判定する。ステップＳ３−３で、過剰にリトライされたトランザクションがカウンタＣ０１によりカウント済みでなければ、ステップＳ３−４を実行する。ステップＳ３−４は、カウンタＣ０１の値を１増加させる。
【００３９】
ステップＳ３−５は、トランザクションが自装置の制御下に存在するか否かを判定する。ステップＳ３−５でトランザクションが自装置の制御下に存在すれば、ステップＳ３−６を実行する。ステップＳ３−６は、トランザクションにカウント済みの情報を。
ステップＳ３−７は、カウント値ｃ０１とカウント値ｃ０２とが一致するか否かを判定する。ステップＳ３−７でカウント値ｃ０１とカウント値ｃ０２とが一致すれば、過剰にリトライされたトランザクションは、解消されたと判断できるので、次にステップＳ３−８を実行する。ステップＳ３−８は、カウンタＣ０１のカウント値ｃ０１を「０」にする。
【００４０】
図９は本発明の第１実施例のリトライ監視部の過剰リトライ状態を判定する処理のフローチャートを示す。
リトライ監視部２３ａは、ステップＳ４−１〜Ｓ４−５を実行する。
ステップS ４−１は、システムが過剰リトライ状態か否かを判定する。ステップS ４−１で、システムが過剰リトライ状態であれば、次に、ステップS ４−２の判断を行なう。
【００４１】
ステップS ４−２は、過剰リトライされたトランザクションの処理が終了したか否かを判定する。ステップＳ４−２で過剰リトライされたトランザクションが処理されると、ステップＳ４−３が実行される。
ステップＳ４−３は、カウンタＣ０２のカウント値ｃ０２を「１」増加させる。
【００４２】
ステップＳ４−４は、カウンタＣ０２のカウント値ｃ０２とリトライ制御部２２ｂのカウンタＣ０１からのカウント値ｃ０１とが同一か否かを判定する。ステップＳ４−４で、カウント値ｃ０１とカウント値Ｃ０２とが同一になった場合には、ステップＳ４−５を実行する。ステップＳ４−５は、過剰リトライのトランザクションがないと判断できるので、カウンタＣ０２のカウント値ｃ０２を「０」にする。
【００４３】
以上のように過剰リトライとなったトランザクションの数をカウントすることにより過剰リトライ状態の判定が可能となる。
なお、上記の過剰リトライ状態の判定方法では、過剰リトライとされたトランザクションの数をカウントしたが、リトライ監視部２３ａに過剰リトライとなったトランザクションに対応したフラグを設けフラグをオン／オフすることにより過剰リトライ状態を判定するようにしてもよい。
【００４４】
図１０は本発明の第１実施例の過剰リトライ状態を判定する方法を説明するための図を示す。
リトライ監視部２３ａに、複数のフラグＦＬＡＧ１〜ＦＬＡＧｍを設ける。フラグの数ｍは、システムに現れる過剰にリトライされたアドレスの最大数と同じだけの数とする。
【００４５】
過剰にリトライされたアドレスが現れると、該当するフラグをオンする。また、過剰にリトライされたアドレスが処理されると、該当するフラグをオフする。すべてのフラグがオフになると、リトライ制御部２２ｂへの過剰リトライ状態の通知を停止する。
また、検査用のトランザクションを発行することにより、過剰リトライ状態か否かを判定するようにしてもよい。
【００４６】
図１１は本発明の第１実施例のリトライ制御部の過剰リトライ判定処理の変形例のフローチャートを示す。
本変形例では、リトライ制御部２２ｂは、ステップＳ５−１〜Ｓ５−５を実行する。
ステップＳ５−１は、システムが過剰リトライ状態か否かを判定する。ステップＳ５−１で、システムが過剰リトライ状態であると判定されると、ステップＳ５−２が実行される。また、ステップＳ５−１でシステムが過剰リトライ状態でないと判定された場合には、処理を終了する。
【００４７】
ステップＳ５−２は、リトライ制御部２２ｂに予め設定された所定時間が経過したかを判定する。
ステップＳ５−２で、所定時間経過すると、ステップＳ５−３を実行させる。ステップＳ５−３は、キュー発行部２２ａから検査用トランザクションをバス制御部５に発行させる。
【００４８】
図１２は本発明の第１実施例の過剰リトライ判定処理の変形例に用いられる検査用トランザクションを説明するための図を示す。
検査用トランザクションは、図１２（Ｂ）に７１で示すように１ビットのアドレストランザクションから構成される。
ステップＳ５−４は、検査用トランザクションが強制的リトライ通知を受けたか否かを判定する。ステップＳ５−４で検査用トランザクションが強制的リトライ通知を受けない場合には、過剰リトライ状態が解消されたと判断できるため、ステップＳ５−５が実行される。ステップＳ５−５は、過剰リトライ通知を停止する。
【００４９】
以上のように１ビットの検査用トランザクションを用いることによりバス６を混雑させることがない。
なお、上記変形例では、１ビットの検査用トランザクションを用いたが、これに限定されるものではなく、過剰リトライ状態でない、他のアドレストランザクションを試験用トランザクションとして発行するようにするようにしてもよい。
【００５０】
また、図１２（Ｃ）に示すアドレス５１の一部８１を検査用アドレストランザクションとして用いるようにしてもよい。
なお、上記の試験用トランザクションの発行は、システムバス６を混雑させない程度の頻度で発行される。
また、上記実施例では、通常のアドレストランザクションの処理について説明した。しかし、アドレストランザクションには、特殊なトランザクションが存在する。特殊なアドレストランザクションとは、抑制を受ける必要がないもの、抑制を受けてはいけないトランザクションである。
【００５１】
次に本発明の第２実施例について説明する。
本実施例の構成は第１実施例と同一であり、リトライ制御部２２ｂ及びリトライ監視部２３ａの処理動作が異なる。よって、構成の説明は省略する。
まず、本実施例におけるリトライ制御部２２ｂの動作を説明する。図１３は本発明の第２実施例のリトライ制御部のフローチャートを示す。
【００５２】
リトライ制御部２２ｂは、ステップＳ６−１〜Ｓ６−７を実行する。ステップＳ６−１は、リトライ制御部２２ｂの制御下のアドレストランザクションが過剰にリトライされているか否かを判定する。ステップＳ６−１で制御下のトランザクションが過剰にリトライされていると、判断された場合には、ステップＳ６−２が実行される。また、ステップＳ６−１で制御下のアドレストランザクションが過剰にリトライされていない場合には、次にステップＳ６−４が実行される。
【００５３】
ステップＳ６−２は、過剰にリトライされたトランザクションの存在をリトライ監視部２３ａに通知する。ステップＳ６−３は、発行するアドレスに図６（Ｂ）に示すように過剰リトライ状態であるマークを発行する。次に、ステップＳ６−４が実行される。
ステップＳ６−４は、システムが過剰リトライ状態か否かを判定する。ステップＳ６−４でシステムが過剰リトライ状態の場合には、ステップＳ６−５が実行される。
【００５４】
ステップＳ６−５は、制御下のアドレストランザクションが特殊なトランザクションが否かを判定する。ステップＳ６−５で制御下のトランザクションが特殊なアドレストランザクションの場合には、ステップＳ６−６が実行され、ステップＳ６−５で制御下のアドレストランザクションが特殊なトランザクションではない場合には、ステップＳ６−７が実行される。
ステップＳ６−６は、特殊なトランザクションの発行頻度を低下させる。ステップＳ６−７は、他のトランザクションの発行を抑制する。
【００５５】
次に本実施例におけるリトライ監視部２３ａの動作を説明する。
図１４は本発明の第２実施例のリトライ監視部の処理フローチャートを示す。
リトライ監視部２３ａは、ステップＳ７−１〜ステップＳ７−７を実行する。ステップＳ７−１は、制御下のアドレストランザクションが過剰リトライ状態か否かを判定する。ステップＳ７−１で制御下のアドレストランザクションが過剰リトライ状態であれば、次にステップＳ７−２が実行される。ステップＳ７−１で、過剰リトライ状態でなければ、次に、ステップＳ７−４が実行される。
【００５６】
ステップＳ７−２は、バス制御部５からのアドレストランザクションが特殊なアドレストランザクションか否かを判定させる。ステップＳ７−２でバス制御部５からのアドレストランザクションが特殊なアドレストランザクション場合には、次にステップＳ７−４が実行され、バス制御部５からのアドレストランザクションが通常のアドレストランザクションの場合には、ステップＳ７−３が実行された後、ステップＳ７−４が実行される。
【００５７】
ステップＳ７−３は、他のアドレストランザクションのスヌープ結果を強制リトライ状態に設定させる。ステップＳ７−４は、アドレストランザクションが強制リトライ状態か否かを判定する。
ステップＳ７−４でアドレストランザクションが強制リトライ状態の場合には、ステップＳ７−５が実行された後ステップＳ７−６が実行され、ステップＳ７−４でアドレストランザクションが強制リトライ状態ではない場合には、ステップＳ７−６が実行される。
【００５８】
ステップＳ７−５は、リトライ制御部２２ｂに過剰リトライ状態である旨を通知する。
ステップＳ７−６は、過剰リトライ状態が解消したか否か判定する。
ステップＳ７−６で、過剰リトライ状態が解消したと判断された場合には、ステップＳ７−７が実行される。
【００５９】
ステップＳ７−７は、リトライ制御部２２ｂへの過剰リトライ状態の通知を停止する。
リトライ監視部２３ａでは、上記ステップＳ７−１〜Ｓ７−７が繰り返される。
本実施例によれば、特殊なアドレストランザクションの存在を許しつつも、過剰リトライ状態のアドレストランザクションを効率的に処理できる。
【００６０】
次に、本発明の第３実施例について説明する。
本実施例は、アドレストランザクションをグループ分けして制御する場合の実装例を示す。なお、本実施例の構成は、第１実施例と同一であり、リトライ制御部２２ｂ及びリトライ監視部２３ａでの処理が相違するだけであるので、構成についての説明は省略する。
【００６１】
図１５は本発明の第３実施例のアドレストランザクションのデータ構成図を示す。
本実施例のアドレストランザクションは、図１５（A ）に示すようにトランザクション情報Ｔ１〜Ｔｎ及びアドレス９１から構成される。
図１５（Ｂ）に示すようにアドレス９１の上位ビット９１−１は、アドレスのキャッシュライン毎のグループ分けに用いられる。
【００６２】
また、図１５（Ｃ）に示すようにトランザクション情報Ｔｘ及びアドレスの上位ビット９１−２は、アドレスが含まれるプロセッサのグループ分けに用いられる。なお、トランザクション情報Ｔｘは、トランザクション情報Ｔ１〜Ｔｎのうちの任意のトランザクション情報を示す。
次に、リトライ制御部２２ｂの動作について説明する。
【００６３】
図１６は本発明の第３実施例のリトライ制御部の処理フローチャートを示す。リトライ制御部２２ｂは、ステップＳ８−１〜Ｓ８−７を実行する。ステップＳ８−１は、制御下のアドレストランザクションが過剰のリトライ状態か否かを判定する。ステップＳ８−１でアドレストランザクションが過剰リトライ状態である場合には、ステップＳ８−２、Ｓ８−３が実行された後ステップＳ８−４が実行される。また、ステップＳ８―１でアドレストランザクションが過剰リトライ状態でない場合には、次にステップＳ８−４が実行される。
【００６４】
ステップＳ８−２は、過剰にリトライされたアドレストランザクションの存在をリトライ監視部２３ａに通知する。ステップＳ８−３は、発行するアドレストランザクションに過剰にリトライされたアドレストランザクションである旨のマークを付ける。
ステップＳ８−４は、システムの配下のアドレストランザクションが属するグループが過剰リトライ状態か否かを判定する。アドレストランザクションが属するグループは、例えば、図１５（Ｂ）に示すアドレス９１の上位ビット９１−１や図１５（Ｃ）に示すトランザクション情報Ｔｘ及びアドレス９１の上記ビット９１−２により判定できる。
【００６５】
ステップＳ８−４で、システムの配下のグループが過剰リトライ状態である場合には、ステップＳ８―５が実行される。ステップＳ８−５は、特殊なアドレストランザクションか否かを判定する。ステップＳ８−５で特殊なアドレストランザクションであると判断された場合には、ステップＳ８−６が実行され、特殊なアドレストランザクションでなないと判断された場合には、ステップＳ８−７が実行される。
【００６６】
ステップＳ８−６は、特殊なアドレストランザクションの発行頻度を低下させる。ステップＳ８−７は、他のアドレストランザクションの発行を抑制する
次に、リトライ監視部２３ａの動作を説明する。
図１７は本発明の第３実施例のリトライ監視部の動作フローチャートを示す。
リトライ監視部２３ａは、ステップＳ９−１〜Ｓ９−７の処理を実行する。
【００６７】
ステップＳ９−１は、制御下のアドレストランザクションは過剰リトライ状態か否かを判定する。ステップＳ９−１で制御下のアドレストランザクションが過剰リトライ状態である場合には、ステップＳ９−２〜Ｓ９−４が実行された後ステップＳ９−５が実行される。また、ステップＳ９−１で、制御下のアドレストランザクションが過剰リトライ状態ではない場合には、次にステップＳ９−５が実行される。
【００６８】
ステップＳ９−２は、バス制御部５からのアドレストランザクションが制御下のグループと同一のグループか否かを判定する。ステップＳ９−２で、同一グループである場合には、次にステップＳ９−３が実行され、同一グループでない場合には、次にステップＳ９−５が実行される。
ステップＳ９−３は、バス制御部５からのトランザクションが特殊なトランザクションか否かを判定する。ステップＳ９−３で特殊なトランザクションであると判定された場合には、次にステップＳ９−５が実行され、特殊なトランザクションではないと判定された場合には、次にステップＳ９−４が実行される。
【００６９】
ステップＳ９−４は、他のトランザクションを強制的リトライ状態にする。
ステップＳ９−５は、スヌープ結果が強制的リトライ状態か否かを判定する。ステップＳ９−５で、スヌープ結果が強制的リトライ状態であると判定された場合には、次にステップＳ９−７が実行され、スヌープ結果が強制的リトライ状態ではないと判定された場合には、次にステップＳ９−６が実行された後ステップＳ９−７が実行される。
【００７０】
ステップＳ９−６は、リトライ制御部２２ｂにグループ情報の通知及び過剰リトライ状態である旨の通知を行なう。
ステップＳ９−７は、過剰リトライ状態が解消したが否かが判定される。ステップＳ９−７で、過剰リトライ状態が解消していないと判断された場合には、そのまま処理を終了する。また、ステップＳ９−７で過剰リトライ状態が解消したと判断された場合には、次にステップＳ９−８が実行される。
【００７１】
ステップＳ９−８は、リトライ制御部２２ｂへのグループ情報の通知及び過剰リトライ状態である旨の通知を停止する。
リトライ監視部２３ａは、上記ステップＳ９−１〜Ｓ９−７の処理をバス制御部５からアドレストランザクションが供給される毎に実行する。
なお、アドレストランザクションのグループ分けは、複数のグループで過剰リトライ状態が干渉しないように行なわれる。
【００７２】
グループの分類方法としては、アドレスのキャッシュライン毎、及びアドレスの対象が含まれるプロセッサ毎などの分類方法がある。
また、過剰なリトライが発生したアドレストランザクションのグループ分類を切り換えることにより、優先してリトライが行なわれるようにしてもよい。
図１８は本発明の第３実施例の変形例のリトライ制御部の動作フローチャートを示す。
【００７３】
グループ分類を切り換える処理は、ステップＳ１０−１〜Ｓ１０−５から構成される。
ステップＳ１０−１は、制御下の所定のアドレストランザクションが過剰にリトライされているか否かを判定する。ステップＳ１０−１で過剰にリトライされた状態であると判定された場合には、次に、ステップＳ１０−２が実行される。また、ステップＳ１０−１で過剰にリトライされた状態ではないと判定された場合には、そのまま処理を終了する。
【００７４】
ステップＳ１０−２は、所定のアドレストランザクションが別のグループ分類でも新たに過剰リトライ状態とされたか否かがが判定される。ステップＳ１０−２で、別のグループ分類でも過剰リトライ状態とされた場合には、次にステップＳ１０−３が実行された後、Ｓ１０−４が実行される。また、ステップＳ１０−２で、別のグループ分類では過剰リトライ状態とされていない場合には、そのまま処理を終了する。
【００７５】
ステップＳ１０−３は、所定のアドレストランザクションが属する複数のグループ分類を比較する。
ステップＳ１０−４は、新たなグループ分類の優先順位が別のグループ分類より高いか否かを判定する。ステップＳ１０−４で、新たに過剰リトライ状態とされたグループ分類の優先順位が高い場合には、ステップＳ１０−５を実行する。また、ステップＳ１０−４で、新たに過剰リトライ状態とされたグループ分類の優先順位が元のグループ分類より低い場合には、そのまま処理を終了する。
ステップＳ１０−５は、制御対象とするグループ分類を新たなグループ分類に設定する。
【００７６】
本変形例によれば、グループ分類の設定を優先順位の高いグループ分類に切り換えることにより、優先してリトライ処理が行なわれ、過剰リトライ状態を解消できる。
なお、本実施例では、図１に示すようにＮ個のプロセッサ２−１〜２−Ｎをシステムバス６に接続してメモリ３を共有する場合について説明したが、複数のプロセッサとメモリからなるシステムボードをシステムバス６に接続するようにしてもよい。
【００７７】
図１９は本発明の他の適用例のブロック構成図を示す。同図中、図１と同一構成部分には同一符号を付し、その説明は省略する。
本適用例のシステム１００は、Ｍ個のシステムボード１０１−１〜
１０１−Ｍをシステムバス６に接続してなる。システムボード１０１−１〜１０１−Ｍは、Ｎ個のプロセッサ１０２−１〜１０２−Ｎ及びメモリ１０３から構成される。システムバス６には、Ｍ×Ｎ個のプロセッサが接続される。各プロセッサは、アドレストランザクションにエラーが発生した場合には、上記のような処理によってリトライ処理が実行される。
【００７８】
【発明の効果】
上述の如く、本発明によれば、トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態が検出された場合にはバスに対する他のトランザクションの発行を抑止することにより、処理を一定時間内に終了させることを保証でき、よって、処理がタイムアウトし、システムダウンすることを防止できる等の特長を有する。
【００７９】
また、本発明によれば、所定の条件に基づいて過剰リトライ状態が解消したか否かの検査を行うための検査用トランザクションの要求を行い、検査用トランザクションが抑制されない場合には過剰リトライ状態が解消したものと判断することにより、通常処理への影響を低減できる等の特長を有する。
さらに、本発明によれば、複数のトランザクションを複数のグループに分類し、所定のトランザクションが属するグループに含まれる他のトランザクションの要求を抑止することにより、処理の要求の抑制を影響が大きい処理だけに限定することができ、関係のない処理への影響は低減できる等の特長を有する。
【図面の簡単な説明】
【図１】マルチプロセッサシステムのブロック構成図である。
【図２】従来の一例の要部の構成図である。
【図３】従来の一例のパイプライン処理の動作説明図である。
【図４】本発明の第１実施例のブロック構成図である。
【図５】本発明の第１実施例のリトライ制御部の処理フローチャートである。
【図６】本発明の第１実施例の動作を説明するための図である。
【図７】本発明の第１実施例のリトライ監視部の処理フローチャートである。
【図８】本発明の第１実施例のリトライ制御部の過剰リトライ状態を判定する処理のフローチャートである。
【図９】本発明の第１実施例のリトライ監視部の過剰リトライ状態を判定する処理のフローチャートである。
【図１０】本発明の第１実施例の過剰リトライ状態を判定する方法を説明するための図である。
【図１１】本発明の第１実施例のリトライ制御部の過剰リトライ判定処理の変形例のフローチャートである。
【図１２】本発明の第１実施例の過剰リトライ判定処理の変形例に用いられる検査用トランザクションを説明するための図である。
【図１３】本発明の第２実施例のリトライ制御部のフローチャートである。
【図１４】本発明の第２実施例のリトライ監視部の処理フローチャートである。
【図１５】本発明の第３実施例のアドレストランザクションのデータ構成図である。
【図１６】本発明の第３実施例のリトライ制御部の処理フローチャートである。
【図１７】本発明の第３実施例のリトライ監視部の動作フローチャートである。
【図１８】本発明の第３実施例の変形例のリトライ制御部の動作フローチャートである。
【図１９】本発明の他の適用例のブロック構成図である。
【符号の説明】
１ マルチプロセッサシステム
２−１〜２−Ｎ プロセッサ
３ メモリ
４ 入出力装置
５ バス制御部
６ システムバス
２１ 演算部
２２ アドレス制御部
２２ａ キュー発行部
２２ｂ リトライ制御部
２２ｃ カウント部
２３ スヌープ制御部
２３ａ リトライ監視部
Ｃ０１、Ｃ０２ カウンタ
Claims (7)
- バスに接続された処理手段を有し、該処理手段により前記バスに対してトランザクションの発行を行う情報処理装置において、
前記処理手段は、検査用トランザクションを発行して、所定のリトライ回数を超えた場合に、前記トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態を検出する過剰リトライ状態検出手段と、
前記過剰リトライ検出手段により過剰リトライ状態が検出された場合には、前記バスに対して、過剰リトライ状態でないトランザクションの発行を抑制する処理制御手段とを有することを特徴とする情報処理装置。 - 前記処理制御手段は、前記複数のトランザクションを複数のグループに分類し、所定のトランザクションが属するグループに含まれる他のトランザクションの要求を抑制することを特徴とする請求項１記載の情報処理装置。
- 複数のトランザクションを処理する情報処理装置のトランザクション処理方法において、
前記処理手段は、検査用トランザクションを発行して、所定のリトライ回数を超えた場合に、前記トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態を検出する過剰リトライ状態検出手順と、
前記過剰リトライ検出手段により過剰リトライ状態が検出された場合には、前記バスに対して、過剰リトライ状態でないトランザクションの発行を抑制する処理制御手順とを有することを特徴とするトランザクション処理方法。 - データ処理を行うとともに、前記データ処理の処理結果に応じてアドレストランザクションの要求を行う演算部と、前記アドレストランザクションの要求に応じてアドレストランザクションの発行を行うキュー発行部と、前記キュー発行部によるアドレストランザクションを再発行するアドレスリトライ制御を行うリトライ制御部とを有するプロセッサであって、
前記アドレスリトライ制御部は、検査用トランザクションを発行して、所定のリトライ回数を超えた場合に、前記トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態を検出し、前記過剰リトライ状態を検出した場合、前記リトライ制御部を制御することによって過剰リトライ状態でない他のアドレストランザクションの発行を抑制することを特徴とするプロセッサ。 - データ処理を行うとともに、前記データ処理結果に応じてアドレストランザクションの要求を行う演算部と、前記アドレストランザクションの要求に応じてアドレストランザクションの発行を行うキュー発行部と、前記キュー発行部によるアドレストランザクションを再発行するものであるアドレスリトライの制御を行うリトライ制御部とを有するプロセッサにおいて、
前記リトライ制御部は、前記アドレスリトライ制御部は、検査用トランザクションを発行して、所定のリトライ回数を超えた場合に、前記トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態を検出し、過剰リトライ状態を検出した場合には過剰リトライ状態のアドレスリトライを優先的に発行することを特徴とするプロセッサ。 - データ処理を行うとともに、前記データ処理の結果に応じてアドレストランザクションの要求に応じてアドレストランザクションの発行を行うキュー発行部と、前記キュー発行部によるアドレストランザクションを再発行するものであるアドレスリトライの制御を行うリトライ制御部とを有するプロセッサにおいて、
前記アドレスリトライ制御部は、検査用トランザクションを発行して、所定のリトライ回数を超えた場合に、前記トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態を検出し、過剰リトライ状態を検出した場合に、前記過剰リトライ状態のアドレス状態のアドレストランザクションにマーキングを行うことを特徴とするプロセッサ。 - データ処理を行うとともに、前記データ処理の結果に応じてアドレストラン ザクションの要求に応じてアドレストランザクションの発行を行うキュー発行部と、前記キュー発行部によるアドレストランザクションを再発行するものであるアドレスリトライの制御を行うリトライ制御部とを有する情報処理装置において、
前記アドレスリトライ制御部は、検査用トランザクションを発行して、所定のリトライ回数を超えた場合に、前記トランザクションの再発行であるリトライが過剰に要求された過剰リトライ状態を検出し、過剰リトライ状態を検出した場合に、前記過剰リトライ状態のアドレス状態のアドレストランザクションにマーキングを行うことにより、前記システムバスに接続された他のプロセッサに前記過剰リトライ状態を通知することを特徴とする情報処理装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35372899A JP4144986B2 (ja) | 1999-12-13 | 1999-12-13 | 情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法 |
| US09/668,377 US6691191B1 (en) | 1999-12-13 | 2000-09-25 | Transaction retry in multi-processor system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35372899A JP4144986B2 (ja) | 1999-12-13 | 1999-12-13 | 情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007038222A Division JP4610570B2 (ja) | 2007-02-19 | 2007-02-19 | 情報処理装置及びトランザクション処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001167048A JP2001167048A (ja) | 2001-06-22 |
| JP4144986B2 true JP4144986B2 (ja) | 2008-09-03 |
Family
ID=18432824
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP35372899A Expired - Fee Related JP4144986B2 (ja) | 1999-12-13 | 1999-12-13 | 情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6691191B1 (ja) |
| JP (1) | JP4144986B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6912608B2 (en) * | 2001-04-27 | 2005-06-28 | Pts Corporation | Methods and apparatus for pipelined bus |
| US20040059858A1 (en) * | 2002-09-23 | 2004-03-25 | Blankenship Robert G. | Methods and arrangements to enhance a downbound path |
| US7099971B1 (en) * | 2003-06-26 | 2006-08-29 | Emc Corporation | Arbitration system |
| US7484131B2 (en) * | 2005-09-13 | 2009-01-27 | International Business Machines Corporation | System and method for recovering from a hang condition in a data processing system |
| US7529866B2 (en) | 2005-11-17 | 2009-05-05 | P.A. Semi, Inc. | Retry mechanism in cache coherent communication among agents |
| CN100511162C (zh) * | 2006-09-29 | 2009-07-08 | 华为技术有限公司 | 一种隔离总线故障的方法、装置与一种单板 |
| JP4362135B2 (ja) | 2007-02-13 | 2009-11-11 | 富士通株式会社 | データ転送装置およびデータ転送方法 |
| JP4975605B2 (ja) * | 2007-12-26 | 2012-07-11 | 東京エレクトロン株式会社 | 処理システム、処理システムの制御方法およびソフトウェアのバージョンアップ方法 |
| JP4969513B2 (ja) * | 2008-05-14 | 2012-07-04 | 三菱電機株式会社 | データ転送システム |
| EP2829986B1 (en) * | 2013-05-20 | 2017-07-12 | Huawei Technologies Co., Ltd. | Computer system, access method and apparatus for peripheral component interconnect express endpoint devices |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU633724B2 (en) * | 1990-06-29 | 1993-02-04 | Digital Equipment Corporation | Interlock queueing |
| US5546546A (en) * | 1994-05-20 | 1996-08-13 | Intel Corporation | Method and apparatus for maintaining transaction ordering and arbitrating in a bus bridge |
| US5706446A (en) * | 1995-05-18 | 1998-01-06 | Unisys Corporation | Arbitration system for bus requestors with deadlock prevention |
| US5644733A (en) * | 1995-05-18 | 1997-07-01 | Unisys Corporation | Dual coupled partitionable networks providing arbitration logic for managed access to commonly shared busses |
| US6128677A (en) * | 1997-10-15 | 2000-10-03 | Intel Corporation | System and method for improved transfer of data between multiple processors and I/O bridges |
-
1999
- 1999-12-13 JP JP35372899A patent/JP4144986B2/ja not_active Expired - Fee Related
-
2000
- 2000-09-25 US US09/668,377 patent/US6691191B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US6691191B1 (en) | 2004-02-10 |
| JP2001167048A (ja) | 2001-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4144986B2 (ja) | 情報処理装置、及び、トランザクション処理方法、プロセッサ、並びに、リトライ方法 | |
| US5796941A (en) | Method for supervising software execution in a license restricted environment | |
| US6920516B2 (en) | Anti-starvation interrupt protocol | |
| US7136970B2 (en) | Storage system and dynamic load management method thereof | |
| US7793143B2 (en) | Switching a defective signal line with a spare signal line without shutting down the computer system | |
| US5404535A (en) | Apparatus and method for providing more effective reiterations of processing task requests in a multiprocessor system | |
| US10560537B2 (en) | Function based dynamic traffic management for network services | |
| US20150067277A1 (en) | Multiprocessor system for restricting an access request to a shared resource | |
| CN110399034A (zh) | 一种SoC系统的功耗优化方法及终端 | |
| US8417974B2 (en) | Power efficient stack of multicore microprocessors | |
| JP4610570B2 (ja) | 情報処理装置及びトランザクション処理方法 | |
| US20040143691A1 (en) | Sender to receiver request retry method and apparatus | |
| CN102169454A (zh) | 多处理器调试串口电路切换方法、装置及系统 | |
| US9053031B2 (en) | System and method for handling data access | |
| CN1255717C (zh) | 用于在盘驱动器接口之间共享中断的方法和设备 | |
| GB2409906A (en) | Testing agents in a computer system using harassing transactions from a library | |
| US8959290B2 (en) | Methods and apparatus for reusing snoop responses and data phase results in a cache controller | |
| JP2024505635A (ja) | 監視排他命令 | |
| US11900164B2 (en) | Intelligent query planning for metric gateway | |
| CN117234711B (zh) | Flink系统资源动态分配方法、系统、设备及介质 | |
| JP2000122832A (ja) | プリンティングジョブ管理装置およびプリンティングジョブ管理方法並びにプリンティングジョブ管理プログラムを記憶した記憶媒体 | |
| CN106502947A (zh) | 一种基于vpx总线的多处理器计算机任务动态分配方法 | |
| CN116991576A (zh) | 跑批作业任务的调节方法、装置、电子设备和存储介质 | |
| JPH1069404A (ja) | データ処理装置 | |
| JP3403932B2 (ja) | データ入出力装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060308 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060322 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060517 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20061219 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070219 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070219 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070426 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080610 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080617 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110627 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120627 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120627 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130627 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140627 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |