自作CPUコアでランダムテストを回していて、いろいろ面倒な解析をしなければならなかった部分のメモ。
- 同じタイミングで2つの命令が何度もリプレイする場合の対処
今の実装では、LSUのパイプラインを2つもっていて、それぞれにリプレイキューを持たせている。 例えばLSU[0]で通常のロード命令を動かしていて、LSU[1]でアトミックアクセス命令を動かしているものとする。 ロード命令のほうが若く、アトミックアクセス命令が古いとする。
同時にL1Dキャッシュにアクセスし、バンクがぶつかったので、静的に優先度がつけられているLSU[1]にバンクコンフリクトが通知される。 ところがLSU[0]のロード命令は自分よりも古いアトミックアクセス命令が存在していることをSTQの検索で検知したので、リプレイキューに入ってある程度待ってから再開することにした。 全く同じタイミングで、LSU[1]のアトミックアクセス命令もリプレイのためにリプレイキューに入る。 面倒なので、それぞれのLSUパイプラインでリプレイキューを持っており、独立して管理される。
問題は、これは完全に偶然なのだが、2つのリプレイキューから当該命令がリプレイされるタイミングが全く同じで、同じようにコンフリクトとハザードが発生して2つの命令とも何度もリプレイキューに入りなおしてしまい、ここでデッドロックが発生する。
- 解決策：
いくつか解決策があるが、「そもそも何でアトミックアクセスを検知したロード命令が、アトミックアクセスと同じタイミングでリプレイしているのか」というのが問題だ。 これは、アトミックアクセスの実行完了をSTQエントリもしくはパイプラインを監視し、完了するまで待つ、ということで解消できるのだが、例えば当該アトミックアクセスのSTQエントリが解放されたからと言って油断はできない。なぜなら、リプレイを待っている間に再びSTQに新しい命令が割り当てられた場合、そのSTQの解放のタイミングを見逃す可能性があるからだ。
もうひとつ、L1Dのアクセスでそもそも古いアトミックアクセス命令に優先度が与えられなかったのも問題だ。この場合、2命令のAgeをチェックし優先度を動的に切り替えることも考えられるが、ちょっと論理的に面倒だ。 そう考えるとLSU[0]とLSU[1]でアクセスの優先度が静的なのもちょっと奇妙な話で、これを動的、あるいはある程度疑似的なポリシで変更してランダム性に頼る、というのもありなのかもしれない。
今のところベストな解決策が浮かんでいないが、もうちょっと検討したい。
