- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
コピーされたリンク
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
After talking to more folks, I realized the answer is there in the optimization guide.
The manual says The event IDQ_UOPS_NOT_DELIVERED counts when the maximum of four microops are not delivered to the rename stage, while it is requesting micro-ops. When the pipeline is backed up the rename stage does not request any further micro-ops from the front end.
So, when there are cache misses (back end stalls), the rename stage is not requesting uops and so the front-end is not delivering uops and so this counter doesnt increment.
The methodology in sections B.3.2-B.3.7is intended to be used in sequence.
First determine if you are front or back end stalled (section B.3.2) and then, if you are front end stalled, use section B.3.7 to further analyze the workload.
Or, as the manual puts it:
B.3.7 Front End Stalls
Stalls in the front end should not be investigated unless the analysis in Section B.3.2
showed at least 30% of a granularity being bound in the front end.
Sound reasonable?
Pat
