このページの本文へ

前へ 1 2 3 次へ

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

チップセット黒歴史 負荷低減策が負荷を招いたIntel 5000X

2013年07月08日 12時00分更新

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

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

キャッシュを確認する動作を抑え、FSBの利用効率を上げる
スヌープフィルター

 そこで登場したのがスヌープフィルターである。これは、FSB #1とFSB #2のそれぞれで、どんなメモリー領域がキャッシュされているかを自身のスヌープキャッシュに搭載している。また、スヌープキャッシュの管理や、スヌーピング自身のトラフィック管理を行なうスヌープコントローラーもチップセット側に追加されている。

 さて、この状況でまたCPU #1がメモリーを書き換えたらどうなるだろうか。まずキャッシュのライトバックそのものは、図2と同じように行なわれる。変わるのはここからで、書き込みが完了したらCPU #1はスヌープの通知を発行するが、これはチップセットに入った段階でそのスヌープコントローラーが一旦受け取る(図4)。

図4

 ここでスヌープコントローラーはスヌープキャッシュを参照し、「このスヌープ通知をFSB #2に流す必要があるか」(CPU #2がそのメモリー領域をキャッシュしているかどうか)を確認する。

 ここでもしキャッシュしていなければ、そもそもFSB #2にスヌープ通知を流す必要がないので破棄、一方もしキャッシュされていれば、スヌープコントローラーが改めてFSB #2にスヌープ通知を送り出す(図5)という仕組みである。

図5

 スヌープフィルターによるメリットは、不必要なスヌープ通知を削減できる可能性があることだ。2つのCPUがお互いに同じようなメモリー領域を書き換えながら処理を進めている状況ではスヌーピングを削減できないが、お互いが別々のメモリー領域にアクセスしながら処理しているような場合だと、スヌープ通知は不要だし、むしろオーバーヘッドになるだけである。

 そもそもスヌープ通知をCPUではなくチップセットが出すような作りになっていれば、スヌーピングのトラフィックを最小にするようなことも可能だった。ところが、長らく共有バス方式を取ってきておりスヌープ通知の発行そのものもCPU側に搭載しているXeonの場合、過去との互換性を保つ必要があり、今更チップセットがスヌープを出すようには変更できない。それでも2本のFSBの間を分断するだけで、性能が改善すると見込めたのだろう。

 スヌープフィルターという方式はGreencreekだけでなく、2007年に登場したClarksboroことIntel 7300 MCHや、AMDもHT Assistという名称でIstanburコアOpteronなどに実装するなど、それなりに普及した方法である。ちなみにAMDの場合、3次キャッシュの一部をスヌープキャッシュとして利用するという形の実装になっている。

スヌープフィルターを使うと
高負荷時以外は性能が低下する

 こうしたスヌープフィルターを実装したGreencreekがなぜ黒歴史だったかというと、「スヌープフィルターを有効にすると遅くなる」からである。

 インテルが当時発表した性能レポートを見ると、高負荷時には確かに効果的というレポートが出ていた。またインテル製品を利用したソリューションベンダーのレポート、例えばHPCテクノロジーズのこちらや、こちらを見ると、スヌープフィルターが効果的というレポートが示されるが、逆に低負荷時には性能が落ちるという話が頻発した。理由は単純で、スヌープコントローラーの処理が遅かったからだ。

 スヌープコントローラーは以下の処理を行なう。

  • スヌープ通知を受け取り、どのメモリ領域が対象か確認する。
  • 自身のキャッシュを確認して、それがキャッシュ対象かを確認する。
  • キャッシュ対象の場合にスヌープを反対側のFSBに発行する。

 この判断のために毎回16MB分のキャッシュ領域を総なめする必要があった。おまけに、スヌープを発行すべきかどうかを判断するまで、反対側のCPUの処理を止めないと危険なため、頻繁にwaitが入ることになる。もしもスヌープ対象かどうかを判断中に、まさにその領域を別のCPUが書き換えた場合には、回復不能エラーになりかねないからだ。

 また、メモリーの書き込みにあわせてスヌープキャッシュの更新も行なわなければならない。このため、メモリーの書き込み速度そのものがIntel 5000Pより遅いという、本末転倒な状況に陥ることになった。

 高負荷時には、こうしたオーバーヘッドを埋めて余るほどスヌーピングのオーバーヘッドが大きいため効果があるが、そうでないとむしろ性能が低下するわけで、結果としてIntel 5000Xを導入したサイトの大多数がBIOSセットアップでスヌープフィルターの機能を殺し、単にIntel 5000P相当として利用するという結果になった。

Intel 5000Xチップセットを搭載するSupermicro製マザーボード「X7DA8」

 インテルはこれに対してどう対処したかというと「何もしなかった」。というより何も出来なかったというほうが正解だろう。

 こうなると、ファームウェアの改善などでどうにかなるレベルではない。幸いにも翌年には、1600MHz FSBや800MHz FB-DIMMなどに対応したSeaburgことIntel 5400チップセットがリリースされ、これに搭載されたスヌープフィルターはスヌープコントローラーとキャッシュを高速化したために問題が解決した。こうしてスヌープフィルターの問題は下火になった。

 スヌープフィルター実装の第一世代だけに、問題が出るのは致し方ないことではあったろうが、鳴り物入りで発表されたにも関わらず、あっという間に引っ込められてしまったあたり(とはいえ、無かったことにはしないあたりはさすがインテルであるが)、初めから捨石扱いだった可能性が高い。

 実のところIntel 5000シリーズチップセット全体が、RAMBUSによる特許問題で登場が遅れてしまっており、結果この5000シリーズチップセットが出た翌月には、Core 2ベースの「Xeon 5100」シリーズが登場することになった。
※:FB-DIMMに搭載されているAMBというチップがRAMBUSの特許を侵害していると訴えられた問題。最終的にFB-DIMMベンダーが個別にRAMBUSとライセンスを結ぶことで解決した。

 「Xeon 5100」でももちろんIntel 5000シリーズチップセットが利用できたが、本命のチップセットは翌年出るSeaburgであり、それまでの1年を繋げれば良い、ということで投入されたようだ。そういう意味では、最初からややかわいそうな子だったのかもしれない。

前へ 1 2 3 次へ

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

最新記事

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

ピックアップ

ASCII.jp RSS2.0 配信中

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