次はMemory Access関係である(Photo15)。Memory Disambiguation/Hardware Prefetch/Advanced Smart Cacheのあたりに関しては、従来のCore Microarchitectureをそのまま引き継いでいる様で、全くの新機能はTLBと16BytesのUnaligned Access、Faster Syncronization Primitiveの3つとなる。

Photo15:もっとも最初の3つについても、機能強化がまるでなされていないとも思えないわけで、何かしらの改良はあるだろうと想像される。このあたりが公開されるのは秋のIDFだろうか?

まずTLBについてだが、従来のCore Microarchitectureの場合の構成を表1に示す。

表1

つまりデータTLBはDTLB0/DTLB1の2段構成だが、命令TLBは1段のみの構成となった。これに対してNehalemではPhoto16の様に変わった。Unified TLBという構成はあまり見かけないが、Data-Intensiveな場合とProgram-Intensiveな場合の両方に対応できる構成であることは間違いない。問題はProgram-Intensiveな場合がどの程度あるのか? という話だが、SMTによってコアあたりでハンドリングするプログラムのサイズが増える事を想定しているのかもしれない。ただこのUnified L2 TLBが4KB Pageのみというのは、やはりLarge Pageのハンドリングまですると複雑になりすぎてしまうからだろうか?

Photo16:Core Microarchitectureと比較した場合、4KB Pageの場合ではエントリ数が凄く増えたという訳ではない。ところがLarge Pageになると格段にエントリが増えている訳で、やはり主眼となるのはサーバーアプリケーション稼動時の性能向上と見なして良いだろう。

TLBについては、もう一つ話題がある。これはTLBというよりはPage Tableそのものという事になるが、Nehalemでは新しくEPT(Enhanced Page Table)と呼ばれる構造がサポートされた(Photo17)。まず、なぜEPTが必要か? という話だが、従来のPage Tableの構造では、仮想化環境上のOSでPage Tableを参照しても、実際にはそれに該当するページをアクセスするためにはVMM上でもう一度Page Tableを参照する必要があった(Photo18)ため、非常にアクセスが遅くなるという問題があった。これを解決するのが、新しいEPTである(Photo19)。これにより、Guest OSからのアクセスがそのままダイレクトに物理アドレスに変換できるので、Page FaultによるVM Exitの頻度が大幅に減る、という仕組みである。これは要するに、AMDがBarcelonaから搭載したNested Pageの技法そのものである。当然ながら新しいTLBは、このEPTをカバーすると思われる。Unified L2 TLBが512ものエントリを持つ理由は、特に仮想環境においてGuest OSやVMMなどが大量にPage Tableを抱え込む事と、EPTによりより多くのPage Tableを必要とすることの両方に対応するためと考えられる。

Photo17:これは後述するNehalemの拡張命令に関するセッションの中で明らかにされた話である。

Photo18:これは単に2回Page Tableをアクセスするから遅くなるというだけでなく、VMM側でPage Faultが発生するとVM EXITが発生、プロセッサコンテクストをVM上のGuest OSからVMMに移し、Page Inの操作後に再びVM EntriesでGuest OSに操作を戻すという作業が発生することにも起因する。このあたりがオーバーヘッドの非常に大きな要素となっている。

Photo19:これはちょっと判りにくいが、従来のIA32e/IA64のPage Tableの構造はそのまま残し、そこにもう一段EPTを追加する形になる。例えばIA32eにおける4KB Pageの場合、まずDirectory Entryを参照し、そこのEntryの内容が示すPage Tableを参照することで物理アドレスを算出するという2段階アクセスだが、EPT環境下ではこれが3段になるという仕組みだ。