- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »