さて、いよいよTLBの問題である。Errata #298といわれているこの問題、現時点で一番正確な情報はこちらと思われる(原稿執筆時点では、AMDの"Revision Guide for AMD Family 10h Processors"にはErrata #280までしか記載されていない)。簡単にまとめると、L2 TLBへの書き込み操作の一部がAtomicになっておらず、この結果L2 CacheとL3 Cacheの間でのModified Copyの操作が同時に行われた場合、TLBのAccessed Bit/Dirty Bitに不正な値が入ってしまう「可能性がある」というものである。「可能性がある」というのは、この時にAccessed Bit/Dirty Bitに書き込まれる値は一定のものであり、それが結果としてエラーになるか否かは状況によるからだ。また、複数のTLB更新が同時に行われない限り、問題は発生しないため、頻度としては非常に稀ではある。

根本的な対策は、TLBへの書き込みを全面的にAtomicにすることで、既にこの措置を行ったB3 Steppingの開発が進んでいるが、単に配線層のレイアウト変更のレベルではなく、(ごく一部とは言え)回路そのものの変更だから、それなりに作業機関を要する事は避けられない。それまでの対処として、TLBの変更があった場合、再度TLB中のAccessed Bit/Dirty Bitの値を設定しなおすという方法が(まもなく公開されると思われる新しい)Revision Guideに記載されるそうであるが、これにはカーネルの改変が必要である。

そこでマザーボードによっては、BIOSレベルでこれへの対処を行っている(Photo13)。ちょっと先ほどのグラフ18~26に戻るが、512+32 or 48エントリまではTLBのアクセスは一定のLatencyでアクセスできるが、その先は緩やかにLatencyが増加する。これは要するにLatencyが溢れても、L2/L3キャッシュを使ってPTEがキャッシュされているから、ここから読み出す形で対処しているわけだ。このキャッシュを止めてしまえば、原理上PTEの書き込みが壊れる事はない。勿論他にもTLBそのものをDisableにするとかL3キャッシュをDisableにする事でも対応できるが、これは当然ながら性能へのインパクトが大きすぎる。TLBへのキャッシュをDisableにするというのは、比較的性能に悪影響を与えにくい賢明なアイディアだろう。

Photo13:ASUSTeK M3A32-MVPの場合、BIOS Revision 0703以降でこの機能が搭載された。

もっとも、「悪影響を与えにくい」といってもそれはあくまで相対的な話。絶対的な性能としては悪化しない訳がない。グラフ30~35にI-TLB、グラフ36~41にD-TLBの、それぞれTLB CacheをEnableにした場合とDisableにした場合のLatencyをまとめてみた。

グラフ30

グラフ31

グラフ32

グラフ33

グラフ34

グラフ35

グラフ36

グラフ37

グラフ38

グラフ39

グラフ40

グラフ41

グラフ30~38までで判る通り、TLBにHitしている範囲ではLatencyに差は無い。問題はTLB Missの場合で、途端にLatencyが急増している。特にグラフ39~41はこれが判りやすい。TLB Cache Enableの場合、TLB Missの場合でも50Cycle前後でアクセスできるのが、TLB Cache Disableにすると軒並み450Cycle前後と、9倍近く遅くなってしまう。