アカウント名:
パスワード:
TLBを実装して使える場所は色々ありますが、今回は3rdキャッシュのTLBでMMU(Pageing)とは別のとこのTLBの話ですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
TLBエラッタえらいこっちゃ (スコア:1, 興味深い)
MMU付きのCPUの場合はほとんどTLBを持っておりまして、論物変換を高速に引くためにTLBを使っていますんで。
で、TLBがミスヒットしたらアドレス解決するために、計算したりメモリ読んだりしないといけないです。
これを回避ということは、わざわざTLBクリーンしていたとかそういうことなのでしょうかね。
それともALLMiss状態。。。恐ろしや。
マルチコアだとCPUでのキャッシュの扱いとか、MMUの整合性処理が大変そうですね。。。
Re: (スコア:0)
TLBを実装して使える場所は色々ありますが、今回は3rdキャッシュのTLBでMMU(Pageing)とは別のとこのTLBの話ですよ。
Re: (スコア:0)
ただ、バグが出る条件として L3 キャッシュがからんでいたので、
ページテーブルに関してはキャッシュ不能にして回避って話じゃ
ありませんでした?
Re:TLBエラッタえらいこっちゃ (スコア:5, 参考になる)
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41322.pdf
のProduct Errata #298。
概要だけ書いておくと、L2にあるTranslation tableのエントリのAccessedビットもしくはDirtyビットを立てるオペレーションがアトミックでないので、もしほかのCacheオペレーションと重なった場合、L2に最新のエントリが書き込まれる前に、L2に存在する古いエントリがL3に書き込まれる、といったバグ。
回避方法は親コメントにあるとおりTLBキャッシュを使用しない。
Re:TLBエラッタえらいこっちゃ (スコア:1)
TLBそのものを使用しないとなると、とんでもなくパフォーマンスが低下するんじゃないでしょうか。
命令フェッチやデータアクセスなどの「全てのメモリアクセス」が、
「MMUテーブルメモリの参照」と「実アドレスへのアクセス」という2段階の処理を行うことになるので、
メモリアクセス速度が半分になってしまいます。
ベンチマークの結果とかを見る限りでは、そこまでのひどいことにはなってないような。
「TLBそのものは使用するが、TLB用のデータはL1~L3キャッシュを利用しない」
(TLBへの書き込みは即メモリに書き出す)ってあたりが順当な気がします。
Re:TLBエラッタえらいこっちゃ (スコア:1)