Intel® 64 and IA-32 Architectures Optimization Reference Manual

USING PERFORMANCE MONITORING EVENTSthat allows qualification at the physical processor boundary or at bus agentboundary.Some events allow qualifications that permit the counting of microarchitecturalconditions associated with a particular core versus counts from all cores in a physicalprocessor (see L2 and bus related events in Appendix A of the Intel® 64 and IA-32Architectures Software Developer’s Manual, Volume 3B).When a multi-threaded workload does not use all cores continuously, a performancecounter counting a core-specific condition may progress to some extent on the haltedcore and stop progressing or a unit mask may be qualified to continue countingoccurrences of the condition attributed to either processor core. Typically, one canadjust the highest two bits (bits 15:14 of the IA32_PERFEVTSELx MSR) in the unitmask field to distinguish such asymmetry (See Chapter 18, “Debugging and PerformanceMonitoring,” of the Intel® 64 and IA-32 Architectures Software Developer’sManual, Volume 3B).There are three cycle-counting events which will not progress on a halted core, evenif the halted core is being snooped. These are: Unhalted core cycles, Unhalted referencecycles, and Unhalted bus cycles. All three events are detected for the unitselected by event 3CH.Some events detect microarchitectural conditions but are limited in their ability toidentify the originating core or physical processor. For example, bus_drdy_clocksmay be programmed with a unit mask of 20H to include all agents on a bus. In thiscase, the performance counter in each core will report nearly identical values. Performancetools interpreting counts must take into account that it is only necessary toequate bus activity with the event count from one core (and not use not the sumfrom each core).The above is also applicable when the core-specificity sub field (bits 15:14 ofIA32_PERFEVTSELx MSR) within an event mask is programmed with 11B. The resultof reported by performance counter on each core will be nearly identical.B.5.2Ratio InterpretationRatios of two events are useful for analyzing various characteristics of a workload. Itmay be possible to acquire such ratios at multiple granularities, for example: (1) perapplicationthread, (2) per logical processor, (3) per core, and (4) per physicalprocessor.The first ratio is most useful from a software development perspective, but requiresmulti-threaded applications to manage processor affinity explicitly for each applicationthread. The other options provide insights on hardware utilization.In general, collect measurements (for all events in a ratio) in the same run. Thisshould be done because:• If measuring ratios for a multi-threaded workload, getting results for all events inthe same run enables you to understand which event counter values belongs toeach thread.B-43