このページの本文へ

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

仮想メモリーを支えるもうひとつのキャッシュ TLB

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

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

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

TLBはページテーブルエントリのキャッシュ
キャッシュ同様に階層化も進む

 だが、メモリーにページテーブルを置くとなると、今度は「煩雑にアクセスが発生した場合のレイテンシーの大きさ」が問題になる。「メモリーアクセスをするためのAddress Translationに先立って、まず変換テーブルをメモリーから読み込む」というのは、実質メモリーアクセスの速度が半分に落ちるに等しい。特にCPUの動作周波数が上がると、このオーバーヘッドが無視できないものになってきた。

 この問題に対する対策がTLBである。TLBは「PTE専用のキャッシュ」だ。格納されるのは「直前に利用されたPTE」のみであり、これを利用するのはAddress Translationのメカニズムのみである。

 こちらも以前は1段のTLBで済んでいたのが、命令/データ用が分かれたうえ、最近では「2次TLB」もでてきた。これはOSが利用するメモリーの量が段々増えてきて、同時に利用されるPTEの数が増えてきた結果、TLBを増量しないとキャッシュが有効に効かなくなってきたためだ。だからといって、TLBのエントリを無闇に増やすと(1次キャッシュ同様に)TLBの検索そのものに時間が掛かるので、複数段構成にしようというわけだ。

 ちなみにNehalem/WestmereベースのCore iシリーズの場合、その前のCore 2 Duo/Quadと比べると、TLBはちょっと複雑な構造になっている。

Nehalem/Westmere Core 2 Duo/Quad
1次命令TLB 128エントリ/コア
(64エントリ/スレッド)
4ウェイセットアソシエイティブ
128エントリ
4ウェイセットアソシエイティブ
1次データTLB 64エントリ
4ウェイセットアソシエイティブ
16エントリ
4ウェイセットアソシエイティブ
+64エントリ
4ウェイセットアソシエイティブ
2次TLB 512エントリ
4ウェイセットアソシエイティブ
なし

 利用する環境によって、必要とされるTLBの大きさは変わる。無尽蔵に大きなTLBを設ければ済む、というものではないことがおわかりいただけよう。ちなみにAMDの「K8」(Athlon 64)の場合、命令/データともに1次/2次TLBを持ち、さらに3次キャッシュが2次TLBとして動作できるような構造になっていた。今のNehalemコアのCore iシリーズなどよりも、遥かに大量のページを扱うことを想定した、非常にサーバー向けのアーキテクチャーと見ることもできよう。

 話を戻すと、このほかにx86系で使われた技術としては、「Pentium 4」の「トレースキャッシュ」(Trace Cache)と、Transmetaの「Crusoe」「Efficeon」で使われた「Translation Cache」が挙げられるが、これはどちらも似たものである。

 Pentium 4のTrace Cacheは図2のように、パイプラインの構造を通常と変えて、デコード後の命令をキャッシュするようにしたものだ。これによりデコードの処理を実際の処理の流れから切り離すことに成功し、特にループ処理などで効果的に働くはずだった。しかし、肝心のPentium 4の処理性能の低さもあってその効果はほとんど評価されなかった。

図2

図2 一般的なx86のパイプラインとPentium 4のパイプラインにおける命令キャッシュの位置

 ただ、インテルの内部ではこのTrace Cacheに一定の評価をしているようで、Nehalem/Westmereコアの「LSD」(Loop Stream Detector)を経て、まもなく登場する「SandyBridge」では、「Devoded μOps Cache」という形で、従来の1次キャッシュと並行して利用されることになる。

 Crusoe/Efficeonもこれに似ている(図3)。これらは、x86をまず独自のVLIW命令に変換する(これをコードモーフィングと呼ぶ。詳細はこちらの記事を参照)。その際に、変換後のVLIW命令を一時的に蓄えるTranslation Cacheと呼ばれるものが存在した。

図3

図3 x86のパイプラインとCrusoe/Efficeonのパイプラインの違い

 フェッチ/デコードをスケジューラー以降のパイプラインと分離して、間にキャッシュを挟むという方式は、x86に限らずほかのCPUアーキテクチャーでも見かける方式だ。しかし、以前は数命令分のバッファ程度、ということも多かった。ところが昨今では、性能改善のためにこのバッファを増やすケースが次第に増えてきている。将来的には、もっと多くのx86プロセッサーでも広く採用されていく可能性がある。

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

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

ピックアップ

ASCII.jp RSS2.0 配信中

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