このページの本文へ

ロードマップでわかる!当世プロセッサー事情 第78回

マルチコアCPUのキャッシュで問題となるコヒーレンシと解決策

2010年11月22日 12時00分更新

文● 大原雄介(http://www.yusuke-ohara.com/)

  • この記事をはてなブックマークに追加
  • 本文印刷

Xeonが直面したスヌープによるオーバーヘッド
解決策は「スヌープフィルタキャッシュ」の導入

 前ページの図1はマルチプロセッサー環境の場合だが、当然ながらマルチコアの場合も同じ問題が発生する。しかし、マルチプロセッサー環境よりもコア間が高速に接続される分だけスヌープも高速になるため、これに要するオーバーヘッドは少なかった。

 ただしこれは、インテルCPUでは「Core Duo」「Core 2 Duo」や「Core i」シリーズ、AMDなら「Athlon 64 X2」以降といった、1ダイのマルチコア製品の話だ。インテルの「Pentium D」や「Core 2 Quad」シリーズ、AMDでは「Opteron 6000」シリーズのMCMパッケージ製品の場合、実際には図1のケースと差がないので注意されたい。

 さて問題は、もっと大規模なケースである。最初にこの問題に直面したのは、インテルの「Xeon」系列CPUである。Xeon系列の場合、FSBの制約があってMCMを使ったマルチコアが利用できず、やむなくFSBを2つに分けることで、MCM構造のマルチコアCPUを利用できるようになった(関連記事)。

 しかし、この設計はスヌーピングにも大きな影響を与えることになった。というのは、スヌープに必要なトラフィックの頻度は、おおむね「コア数の2乗」に比例するからだ(正確には、コア数をnとすると、トラフィックは「n(n-1)」倍になる)。

 例えば、CPU #1~#4までが独立して動き、勝手にメモリーをアクセスして勝手に書き戻しているとする。この場合、以下の4パターンのスヌープが発生することになる。

  • CPU #1からCPU #2~#4へのスヌープ
  • CPU #2からCPU #1/#3/#4へのスヌープ
  • CPU #3からCPU #1/#2/#4へのスヌープ
  • CPU #4からCPU #1~#3へのスヌープ

 もちろんスヌープ処理に一斉発信(Broadcast)の仕組みを使えば、(コア数の二乗から、コア数に比例する程度まで)トラフィックは減るが、それでも8~16コアのシステムを作るためには、もう少しスヌープの頻度を減らさないと、FSBの帯域そのものを占有してしまう。さらに、FSBの帯域にスヌーピングそのものが制約されてしまい、キャッシュスヌープ待ちで無駄にCPUが待たされてしまう。

 これを解決すべく、「Intel 5000X」チップセットで初めて投入されたのが「スヌープフィルタ」である(関連記事)。Intel 5000Xは内部に、16MBの「スヌープフィルタキャッシュ」と呼ばれるメモリーを搭載する。名前はキャッシュだが、実体としてはタグとコヒーレント情報(つまりMESIの状態)のみを保存するものだ。

Intel 5000Xの構成

図4 Intel 5000Xの構成

 スヌープフィルタの働きを、CPU #1のあるCPUコア(#1α)がメモリーに書き込んだ場合を例に見てみよう(図5)。

図5

図5 CPU #1αがメモリーに書き込んだ場合の、スヌープフィルタの働き

  • ①スヌープ情報がFSB経由でチップセットおよび、#1αとFSBを共有する#1βに伝わる。
  • ②チップセットはその情報を、スヌープフィルタキャッシュに反映させる。
  • ③チップセットはスヌープフィルタキャッシュの情報を元に、その書き換わったアドレスをCPU #2側がキャッシュしているかどうか判断する。ここでキャッシュしている場合は、CPU #2側にスヌープ情報を送り出す。

 従来であれば、あるCPUコアがメモリーを書き換えようとした時に、ほかのコアが同じアドレスをキャッシュしているかどうかを知る方法がなかった。そのため、とりあえずスヌープは無条件で出す必要があった。これがスヌープによるトラフィック増加を招いてしまう。必要ないスヌープを途中で排除することで、FSBの利用効率を上げようというのが、スヌープフィルタの仕組みである。

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン