プロセサ間を接続するバス(2)

話は横道に逸れるが、Starfireを製品化したのはSun Microsystemsであるが、元々は、SPARCベースのミニスーパーコンピュータを開発していたFloating Point Systems(FPS)の設計に基づいている。FPSはその後Crayに買収され、そのCrayがSilicon Graphicsに買収される際に、SPARCベースの製品はシナジーが無いというので、FPSの残党と設計資産はSunに売り渡されるという歴史をたどった。

さらに言うと、同じくミニスーパーを開発していたConvexはHPに買収され、同社のExemplarがHPのハイエンドのS-Class、X-Classマシンとして販売され、その技術がSuperdomeの元になるV-Classに受け継がれて行った。つまり、FPSやConvexの設計は技術的には良かったのであるが、時期が早すぎ、用途としてミニスーパーコンピュータを目指したのがビジネス的には失敗で、それらの資産を継承したSunやHPがハイエンドのコマーシャルサーバとして展開して大成功を収めるという結果となった。

また、コモンバスやクロスバではなく、次に述べるAMD Opteonプロセサのように、Point-to-Pointの接続を用いる実装もある。図9.11は、2006年のHotChips18でのAMDの発表スライドであるが、P0～P3の4チップ間のコマンドとデータの流れを示している。Opteronのシステムでは、それぞれのチップに接続されたメモリがどのアドレスを分担するかが決まっている。そして、自チップのキャッシュをミスしたメモリアクセスは、そのアドレスのメモリを担当するプロセサチップ(ホームノードと呼ぶ)に送られる。

P3チップが1:でP2にリード要求を送り、P2は自分のメモリには要求されたアドレスが存在しないので、2:でリード要求をP0に送る。そして、P0は(ホームノードなので)自分のメモリにデータがあるので、3:でMemory0にリードを掛け、4:でデータを受け取る。

しかし、他のプロセサにそのアドレスのデータを持つキャッシュラインが存在する可能性があるので、プロセサP0は3:でP2とP1に対してプローブ(=スヌープ)を送る。プロセサP1は4:でプローブをP3に送り、全チップのプローブが終わる。プロセサP1とP2はプローブに対する応答をそれぞれ5:、4:で応答を返す。これにより、要求元のP3はどのチップのキャッシュにそのアドレスのキャッシュラインが格納されているかを知る。

プロセサP0はデータを持っているので、4:で応答RP0を返し、5:でデータをP2に送る。そしてP2はこれらを中継して、5:で応答RP0、6:でデータを要求元のP3に返す。さらにP3は6:でデータを受け取ると、7:でキャッシュ状態の変更指示をP1に送り、8:でP1がP0に指示を転送してリードが完了する。なお、P2にはキャッシュ状態の変更指示が送られておらず、4:RP0の受け取りで代用していると思われる。

コモンバスでなく、HyperTransportのようなPoint-to-Pointのバスでキャッシュコヒーレンシを実現するとこのような複雑な要求と応答のやり取りが必要となる。なお、この図からは、どのようなキャッシュコヒーレンスプロトコルを使っているのかは不明であるが、AMDがFamily 10hと呼ぶShanghaiプロセサのドキュメントでは、MOESIプロトコルを使っていると書かれており、以前のOpteronプロセサでも同様である可能性が高い。