Volume 3B System Programming Guide_ Part 2 (794104), страница 11
Текст из файла (страница 11)
3 18-45DEBUGGING AND PERFORMANCE MONITORING6335 34 33 32 312 1 0IA32_FIXED_CTR2 enableIA32_FIXED_CTR1 enableIA32_FIXED_CTR0 enableIA32_PMC1 enableIA32_PMC0 enableReservedFigure 18-14. Layout of IA32_PERF_GLOBAL_CTRL MSRThe fixed-function performance counters supported by architectural performanceversion 2 is listed in Table 18-13, the pairing between each fixed-function performance counter to an architectural performance event is also shown.IA32_PERF_GLOBAL_STATUS MSR provides single-bit status for software to querythe overflow condition of each performance counter. The MSR also provides additional status bit to indicate overflow conditions when counters are programmed forprecise-event-based sampling (PEBS). IA32_PERF_GLOBAL_STATUS MSR alsoprovides a sticky bit to indicate changes to the state of performance monitoring hardware. Figure 18-15 shows the layout of IA32_PERF_GLOBAL_STATUS.
A value of 1 inbits 0, 1, 32 through 34 indicates a counter overflow condition has occurred in theassociated counter.When a performance counter is configured for PEBS, overflow condition in thecounter generates a performance-monitoring interrupt signaling a PEBS event. On aPEBS event, the processor stores data records into the buffer area (see Section18.15.5), clears the counter overflow status., and sets the “OvfBuffer“bit inIA32_PERF_GLOBAL_STATUS.18-46 Vol. 3DEBUGGING AND PERFORMANCE MONITORING63 6235 34 33 32 312 1 0CondChgdOvfBufferIA32_FIXED_CTR2 OverflowIA32_FIXED_CTR1 OverflowIA32_FIXED_CTR0 OverflowIA32_PMC1 OverflowIA32_PMC0 OverflowReservedFigure 18-15.
Layout of IA32_PERF_GLOBAL_STATUS MSRIA32_PERF_GLOBAL_OVF_CTL MSR allows software to clear overflow indicator(s) ofany general-purpose or fixed-function counters using WRMSR once. Software shouldclear overflow indications when•Setting up new values in the event select and/or UMASK field for counting orsampling••Reloading counter values to continue samplingDisabling event counting or sampling.The layout of IA32_PERF_GLOBAL_OVF_CTL is shown in Figures 18-17.63 6235 34 33 32 312 1 0ClrCondChgdClrOvfBufferIA32_FIXED_CTR2 ClrOverflowIA32_FIXED_CTR1 ClrOverflowIA32_FIXED_CTR0 ClrOverflowIA32_PMC1 ClrOverflowIA32_PMC0 ClrOverflowReservedFigure 18-16. Layout of IA32_PERF_GLOBAL_OVF_CTRL MSRVol.
3 18-47DEBUGGING AND PERFORMANCE MONITORING18.12.3 Pre-defined Architectural Performance EventsTable 18-6 listings architecturally defined events.Table 18-6. UMask and Event Select Encodings for Pre-DefinedArchitectural Performance EventsBit PositionCPUID.AH.EBXEvent NameUMaskEvent Select0UnHalted Core Cycles00H3CH1Instruction Retired00HC0H2UnHalted Reference Cycles01H3CH3LLC Reference4FH2EH4LLC Misses41H2EH5Branch Instruction Retired00HC4H6Branch Misses Retired00HC5HA processor that supports architectural performance monitoring may not support allthe predefined architectural performance events (Table 18-6).CPUID.0AH:EAX[31:24] indicates events not available.The behavior of each architectural performance event is expected to be consistent onall processors that support that event. Minor variations between microarchitecturesare noted below:•UnHalted Core Cycles — Event select 3CH, Umask 00HThis event counts core clock cycles when the clock signal on a specific core isrunning (not halted).
The counter does not advance in the following conditions:— an ACPI C-state other than C0 for normal operation— HLT— STPCLK# pin asserted— being throttled by TM1— during the frequency switching phase of a performance state transition (seeChapter 13, “Power and Thermal Management”)The performance counter for this event counts across performance statetransitions using different core clock frequencies•Instructions Retired — Event select C0H, Umask 00HThis event counts the number of instructions at retirement. For instructions thatconsist of multiple micro-ops, this event counts the retirement of the last microop of the instruction.
An instruction with a REP prefix counts as one instruction(not per iteration). Faults before the retirement of the last micro-op of a multiops instruction are not counted.18-48 Vol. 3DEBUGGING AND PERFORMANCE MONITORINGThis event does not increment under VM-exit conditions. Counters continuecounting during hardware interrupts, traps, and inside interrupt handlers.•UnHalted Reference Cycles — Event select 3CH, Umask 01HThis event counts reference clock cycles while the clock signal on the core isrunning. The reference clock operates at a fixed frequency, irrespective of corefrequency changes due to performance state transitions.
Processors mayimplement this behavior differently. See Table A-3 and Table A-4 in Appendix A,“Performance-Monitoring Events.”•Last Level Cache References — Event select 2EH, Umask 4FHThis event counts requests originating from the core that reference a cache linein the last level cache. The event count may include speculation, but excludescache line fills due to a hardware-prefetch.Because cache hierarchy, cache sizes and other implementation-specific characteristics; value comparison to estimate performance differences is not recommended.•Last Level Cache Misses — Event select 2EH, Umask 41HThis event counts each cache miss condition for references to the last level cache.The event count may include speculation, but excludes cache line fills due tohardware-prefetch.Because cache hierarchy, cache sizes and other implementation-specific characteristics; value comparison to estimate performance differences is not recommended.•Branch Instructions Retired — Event select C4H, Umask 00HThis event counts branch instructions at retirement.
It counts the retirement ofthe last micro-op of a branch instruction.•All Branch Mispredict Retired — Event select C5H, Umask 00HThis event counts mispredicted branch instructions at retirement. It counts theretirement of the last micro-op of a branch instruction in the architectural path ofexecution and experienced misprediction in the branch prediction hardware.Branch prediction hardware is implementation-specific across microarchitectures; value comparison to estimate performance differences is not recommended.NOTEProgramming decisions or software precisians on functionality shouldnot be based on the event values or dependent on the existence ofperformance monitoring events.Vol. 3 18-49DEBUGGING AND PERFORMANCE MONITORING18.13PERFORMANCE MONITORING (INTEL® CORE™ SOLOAND INTEL® CORE™ DUO PROCESSORS)In Intel Core Solo and Intel Core Duo processors, non-architectural performancemonitoring events are programmed using the same facilities (see Figure 18-12) usedfor architectural performance events.Non-architectural performance events use event select values that are modelspecific.
Event mask (Umask) values are also specific to event logic units. Somemicroarchitectural conditions detectable by a Umask value may have specificityrelated to processor topology (see Section 7.7, “Detecting Hardware Multi-ThreadingSupport and Topology,” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A). As a result, the unit mask field (for example,IA32_PERFEVTSELx[bits 15:8]) may contain sub-fields that specify topology information of processor cores.The sub-field layout within the Umask field may support two-bit encoding that qualifies the relationship between a microarchitectural condition and the originating core.This data is shown in Table 18-7.
The two-bit encoding for core-specificity is onlysupported for a subset of Umask values (see Appendix A, “Performance MonitoringEvents”) and for Intel Core Duo processors. Such events are referred to as corespecific events.Table 18-7. Core Specificity Encoding within a Non-Architectural UmaskIA32_PERFEVTSELx MSRsBit 15:14 EncodingDescription11BAll cores10BReserved01BThis core00BReservedSome microarchitectural conditions allow detection specificity only at the boundaryof physical processors.
Some bus events belong to this category, providing specificitybetween the originating physical processor (a bus agent) versus other agents on thebus. Sub-field encoding for agent specificity is shown in Table 18-8.Table 18-8. Agent Specificity Encoding within a Non-Architectural UmaskIA32_PERFEVTSELx MSRsBit 13 EncodingDescription0This agent1Include all agents18-50 Vol. 3DEBUGGING AND PERFORMANCE MONITORINGSome microarchitectural conditions are detectable only from the originating core. Insuch cases, unit mask does not support core-specificity or agent-specificity encodings. These are referred to as core-only conditions.Some microarchitectural conditions allow detection specificity that includes orexcludes the action of hardware prefetches.
A two-bit encoding may be supported toqualify hardware prefetch actions. Typically, this applies only to some L2 or busevents. The sub-field encoding for hardware prefetch qualification is shown inTable 18-9.Table 18-9. HW Prefetch Qualification Encoding within a Non-Architectural UmaskIA32_PERFEVTSELx MSRsBit 13:12 EncodingDescription11BAll inclusive10BReserved01BHardware prefetch only00BExclude hardware prefetchSome performance events may (a) support none of the three event-specific qualification encodings (b) may support core-specificity and agent specificity simultaneously(c) or may support core-specificity and hardware prefetch qualification simultaneously.
Agent-specificity and hardware prefetch qualification are mutually exclusive.In addition, some L2 events permit qualifications that distinguish cache coherentstates. The sub-field definition for cache coherency state qualification is shown inTable 18-10. If no bits in the MESI qualification sub-field are set for an event thatrequires setting MESI qualification bits, the event count will not increment.Table 18-10. MESI Qualification Definitions within a Non-Architectural UmaskIA32_PERFEVTSELx MSRsBit Position 11:8DescriptionBit 11Counts modified stateBit 10Counts exclusive stateBit 9Counts shared stateBit 8Counts Invalid stateVol. 3 18-51DEBUGGING AND PERFORMANCE MONITORING18.14PERFORMANCE MONITORING (PROCESSORS BASEDON INTEL® CORE™ MICROARCHITECTURE)In addition to architectural performance monitoring, processors based on the IntelCore microarchitecture support non-architectural performance monitoring events.Architectural performance events can be collected using general-purpose performance counters.
Non-architectural performance events can be collected usinggeneral-purpose performance counters (coupled with two IA32_PERFEVTSELx MSRsfor detailed event configurations), or fixed-function performance counters (seeSection 18.14.1). IA32_PERFEVTSELx MSRs are architectural; their layout is shownin Figure 18-12. Starting with Intel Core 2 processor T 7700, fixed-function performance counters and associated counter control and status MSR becomes part ofarchitectural performance monitoring version 2 facilities (see also Section 18.12.2).Non-architectural performance events in processors based on Intel Core microarchitecture use event select values that are model-specific. Valid event mask (Umask)bits are listed in Appendix A. The UMASK field may contain sub-fields identical tothose listed in Table 18-7, Table 18-8, Table 18-9, and Table 18-10.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
