次はMemory Access関係である(Photo15)。Memory Disambiguation/Hardware Prefetch/Advanced Smart Cacheのあたりに関しては、従来のCore Microarchitectureをそのまま引き継いでいる様で、全くの新機能はTLBと16BytesのUnaligned Access、Faster Syncronization Primitiveの3つとなる。
まず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を必要とすることの両方に対応するためと考えられる。