PMC.WESTMERE(3)

๐Ÿ“ฆ
version 15.1 ยท 2 versions
, in freebsd 15.1

๐Ÿ’… PMC.WESTMERE(3) โ€” Intel Westmere family CPUs, performance measurement events

okay so bestie. This is pmc.westmere, ok? It lives in the Library Functions Manual and it's the whole saga of measurement events for Intel Westmere family CPUs. Grab a snack, this one's long ๐ŸŒธ


๐Ÿซถ LIBRARY

Performance Counters Library (libpmc, -lpmc)

โœจ SYNOPSIS

#include <pmc.h>

๐Ÿฆ‹ DESCRIPTION

So like. Intel Westmere CPUs contain PMCs that conform to version 2 of the Intel performance measurement architecture. These CPUs may contain up to three classes of PMCs:

  • PMC_CLASS_IAF โ€” fixed-function counters that count only one hardware event per counter.
  • PMC_CLASS_IAP โ€” programmable counters that may be configured to count one of a defined set of hardware events.

The number of PMCs available in each class, and their widths, need to be determined at run time by calling pmc_cpuinfo(3) โœจ

Intel Westmere PMCs are documented in โ€œVolume 3B: System Programming Guide, Part 2โ€, Intel(R) 64 and IA-32 Architectures Software Developes Manual, Order Number: 253669-033US, Intel Corporation, December 2009.


๐ŸŽ€ WESTMERE FIXED FUNCTION PMCS

These PMCs and their supported events are documented in pmc.iaf(3).

๐Ÿ‘‘ WESTMERE PROGRAMMABLE PMCS

The programmable PMCs support the following capabilities:

  • PMC_CAP_CASCADE โ€” No
  • PMC_CAP_EDGE โ€” Yes
  • PMC_CAP_INTERRUPT โ€” Yes
  • PMC_CAP_INVERT โ€” Yes
  • PMC_CAP_READ โ€” Yes
  • PMC_CAP_PRECISE โ€” No
  • PMC_CAP_SYSTEM โ€” Yes
  • PMC_CAP_TAGGING โ€” No
  • PMC_CAP_THRESHOLD โ€” Yes
  • PMC_CAP_USER โ€” Yes
  • PMC_CAP_WRITE โ€” Yes

๐ŸŒˆ Event Qualifiers

Event specifiers for these PMCs support the following common qualifiers:

  • rsp=value โ€” configure the Off-core Response bits. The values you can feed it are:
    • DMND_DATA_RD โ€” counts the number of demand and DCU prefetch data reads of full and partial cachelines, as well as demand data page table entry cacheline reads. Does not count L2 data read prefetches or instruction fetches.
    • DMND_RFO โ€” counts the number of demand and DCU prefetch reads for ownership (RFO) requests generated by a write to data cacheline. Does not count L2 RFO.
    • DMND_IFETCH โ€” counts the number of demand and DCU prefetch instruction cacheline reads. Does not count L2 code read prefetches. WB counts the number of writeback (modified to exclusive) transactions.
    • PF_DATA_RD โ€” counts the number of data cacheline reads generated by L2 prefetchers.
    • PF_RFO โ€” counts the number of RFO requests generated by L2 prefetchers.
    • PF_IFETCH โ€” counts the number of code reads generated by L2 prefetchers.
    • OTHER โ€” counts one of the following transaction types, including L3 invalidate, I/O, full or partial writes, WC or non-temporal stores, CLFLUSH, Fences, lock, unlock, split lock.
    • UNCORE_HIT โ€” L3 Hit: local or remote home requests that hit L3 cache in the uncore with no coherency actions required (snooping).
    • OTHER_CORE_HIT_SNP โ€” L3 Hit: local or remote home requests that hit L3 cache in the uncore and was serviced by another core with a cross core snoop where no modified copies were found (clean).
    • OTHER_CORE_HITM โ€” L3 Hit: local or remote home requests that hit L3 cache in the uncore and was serviced by another core with a cross core snoop where modified copies were found (HITM).
    • REMOTE_CACHE_FWD โ€” L3 Miss: local homed requests that missed the L3 cache and was serviced by forwarded data following a cross package snoop where no modified copies found. (Remote home requests are not counted)
    • REMOTE_DRAM โ€” L3 Miss: remote home requests that missed the L3 cache and were serviced by remote DRAM.
    • LOCAL_DRAM โ€” L3 Miss: local home requests that missed the L3 cache and were serviced by local DRAM.
    • NON_DRAM โ€” Non-DRAM requests that were serviced by IOH.
  • cmask=value โ€” configure the PMC to increment only if the number of configured events measured in a cycle is greater than or equal to value.
  • edge โ€” configure the PMC to count the number of de-asserted to asserted transitions of the conditions expressed by the other qualifiers. If specified, the counter will increment only once whenever a condition becomes true, irrespective of the number of clocks during which the condition remains true. ๐Ÿฆ‹
  • inv โ€” invert the sense of comparison when the โ€œcmaskโ€ qualifier is present, making the counter increment when the number of events per cycle is less than the value specified by the โ€œcmaskโ€ qualifier.
  • os โ€” configure the PMC to count events happening at processor privilege level 0.
  • usr โ€” configure the PMC to count events occurring at privilege levels 1, 2 or 3.
If neither of the โ€œosโ€ or โ€œusrโ€ qualifiers are specified, the default is to enable both. ๐Ÿ’–

๐ŸŒธ Event Specifiers (Programmable PMCs)

Westmere programmable PMCs support the following events:

  • LOAD_BLOCK.OVERLAP_STORE โ€” (Event 03H, Umask 02H) Loads that partially overlap an earlier store
  • SB_DRAIN.ANY โ€” (Event 04H, Umask 07H) All Store buffer stall cycles
  • MISALIGN_MEMORY.STORE โ€” (Event 05H, Umask 02H) All store referenced with misaligned address
  • STORE_BLOCKS.AT_RET โ€” (Event 06H, Umask 04H) Counts number of loads delayed with at-Retirement block code. The following loads need to be executed at retirement and wait for all senior stores on the same thread to be drained: load splitting across 4K boundary (page split), load accessing uncacheable (UC or USWC) memory, load lock, and load with page table in UC or USWC memory region.
  • STORE_BLOCKS.L1D_BLOCK โ€” (Event 06H, Umask 08H) Cacheable loads delayed with L1D block code
  • PARTIAL_ADDRESS_ALIAS โ€” (Event 07H, Umask 01H) Counts false dependency due to partial address aliasing
  • DTLB_LOAD_MISSES.ANY โ€” (Event 08H, Umask 01H) Counts all load misses that cause a page walk
  • DTLB_LOAD_MISSES.WALK_COMPLETED โ€” (Event 08H, Umask 02H) Counts number of completed page walks due to load miss in the STLB.
  • DTLB_LOAD_MISSES.WALK_CYCLES โ€” (Event 08H, Umask 04H) Cycles PMH is busy with a page walk due to a load miss in the STLB.
  • DTLB_LOAD_MISSES.STLB_HIT โ€” (Event 08H, Umask 10H) Number of cache load STLB hits
  • DTLB_LOAD_MISSES.PDE_MISS โ€” (Event 08H, Umask 20H) Number of DTLB cache load misses where the low part of the linear to physical address translation was missed.
  • MEM_INST_RETIRED.LOADS โ€” (Event 0BH, Umask 01H) Counts the number of instructions with an architecturally-visible store retired on the architected path. In conjunction with ld_lat facility
  • MEM_INST_RETIRED.STORES โ€” (Event 0BH, Umask 02H) Counts the number of instructions with an architecturally-visible store retired on the architected path. In conjunction with ld_lat facility
  • MEM_INST_RETIRED.LATENCY_ABOVE_THRESHOLD โ€” (Event 0BH, Umask 10H) Counts the number of instructions exceeding the latency specified with ld_lat facility. In conjunction with ld_lat facility
  • MEM_STORE_RETIRED.DTLB_MISS โ€” (Event 0CH, Umask 01H) The event counts the number of retired stores that missed the DTLB. The DTLB miss is not counted if the store operation causes a fault. Does not counter prefetches. Counts both primary and secondary misses to the TLB
  • UOPS_ISSUED.ANY โ€” (Event 0EH, Umask 01H) Counts the number of Uops issued by the Register Allocation Table to the Reservation Station, i.e. the UOPs issued from the front end to the back end.
  • UOPS_ISSUED.STALLED_CYCLES โ€” (Event 0EH, Umask 01H) Counts the number of cycles no Uops issued by the Register Allocation Table to the Reservation Station, i.e. the UOPs issued from the front end to the back end. set invert=1, cmask = 1
  • UOPS_ISSUED.FUSED โ€” (Event 0EH, Umask 02H) Counts the number of fused Uops that were issued from the Register Allocation Table to the Reservation Station.
  • MEM_UNCORE_RETIRED.LOCAL_HITM โ€” (Event 0FH, Umask 02H) Load instructions retired that HIT modified data in sibling core (Precise Event)
  • MEM_UNCORE_RETIRED.LOCAL_DRAM_AND_REMOTE_CACHE_HIT โ€” (Event 0FH, Umask 08H) Load instructions retired local dram and remote cache HIT data sources (Precise Event)
  • MEM_UNCORE_RETIRED.LOCAL_DRAM โ€” (Event 0FH, Umask 10H) Load instructions retired with a data source of local DRAM or locally homed remote cache HITM (Precise Event)
  • MEM_UNCORE_RETIRED.REMOTE_DRAM โ€” (Event 0FH, Umask 20H) Load instructions retired remote DRAM and remote home-remote cache HITM (Precise Event)
  • MEM_UNCORE_RETIRED.UNCACHEABLE โ€” (Event 0FH, Umask 80H) Load instructions retired I/O (Precise Event)
  • FP_COMP_OPS_EXE.X87 โ€” (Event 10H, Umask 01H) Counts the number of FP Computational Uops Executed. The number of FADD, FSUB, FCOM, FMULs, integer MULsand IMULs, FDIVs, FPREMs, FSQRTS, integer DIVs, and IDIVs. This event does not distinguish an FADD used in the middle of a transcendental flow from a separate FADD instruction.
  • FP_COMP_OPS_EXE.MMX โ€” (Event 10H, Umask 02H) Counts number of MMX Uops executed.
  • FP_COMP_OPS_EXE.SSE_FP โ€” (Event 10H, Umask 04H) Counts number of SSE and SSE2 FP uops executed.
  • FP_COMP_OPS_EXE.SSE2_INTEGER โ€” (Event 10H, Umask 08H) Counts number of SSE2 integer uops executed.
  • FP_COMP_OPS_EXE.SSE_FP_PACKED โ€” (Event 10H, Umask 10H) Counts number of SSE FP packed uops executed.
  • FP_COMP_OPS_EXE.SSE_FP_SCALAR โ€” (Event 10H, Umask 20H) Counts number of SSE FP scalar uops executed.
  • FP_COMP_OPS_EXE.SSE_SINGLE_PRECISION โ€” (Event 10H, Umask 40H) Counts number of SSE* FP single precision uops executed.
  • FP_COMP_OPS_EXE.SSE_DOUBLE_PRECISION (Event 10H, Umask 80H) โ€” counts how many SSE* FP double precision uops actually got executed ๐Ÿ’…
  • SIMD_INT_128.PACKED_MPY (Event 12H, Umask 01H) โ€” counts 128 bit SIMD integer multiply operations โœจ
  • SIMD_INT_128.PACKED_SHIFT (Event 12H, Umask 02H) โ€” counts 128 bit SIMD integer shift operations ๐ŸŒ€
  • SIMD_INT_128.PACK (Event 12H, Umask 04H) โ€” counts 128 bit SIMD integer pack operations ๐ŸŽ€
  • SIMD_INT_128.UNPACK (Event 12H, Umask 08H) โ€” counts 128 bit SIMD integer unpack operations ๐Ÿฆ‹
  • SIMD_INT_128.PACKED_LOGICAL (Event 12H, Umask 10H) โ€” counts 128 bit SIMD integer logical operations ๐ŸŒธ
  • SIMD_INT_128.PACKED_ARITH (Event 12H, Umask 20H) โ€” counts 128 bit SIMD integer arithmetic operations ๐Ÿ”ฅ
  • SIMD_INT_128.SHUFFLE_MOVE (Event 12H, Umask 40H) โ€” counts 128 bit SIMD integer shuffle and move operations ๐Ÿ‘‘
  • LOAD_DISPATCH.RS (Event 13H, Umask 01H) โ€” counts the loads that got dispatched from the Reservation Station and straight up bypassed the Memory Order Buffer ๐Ÿ˜ค
  • LOAD_DISPATCH.RS_DELAYED (Event 13H, Umask 02H) โ€” counts the delayed RS dispatches at the stage latch. So basically: if an RS dispatch can't bypass to LB, it gets one more shot from the one-cycle delayed staging latch before it's written into the LB ๐Ÿซถ
  • LOAD_DISPATCH.MOB (Event 13H, Umask 04H) โ€” counts loads dispatched from the Reservation Station to the Memory Order Buffer ๐Ÿ’–
  • LOAD_DISPATCH.ANY (Event 13H, Umask 07H) โ€” counts all the loads dispatched from the Reservation Station, no crumbs left behind โญ
  • ARITH.CYCLES_DIV_BUSY (Event 14H, Umask 01H) โ€” counts the cycles the divider is busy doing divide or square root stuff. The divide can be integer, X87 or Streaming SIMD Extensions (SSE); the square root can be X87 or SSE. Set 'edge =1, invert=1, cmask=1' if what you actually want is the number of divides. Heads up though: the count may be incorrect when SMT is on ๐Ÿ’€
  • ARITH.MUL (Event 14H, Umask 02H) โ€” counts multiply operations executed โ€” integer and floating point โ€” but excludes DPPS mul and MPSAD. And yeah, count may be incorrect when SMT is on ๐Ÿ™ˆ
  • INST_QUEUE_WRITES (Event 17H, Umask 01H) โ€” counts the instructions written into the instruction queue every cycle ๐Ÿ“ฅ
  • INST_DECODED.DEC0 (Event 18H, Umask 01H) โ€” counts instructions that require decoder 0 to decode them. Usually that means the instruction maps to more than 1 uop ๐Ÿ‘€
  • TWO_UOP_INSTS_DECODED (Event 19H, Umask 01H) โ€” an instruction that generates two uops got decoded, and we're counting it โœŒ๏ธ
  • INST_QUEUE_WRITE_CYCLES (Event 1EH, Umask 01H) โ€” counts the cycles where instructions are being written to the instruction queue. Divide this counter by INST_QUEUE_WRITES and boom, you've got the average number of instructions decoded per cycle ๐Ÿงฎ

If that number comes out less than four and the pipe stalls? That's your sign the decoder isn't decoding enough per cycle to feed the 4-wide pipeline ๐Ÿ˜ฌ And if SSE* instructions that are 6 bytes or longer keep arriving one after another, front end throughput might be capping your execution speed. In such case,

ngl bestie the original page just cuts off right there mid-sentence ๐Ÿ’€ "In such case," and thenโ€ฆ nothing. iconic of it honestly.
  • LSD_OVERFLOW (Event 20H, Umask 01H) โ€” the number of loops that can't stream from the instruction queue ๐Ÿ˜ญ
  • L2_RQSTS.LD_HIT (Event 24H, Umask 01H) โ€” counts loads that hit the L2 cache. L2 loads include both L1D demand misses and L1D prefetches. L2 loads can get rejected for a bunch of reasons, and only the non-rejected ones get counted ๐Ÿ’…
  • L2_RQSTS.LD_MISS (Event 24H, Umask 02H) โ€” counts loads that miss the L2 cache. Again: L2 loads = L1D demand misses + L1D prefetches ๐ŸŒธ
  • L2_RQSTS.LOADS (Event 24H, Umask 03H) โ€” counts all L2 load requests โ€” L1D demand misses plus L1D prefetches, the whole guest list ๐ŸŽ€
  • L2_RQSTS.RFO_HIT (Event 24H, Umask 04H) โ€” counts store RFO requests that hit the L2 cache. L2 RFO requests include both L1D demand RFO misses and L1D RFO prefetches. The count also includes WC memory requests, where the data isn't fetched but you still need permission to write the line ๐Ÿ‘‘
  • L2_RQSTS.RFO_MISS (Event 24H, Umask 08H) โ€” counts store RFO requests that miss the L2 cache. L2 RFO requests = L1D demand RFO misses + L1D RFO prefetches ๐Ÿฆ‹
  • L2_RQSTS.RFOS (Event 24H, Umask 0CH) โ€” counts all L2 store RFO requests, same composition as above (L1D demand RFO misses + L1D RFO prefetches) โœจ
  • L2_RQSTS.IFETCH_HIT (Event 24H, Umask 10H) โ€” counts instruction fetches that hit the L2 cache. L2 instruction fetches include both L1I demand misses and L1I instruction prefetches ๐Ÿ“š
  • L2_RQSTS.IFETCH_MISS (Event 24H, Umask 20H) โ€” counts instruction fetches that miss the L2 cache โ€” L1I demand misses + L1I instruction prefetches ๐Ÿ˜ค
  • L2_RQSTS.IFETCHES (Event 24H, Umask 30H) โ€” counts all instruction fetches (L1I demand misses + L1I instruction prefetches, fr fr) ๐Ÿ”ฅ
  • L2_RQSTS.PREFETCH_HIT (Event 24H, Umask 40H) โ€” counts L2 prefetch hits, for both code and data ๐ŸŽ€
  • L2_RQSTS.PREFETCH_MISS (Event 24H, Umask 80H) โ€” counts L2 prefetch misses, again both code and data ๐Ÿ˜ญ
  • L2_RQSTS.PREFETCHES (Event 24H, Umask C0H) โ€” counts all L2 prefetches, code and data together, the full set ๐ŸŒˆ
  • L2_RQSTS.MISS (Event 24H, Umask AAH) โ€” counts all L2 misses, code and data ๐Ÿ’€
  • L2_RQSTS.REFERENCES (Event 24H, Umask FFH) โ€” counts all L2 requests, code and data, every last one ๐Ÿ‘‘
  • L2_DATA_RQSTS.DEMAND.I_STATE (Event 26H, Umask 01H) โ€” counts L2 data demand loads where the cache line being loaded is in the I (invalid) state, i.e. a cache miss ๐Ÿ™ˆ L2 demand loads = both L1D demand misses and L1D prefetches.
  • L2_DATA_RQSTS.DEMAND.S_STATE (Event 26H, Umask 02H) โ€” counts L2 data demand loads where the line is in the S (shared) state. L2 demand loads are both L1D demand misses and L1D prefetches ๐Ÿซถ
  • L2_DATA_RQSTS.DEMAND.E_STATE (Event 26H, Umask 04H) โ€” counts L2 data demand loads where the line is in the E (exclusive) state. Same definition of L2 demand loads as always ๐Ÿ’…
  • L2_DATA_RQSTS.DEMAND.M_STATE (Event 26H, Umask 08H) โ€” counts L2 data demand loads where the line is in the M (modified) state. L2 demand loads = L1D demand misses + L1D prefetches ๐ŸŒธ
  • L2_DATA_RQSTS.DEMAND.MESI (Event 26H, Umask 0FH) โ€” counts all L2 data demand requests, which are both L1D demand misses and L1D prefetches โœจ
  • L2_DATA_RQSTS.PREFETCH.I_STATE (Event 26H, Umask 10H) โ€” counts L2 prefetch data loads where the line is in the I (invalid) state, i.e. a cache miss ๐Ÿ’€
  • L2_DATA_RQSTS.PREFETCH.S_STATE (Event 26H, Umask 20H) โ€” counts L2 prefetch data loads where the line is in the S (shared) state. Fun fact: a prefetch RFO will miss on an S state line, while a prefetch read will hit on one ๐Ÿฆ‹
  • L2_DATA_RQSTS.PREFETCH.E_STATE (Event 26H, Umask 40H) โ€” counts L2 prefetch data loads where the line is in the E (exclusive) state ๐Ÿ”ฅ
  • L2_DATA_RQSTS.PREFETCH.M_STATE (Event 26H, Umask 80H) โ€” counts L2 prefetch data loads where the line is in the M (modified) state ๐Ÿ‘‘
  • L2_DATA_RQSTS.PREFETCH.MESI (Event 26H, Umask F0H) โ€” counts all L2 prefetch requests ๐ŸŽ€
  • L2_DATA_RQSTS.ANY (Event 26H, Umask FFH) โ€” counts all L2 data requests, periodt โญ
  • L2_WRITE.RFO.I_STATE (Event 27H, Umask 01H) โ€” counts L2 demand store RFO requests where the line being loaded is in the I (invalid) state, i.e. a cache miss. The L1D prefetcher does not issue an RFO prefetch โ€” this is a demand RFO request ๐Ÿ˜ค
  • L2_WRITE.RFO.S_STATE (Event 27H, Umask 02H) โ€” counts L2 store RFO requests where the line is in the S (shared) state. Again, no RFO prefetch from the L1D prefetcher; this is a demand RFO request ๐Ÿ’…
  • L2_WRITE.RFO.M_STATE (Event 27H, Umask 08H) โ€” counts L2 store RFO requests where the line is in the M (modified) state. Still no L1D RFO prefetch โ€” demand RFO request only ๐Ÿซถ
  • L2_WRITE.RFO.HIT (Event 27H, Umask 0EH) โ€” counts L2 store RFO requests where the line is in either the S, E or M states. L1D prefetcher doesn't issue an RFO prefetch; this is a demand RFO request ๐ŸŒธ
  • L2_WRITE.RFO.MESI (Event 27H, Umask 0FH) โ€” counts all L2 store RFO requests. The L1D prefetcher does not issue a RFO prefetch โ€” this is a demand RFO request โœจ
  • L2_WRITE.LOCK.I_STATE (Event 27H, Umask 10H) โ€” counts L2 demand lock RFO requests where the line is in the I (invalid) state, i.e. a cache miss ๐Ÿ’€
  • L2_WRITE.LOCK.S_STATE (Event 27H, Umask 20H) โ€” counts L2 lock RFO requests where the line is in the S (shared) state ๐Ÿฆ‹
  • L2_WRITE.LOCK.E_STATE (Event 27H, Umask 40H) โ€” counts L2 demand lock RFO requests where the line is in the E (exclusive) state ๐Ÿ”ฅ
  • L2_WRITE.LOCK.M_STATE (Event 27H, Umask 80H) โ€” counts L2 demand lock RFO requests where the line is in the M (modified) state ๐Ÿ‘‘
  • L2_WRITE.LOCK.HIT (Event 27H, Umask E0H) โ€” counts L2 demand lock RFO requests where the line is in either the S, E, or M state ๐ŸŽ€
  • L2_WRITE.LOCK.MESI โ€” (Event 27H, Umask F0H) counts, like, all the L2 demand lock RFO requests. Every single one. ๐Ÿ’…
  • L1D_WB_L2.I_STATE โ€” (Event 28H, Umask 01H) counts how many L1 writebacks to the L2 happen where the cache line being written is in the I (invalid) state โ€” i.e. a cache miss. It's giving "nothing was there bestie". ๐Ÿซฅ
  • L1D_WB_L2.S_STATE โ€” (Event 28H, Umask 02H) counts L1 writebacks to the L2 where the line being written is in the S state. โœจ
  • L1D_WB_L2.E_STATE โ€” (Event 28H, Umask 04H) counts L1 writebacks to the L2 where the line being written is in the E (exclusive) state. ๐Ÿ‘‘
  • L1D_WB_L2.M_STATE โ€” (Event 28H, Umask 08H) counts L1 writebacks to the L2 where the line being written is in the M (modified) state. ๐Ÿ”ฅ
  • L1D_WB_L2.MESI โ€” (Event 28H, Umask 0FH) counts all L1 writebacks to the L2. No filter, no drama, just vibes. ๐ŸŒˆ
  • L3_LAT_CACHE.REFERENCE โ€” (Event 2EH, Umask 02H) counts uncore Last Level Cache references. ๐Ÿงš Now listen โ€” because of cache hierarchy, cache sizes and other implementation-specific characteristics, comparing the value to estimate performance differences is not recommended. See Table A-1.
  • L3_LAT_CACHE.MISS โ€” (Event 2EH, Umask 01H) counts uncore Last Level Cache misses. ๐Ÿ˜ญ Same caveat bestie: because of cache hierarchy, cache sizes and other implementation-specific characteristics, comparing the value to estimate performance differences is not recommended. See Table A-1.
  • CPU_CLK_UNHALTED.THREAD_P โ€” (Event 3CH, Umask 00H) counts the number of thread cycles while the thread is not in a halt state. The thread enters the halt state when it's running the HLT instruction. Heads up: the core frequency may change from time to time due to power or thermal throttling. see Table A-1
  • CPU_CLK_UNHALTED.REF_P โ€” (Event 3CH, Umask 01H) increments at the frequency of TSC when not halted. see Table A-1
  • DTLB_MISSES.ANY โ€” (Event 49H, Umask 01H) counts the number of misses in the STLB which cause a page walk. ๐Ÿšถโ€โ™€๏ธ
  • DTLB_MISSES.WALK_COMPLETED โ€” (Event 49H, Umask 02H) counts the number of misses in the STLB which resulted in a completed page walk. ate and finished. โœ…
  • DTLB_MISSES.WALK_CYCLES โ€” (Event 49H, Umask 04H) counts cycles of page walk due to misses in the STLB. โณ
  • DTLB_MISSES.STLB_HIT โ€” (Event 49H, Umask 10H) counts the number of DTLB first level misses that hit in the second level TLB. ๐ŸŽฏ Real talk: this event is only relevant if the core contains multiple DTLB levels.
  • DTLB_MISSES.LARGE_WALK_COMPLETED โ€” (Event 49H, Umask 80H) counts the number of completed large page walks due to misses in the STLB. Big pages, big energy. ๐Ÿ’–
  • LOAD_HIT_PRE โ€” (Event 4CH, Umask 01H) counts load operations sent to the L1 data cache while a previous SSE prefetch instruction to the same cache line has started prefetching but has not yet finished. So close and yet so far. ๐Ÿ˜ฉ
  • L1D_PREFETCH.REQUESTS โ€” (Event 4EH, Umask 01H) counts the number of hardware prefetch requests dispatched out of the prefetch FIFO. ๐Ÿ“ฌ
  • L1D_PREFETCH.MISS โ€” (Event 4EH, Umask 02H) counts the number of hardware prefetch requests that miss the L1D. Okay so there are two prefetchers in the L1D: a streamer, which predicts lines sequentially after this one should be fetched, and the IP prefetcher that remembers access patterns for the current instruction. The streamer prefetcher stops on an L1D hit, while the IP prefetcher does not. Different strokes, honestly. ๐Ÿฆ‹
  • L1D_PREFETCH.TRIGGERS โ€” (Event 4EH, Umask 04H) counts the number of prefetch requests triggered by the Finite State Machine and pushed into the prefetch FIFO. Some of the prefetch requests get dropped due to overwrites or competition between the IP index prefetcher and streamer prefetcher. The prefetch FIFO contains 4 entries. ๐Ÿ’€ Four. That's it.
  • EPT.WALK_CYCLES โ€” (Event 4FH, Umask 10H) counts Extended Page walk cycles. ๐ŸŒ€
  • L1D.REPL โ€” (Event 51H, Umask 01H) counts the number of lines brought into the L1 data cache. Counter 0, 1 only.
  • L1D.M_REPL โ€” (Event 51H, Umask 02H) counts the number of modified lines brought into the L1 data cache. Counter 0, 1 only.
  • L1D.M_EVICT โ€” (Event 51H, Umask 04H) counts the number of modified lines evicted from the L1 data cache due to replacement. Counter 0, 1 only. bye bestie ๐Ÿ‘‹
  • L1D.M_SNOOP_EVICT โ€” (Event 51H, Umask 08H) counts the number of modified lines evicted from the L1 data cache due to snoop HITM intervention. Counter 0, 1 only
  • L1D_CACHE_PREFETCH_LOCK_FB_HIT โ€” (Event 52H, Umask 01H) counts the number of cacheable load lock speculated instructions accepted into the fill buffer. ๐ŸŽ€
  • L1D_CACHE_LOCK_FB_HIT โ€” (Event 53H, Umask 01H) counts the number of cacheable load lock speculated or retired instructions accepted into the fill buffer. ๐Ÿ‘‘
  • OFFCORE_REQUESTS_OUTSTANDING.DEMAND.READ_DATA โ€” (Event 60H, Umask 01H) counts weighted cycles of offcore demand data read requests. Does not include L2 prefetch requests. Counter 0.
  • OFFCORE_REQUESTS_OUTSTANDING.DEMAND.READ_CODE โ€” (Event 60H, Umask 02H) counts weighted cycles of offcore demand code read requests. Does not include L2 prefetch requests. Counter 0.
  • OFFCORE_REQUESTS_OUTSTANDING.DEMAND.RFO โ€” (Event 60H, Umask 04H) counts weighted cycles of offcore demand RFO requests. Does not include L2 prefetch requests. Counter 0.
  • OFFCORE_REQUESTS_OUTSTANDING.ANY.READ โ€” (Event 60H, Umask 08H) counts weighted cycles of offcore read requests of any kind. Include L2 prefetch requests. Counter 0.
  • CACHE_LOCK_CYCLES.L1D_L2 โ€” (Event 63H, Umask 01H) cycle count during which the L1D and L2 are locked. A lock is asserted when there is a locked memory access, due to uncacheable memory, a locked operation that spans two cache lines, or a page walk from an uncacheable page table. Counter 0, 1 only.
๐Ÿšจ Bestie, listen to me: L1D and L2 locks have a very high performance penalty and it is highly recommended to avoid such accesses. Like, do not do this. Periodt.
  • CACHE_LOCK_CYCLES.L1D โ€” (Event 63H, Umask 02H) counts the number of cycles that cacheline in the L1 data cache unit is locked. Counter 0, 1 only. ๐Ÿ”’
  • IO_TRANSACTIONS โ€” (Event 6CH, Umask 01H) counts the number of completed I/O transactions. โœ…
  • L1I.HITS โ€” (Event 80H, Umask 01H) counts all instruction fetches that hit the L1 instruction cache. slay. โœจ
  • L1I.MISSES โ€” (Event 80H, Umask 02H) counts all instruction fetches that miss the L1I cache. This includes instruction cache misses, streaming buffer misses, victim cache misses and uncacheable fetches. Important detail: an instruction fetch miss is counted only once and not once for every cycle it is outstanding. ๐Ÿ™ˆ
  • L1I.READS โ€” (Event 80H, Umask 03H) counts all instruction fetches, including uncacheable fetches that bypass the L1I. ๐ŸŒธ
  • L1I.CYCLES_STALLED โ€” (Event 80H, Umask 04H) cycle counts for which an instruction fetch stalls due to a L1I cache miss, ITLB miss or ITLB fault. stuck in traffic vibes. ๐Ÿ˜ญ
  • LARGE_ITLB.HIT โ€” (Event 82H, Umask 01H) counts number of large ITLB hits. ๐Ÿ‘‘
  • ITLB_MISSES.ANY โ€” (Event 85H, Umask 01H) counts the number of misses in all levels of the ITLB which causes a page walk. ๐Ÿšถ
  • ITLB_MISSES.WALK_COMPLETED โ€” (Event 85H, Umask 02H) counts number of misses in all levels of the ITLB which resulted in a completed page walk. ๐Ÿ
  • ITLB_MISSES.WALK_CYCLES โ€” (Event 85H, Umask 04H) counts ITLB miss page walk cycles. โฑ๏ธ
  • ITLB_MISSES.LARGE_WALK_COMPLETED โ€” (Event 85H, Umask 80H) counts number of completed large page walks due to misses in the STLB. ๐Ÿ’–
  • ILD_STALL.LCP โ€” (Event 87H, Umask 01H) cycles Instruction Length Decoder stalls due to length changing prefixes: 66, 67 or REX.W (for EM64T) instructions which change the length of the decoded instruction. ๐Ÿ˜ตโ€๐Ÿ’ซ
  • ILD_STALL.MRU โ€” (Event 87H, Umask 02H) Instruction Length Decoder stall cycles due to Brand Prediction Unit (PBU) Most Recently Used (MRU) bypass.
  • ILD_STALL.IQ_FULL โ€” (Event 87H, Umask 04H) stall cycles due to a full instruction queue. no room, no entry, we're full. ๐Ÿ’€
  • ILD_STALL.REGEN โ€” (Event 87H, Umask 08H) counts the number of regen stalls.
  • ILD_STALL.ANY โ€” (Event 87H, Umask 0FH) counts any cycles the Instruction Length Decoder is stalled. all of them. every last one. ๐ŸŒˆ
  • BR_INST_EXEC.COND โ€” (Event 88H, Umask 01H) counts the number of conditional near branch instructions executed, but not necessarily retired.
  • BR_INST_EXEC.DIRECT โ€” (Event 88H, Umask 02H) counts all unconditional near branch instructions excluding calls and indirect branches.
  • BR_INST_EXEC.INDIRECT_NON_CALL โ€” (Event 88H, Umask 04H) counts the number of executed indirect near branch instructions that are not calls.
  • BR_INST_EXEC.NON_CALLS โ€” (Event 88H, Umask 07H) counts all non-call near branch instructions executed, but not necessarily retired.
  • BR_INST_EXEC.RETURN_NEAR โ€” (Event 88H, Umask 08H) counts indirect near branches that have a return mnemonic. ๐Ÿ”™
  • BR_INST_EXEC.DIRECT_NEAR_CALL โ€” (Event 88H, Umask 10H) counts unconditional near call branch instructions, excluding non-call branch, executed.
  • BR_INST_EXEC.INDIRECT_NEAR_CALL โ€” (Event 88H, Umask 20H) counts indirect near calls, including both register and memory indirect, executed. ๐Ÿ“ž
  • BR_INST_EXEC.NEAR_CALLS โ€” (Event 88H, Umask 30H) counts all near call branches executed, but not necessarily retired.
  • BR_INST_EXEC.TAKEN โ€” (Event 88H, Umask 40H) counts taken near branches executed, but not necessarily retired. ๐ŸŽฏ
  • BR_INST_EXEC.ANY โ€” (Event 88H, Umask 7FH) counts all near executed branches (not necessarily retired). This includes only instructions and not micro-op branches.
๐Ÿซถ Note from the manpage, not me: frequent branching is not necessarily a major performance issue. However frequent branch mispredictions may be a problem.
  • BR_MISP_EXEC.COND โ€” (Event 89H, Umask 01H) counts the number of mispredicted conditional near branch instructions executed, but not necessarily retired. ๐Ÿ™ˆ
  • BR_MISP_EXEC.DIRECT โ€” (Event 89H, Umask 02H) counts mispredicted macro unconditional near branch instructions, excluding calls and indirect branches (should always be 0). yes bestie, always. if it's not, something is deeply wrong. ๐Ÿ˜ญ
  • BR_MISP_EXEC.INDIRECT_NON_CALL โ€” (Event 89H, Umask 04H) bestie this one counts the executed mispredicted indirect near branch instructions that are not calls ๐Ÿ’…
  • BR_MISP_EXEC.NON_CALLS โ€” (Event 89H, Umask 07H) counts mispredicted non-call near branches that got executed, but not necessarily retired (ngl "executed" โ‰  "retired" and the manpage is very serious about this distinction ๐Ÿ˜ญ)
  • BR_MISP_EXEC.RETURN_NEAR โ€” (Event 89H, Umask 08H) counts mispredicted indirect branches that have a rear return mnemonic ๐ŸŒ€
  • BR_MISP_EXEC.DIRECT_NEAR_CALL โ€” (Event 89H, Umask 10H) counts mispredicted non-indirect near calls executed โ€” and the manpage literally says it (should always be 0) ๐Ÿ’€ so if you're seeing anything here, that's a vibe check fail fr fr
  • BR_MISP_EXEC.INDIRECT_NEAR_CALL โ€” (Event 89H, Umask 20H) counts mispredicted indirect near calls executed, and it's inclusive like that โ€” both register and memory indirect ๐Ÿซถ
  • BR_MISP_EXEC.NEAR_CALLS โ€” (Event 89H, Umask 30H) counts all mispredicted near call branches executed, but not necessarily retired โœจ
  • BR_MISP_EXEC.TAKEN โ€” (Event 89H, Umask 40H) counts executed mispredicted near branches that are taken, but not necessarily retired ๐ŸŽ€
  • BR_MISP_EXEC.ANY โ€” (Event 89H, Umask 7FH) counts the number of mispredicted near branch instructions that were executed, but not necessarily retired. The whole category, the main character ๐Ÿ‘‘
  • RESOURCE_STALLS.ANY โ€” (Event A2H, Umask 01H) counts the number of Allocator resource related stalls. Includes register renaming buffer entries, memory buffer entries. In addition to resource related stalls, this event counts some other events. Includes stalls arising during branch misprediction recovery โ€” like if retirement of the mispredicted branch is delayed โ€” and stalls arising while store buffer is draining from synchronizing operations. It does not include stalls due to SuperQ (off core) queue full, too many cache misses, etc. ๐Ÿ™ˆ
  • RESOURCE_STALLS.LOAD โ€” (Event A2H, Umask 02H) counts the cycles of stall due to lack of load buffer for load operation ๐Ÿ˜ด
  • RESOURCE_STALLS.RS_FULL โ€” (Event A2H, Umask 04H) this event counts the number of cycles when the number of instructions in the pipeline waiting for execution reaches the limit the processor can handle. A high count of this event indicates that there are long latency operations in the pipe โ€” possibly load and store operations that miss the L2 cache, or instructions dependent upon instructions further down the pipeline that have yet to retire. When RS is full, new instructions can not enter the reservation station and start execution ๐Ÿšซ
  • RESOURCE_STALLS.STORE โ€” (Event A2H, Umask 08H) counts the number of cycles that a resource related stall will occur due to the number of store instructions reaching the limit of the pipeline, (i.e. all store buffers are used). The stall ends when a store instruction commits its data to the cache or memory ๐Ÿ“ฆ
  • RESOURCE_STALLS.ROB_FULL โ€” (Event A2H, Umask 10H) counts the cycles of stall due to re-order buffer full ๐Ÿงบ
  • RESOURCE_STALLS.FPCW โ€” (Event A2H, Umask 20H) counts the number of cycles while execution was stalled due to writing the floating-point unit (FPU) control word ๐ŸŒŠ
  • RESOURCE_STALLS.MXCSR โ€” (Event A2H, Umask 40H) stalls due to the MXCSR register rename occurring to close to a previous MXCSR rename. The MXCSR provides control and status for the MMX registers โš™๏ธ
  • RESOURCE_STALLS.OTHER โ€” (Event A2H, Umask 80H) counts the number of cycles while execution was stalled due to other resource issues. The catch-all, the "it's giving miscellaneous" bin ๐Ÿ’€
  • MACRO_INSTS.FUSIONS_DECODED โ€” (Event A6H, Umask 01H) counts the number of instructions decoded that are macro-fused but not necessarily executed or retired ๐Ÿงฌ (fused but not fulfilled, we've all been there)
  • BACLEAR_FORCE_IQ โ€” (Event A7H, Umask 01H) counts number of times a BACLEAR was forced by the Instruction Queue. The IQ is also responsible for providing conditional branch prediction direction based on a static scheme and dynamic data provided by the L2 Branch Prediction Unit. If the conditional branch target is not found in the Target Array and the IQ predicts that the branch is taken, then the IQ will force the Branch Address Calculator to issue a BACLEAR. Each BACLEAR asserted by the BAC generates approximately an 8 cycle bubble in the instruction fetch pipeline ๐Ÿซง โ€” eight whole cycles, no cap, that's a lot of bubble
  • LSD.UOPS โ€” (Event A8H, Umask 01H) counts the number of micro-ops delivered by loop stream detector. Use cmask=1 and invert to count cycles ๐Ÿ”
  • ITLB_FLUSH โ€” (Event AEH, Umask 01H) counts the number of ITLB flushes ๐Ÿšฝ (okay it's a translation lookaside buffer flush but the joke writes itself)
  • OFFCORE_REQUESTS.DEMAND.READ_DATA โ€” (Event B0H, Umask 01H) counts number of offcore demand data read requests. Does not count L2 prefetch requests ๐Ÿ™…
  • OFFCORE_REQUESTS.DEMAND.READ_CODE โ€” (Event B0H, Umask 02H) counts number of offcore demand code read requests. Does not count L2 prefetch requests ๐Ÿ™…
  • OFFCORE_REQUESTS.DEMAND.RFO โ€” (Event B0H, Umask 04H) counts number of offcore demand RFO requests. Does not count L2 prefetch requests ๐Ÿ™…
  • OFFCORE_REQUESTS.ANY.READ โ€” (Event B0H, Umask 08H) counts number of offcore read requests. Includes L2 prefetch requests this time bestie, plot twist โœจ
  • OFFCORE_REQUESTS.ANY.RFO โ€” (Event 80H, Umask 10H) counts number of offcore RFO requests. Includes L2 prefetch requests. (yes the event is 80H here, not B0H โ€” write it exactly like that, don't come for me ๐Ÿ’€)
  • OFFCORE_REQUESTS.L1D_WRITEBACK โ€” (Event B0H, Umask 40H) counts number of L1D writebacks to the uncore ๐ŸŒˆ
  • OFFCORE_REQUESTS.ANY โ€” (Event B0H, Umask 80H) counts all offcore requests. Every single one. The whole squad ๐Ÿ‘ฏ
  • UOPS_EXECUTED.PORT0 โ€” (Event B1H, Umask 01H) counts number of Uops executed that were issued on port 0. Port 0 handles integer arithmetic, SIMD and FP add Uops ๐Ÿ’ช
  • UOPS_EXECUTED.PORT1 โ€” (Event B1H, Umask 02H) counts number of Uops executed that were issued on port 1. Port 1 handles integer arithmetic, SIMD, integer shift, FP multiply and FP divide Uops ๐Ÿ”ข
  • UOPS_EXECUTED.PORT2_CORE โ€” (Event B1H, Umask 04H) counts number of Uops executed that were issued on port 2. Port 2 handles the load Uops. This is a core count only and can not be collected per thread โš ๏ธ
  • UOPS_EXECUTED.PORT3_CORE โ€” (Event B1H, Umask 08H) counts number of Uops executed that were issued on port 3. Port 3 handles store Uops. This is a core count only and can not be collected per thread โš ๏ธ
  • UOPS_EXECUTED.PORT4_CORE โ€” (Event B1H, Umask 10H) counts number of Uops executed that where issued on port 4. Port 4 handles the value to be stored for the store Uops issued on port 3. This is a core count only and can not be collected per thread โš ๏ธ
  • UOPS_EXECUTED.CORE_ACTIVE_CYCLES_NO_PORT5 โ€” (Event B1H, Umask 1FH) counts number of cycles there are one or more uops being executed and were issued on ports 0-4. This is a core count only and can not be collected per thread โš ๏ธ
  • UOPS_EXECUTED.PORT5 โ€” (Event B1H, Umask 20H) counts number of Uops executed that where issued on port 5 ๐Ÿ–๏ธ (the forbidden port, the one the previous event excluded)
  • UOPS_EXECUTED.CORE_ACTIVE_CYCLES โ€” (Event B1H, Umask 3FH) counts number of cycles there are one or more uops being executed on any ports. This is a core count only and can not be collected per thread โš ๏ธ
  • UOPS_EXECUTED.PORT015 โ€” (Event B1H, Umask 40H) counts number of Uops executed that where issued on port 0, 1, or 5. Use cmask=1, invert=1 to count stall cycles ๐ŸŒ€
  • UOPS_EXECUTED.PORT234 โ€” (Event B1H, Umask 80H) counts number of Uops executed that where issued on port 2, 3, or 4 โœจ
  • OFFCORE_REQUESTS_SQ_FULL โ€” (Event B2H, Umask 01H) counts number of cycles the SQ is full to handle off-core requests ๐Ÿ˜ค
  • SNOOPQ_REQUESTS_OUTSTANDING.DATA โ€” (Event B3H, Umask 01H) counts weighted cycles of snoopq requests for data. Counter 0 only. Use cmask=1 to count cycles not empty ๐Ÿ‘€
  • SNOOPQ_REQUESTS_OUTSTANDING.INVALIDATE โ€” (Event B3H, Umask 02H) counts weighted cycles of snoopq invalidate requests. Counter 0 only. Use cmask=1 to count cycles not empty ๐Ÿ‘€
  • SNOOPQ_REQUESTS_OUTSTANDING.CODE โ€” (Event B3H, Umask 04H) counts weighted cycles of snoopq requests for code. Counter 0 only. Use cmask=1 to count cycles not empty ๐Ÿ‘€
  • SNOOPQ_REQUESTS.CODE โ€” (Event B4H, Umask 01H) counts the number of snoop code requests ๐Ÿ“จ
  • SNOOPQ_REQUESTS.DATA โ€” (Event B4H, Umask 02H) counts the number of snoop data requests ๐Ÿ“จ
  • SNOOPQ_REQUESTS.INVALIDATE โ€” (Event B4H, Umask 04H) counts the number of snoop invalidate requests ๐Ÿ“จ
  • OFF_CORE_RESPONSE_0 โ€” (Event B7H, Umask 01H) see Section 30.6.1.3, Off-core Response Performance Monitoring in the Processor Core. Requires programming MSR 01A6H ๐Ÿ”ง
  • SNOOP_RESPONSE.HIT โ€” (Event B8H, Umask 01H) counts HIT snoop response sent by this thread in response to a snoop request โœ…
  • SNOOP_RESPONSE.HITE โ€” (Event B8H, Umask 02H) counts HIT E snoop response sent by this thread in response to a snoop request โœ…
  • SNOOP_RESPONSE.HITM โ€” (Event B8H, Umask 04H) counts HIT M snoop response sent by this thread in response to a snoop request โœ…
  • OFF_CORE_RESPONSE_1 โ€” (Event BBH, Umask 01H) see Section 30.6.1.3, Off-core Response Performance Monitoring in the Processor Core. Use MSR 01A7H ๐Ÿ”ง
  • INST_RETIRED.ANY_P โ€” (Event C0H, Umask 01H) See Table A-1 Notes: INST_RETIRED.ANY is counted by a designated fixed counter. INST_RETIRED.ANY_P is counted by a programmable counter and is an architectural performance event. Event is supported if CPUID.A.EBX[1] = 0. Counting: Faulting executions of GETSEC/VM entry/VM Exit/MWait will not count as retired instructions โš ๏ธ
  • INST_RETIRED.X87 โ€” (Event C0H, Umask 02H) counts the number of floating point computational operations retired โ€” floating point computational operations executed by the assist handler and sub-operations of complex floating point instructions like transcendental instructions ๐Ÿงฎ
  • INST_RETIRED.MMX โ€” (Event C0H, Umask 04H) counts the number of retired: MMX instructions ๐ŸŽฎ
  • UOPS_RETIRED.ANY โ€” (Event C2H, Umask 01H) counts the micro-ops that actually retired, bestie. The math: macro-fused = 1, micro-fused = 2, everything else = 1, and the max count is 8 per cycle. Most instructions are made of one or two micro-ops. Some get decoded into way longer sequences โ€” think repeat instructions, floating point transcendental instructions, and assists. Pro tip from the source: use cmask=1 and invert to count active cycles or stalled cycles. ๐Ÿ’…
  • UOPS_RETIRED.RETIRE_SLOTS โ€” (Event C2H, Umask 02H) counts the number of retirement slots used each cycle.
  • UOPS_RETIRED.MACRO_FUSED โ€” (Event C2H, Umask 04H) counts the number of macro-fused uops retired.
  • MACHINE_CLEARS.CYCLES โ€” (Event C3H, Umask 01H) counts the cycles machine clear is asserted.
  • MACHINE_CLEARS.MEM_ORDER โ€” (Event C3H, Umask 02H) counts machine clears due to memory order conflicts. ๐Ÿ˜ญ
  • MACHINE_CLEARS.SMC โ€” (Event C3H, Umask 04H) counts the number of times a program writes to a code section. Self-modifying code causes a severe penalty in all Intel 64 and IA-32 processors โ€” and the modified cache line gets written back to the L2 and L3 caches. Not the vibe, honestly. ๐Ÿ’€
  • BR_INST_RETIRED.ANY_P โ€” (Event C4H, Umask 00H) See Table A-1.
  • BR_INST_RETIRED.CONDITIONAL โ€” (Event C4H, Umask 01H) counts the number of conditional branch instructions retired.
  • BR_INST_RETIRED.NEAR_CALL โ€” (Event C4H, Umask 02H) counts the number of direct &amp; indirect near unconditional calls retired.
  • BR_INST_RETIRED.ALL_BRANCHES โ€” (Event C4H, Umask 04H) counts the number of branch instructions retired.
  • BR_MISP_RETIRED.ANY_P โ€” (Event C5H, Umask 00H) See Table A-1.
  • BR_MISP_RETIRED.CONDITIONAL โ€” (Event C5H, Umask 01H) counts mispredicted conditional retired calls.
  • BR_MISP_RETIRED.NEAR_CALL โ€” (Event C5H, Umask 02H) counts mispredicted direct &amp; indirect near unconditional retired calls.
  • BR_MISP_RETIRED.ALL_BRANCHES โ€” (Event C5H, Umask 04H) counts all mispredicted retired calls.
  • SSEX_UOPS_RETIRED.PACKED_SINGLE โ€” (Event C7H, Umask 01H) counts SIMD packed single-precision floating point Uops retired. โœจ
  • SSEX_UOPS_RETIRED.SCALAR_SINGLE โ€” (Event C7H, Umask 02H) counts SIMD scalar single-precision floating point Uops retired.
  • SSEX_UOPS_RETIRED.PACKED_DOUBLE โ€” (Event C7H, Umask 04H) counts SIMD packed double-precision floating point Uops retired.
  • SSEX_UOPS_RETIRED.SCALAR_DOUBLE โ€” (Event C7H, Umask 08H) counts SIMD scalar double-precision floating point Uops retired.
  • SSEX_UOPS_RETIRED.VECTOR_INTEGER โ€” (Event C7H, Umask 10H) counts 128-bit SIMD vector integer Uops retired.
  • ITLB_MISS_RETIRED โ€” (Event C8H, Umask 20H) counts the number of retired instructions that missed the ITLB when the instruction was fetched. ๐Ÿฆ‹
  • MEM_LOAD_RETIRED.L1D_HIT โ€” (Event CBH, Umask 01H) counts the number of retired loads that hit the L1 data cache.
  • MEM_LOAD_RETIRED.L2_HIT โ€” (Event CBH, Umask 02H) counts the number of retired loads that hit the L2 data cache.
  • MEM_LOAD_RETIRED.L3_UNSHARED_HIT โ€” (Event CBH, Umask 04H) counts the number of retired loads that hit their own, unshared lines in the L3 cache.
  • MEM_LOAD_RETIRED.OTHER_CORE_L2_HIT_HITM โ€” (Event CBH, Umask 08H) counts the number of retired loads that hit in a sibling core's L2 (on die core). Since the L3 is inclusive of all cores on the package, this is an L3 hit โ€” and it counts both clean or modified hits.
  • MEM_LOAD_RETIRED.L3_MISS โ€” (Event CBH, Umask 10H) counts the number of retired loads that miss the L3 cache. The load was satisfied by a remote socket, local memory or an IOH.
  • MEM_LOAD_RETIRED.HIT_LFB โ€” (Event CBH, Umask 40H) counts the number of retired loads that miss the L1D and the address is located in an allocated line fill buffer and will soon be committed to cache. Basically it's counting secondary L1D misses. ๐Ÿซถ
  • MEM_LOAD_RETIRED.DTLB_MISS โ€” (Event CBH, Umask 80H) counts the number of retired loads that missed the DTLB. Heads up tho: the DTLB miss is not counted if the load operation causes a fault. This event counts loads from cacheable memory only. It also does not count loads by software prefetches. And it counts both primary and secondary misses to the TLB. ๐Ÿ’œ
  • FP_MMX_TRANS.TO_FP โ€” (Event CCH, Umask 01H) counts the first floating-point instruction following any MMX instruction. You can use this event to estimate the penalties for the transitions between floating-point and MMX technology states.
  • FP_MMX_TRANS.TO_MMX โ€” (Event CCH, Umask 02H) counts the first MMX instruction following a floating-point instruction. Same deal โ€” you can use this event to estimate the penalties for the transitions between floating-point and MMX technology states.
  • FP_MMX_TRANS.ANY โ€” (Event CCH, Umask 03H) counts all transitions from floating point to MMX instructions and from MMX instructions to floating point instructions. You can use this event to estimate the penalties for the transitions between floating-point and MMX technology states. Iconic triple threat honestly. ๐Ÿ‘‘
  • MACRO_INSTS.DECODED โ€” (Event D0H, Umask 01H) counts the number of instructions decoded (but not necessarily executed or retired). Decoded โ‰  done, bestie.
  • UOPS_DECODED.STALL_CYCLES โ€” (Event D1H, Umask 01H) counts the cycles of decoder stalls.
  • UOPS_DECODED.MS โ€” (Event D1H, Umask 02H) counts the number of Uops decoded by the Microcode Sequencer, MS. The MS delivers uops when the instruction is more than 4 uops long or a microcode assist is occurring.
  • UOPS_DECODED.ESP_FOLDING โ€” (Event D1H, Umask 04H) counts the number of stack pointer (ESP) instructions decoded: push, pop, call, ret, etc. ESP instructions do not generate a Uop to increment or decrement ESP. Instead, they update an ESP_Offset register that keeps track of the delta to the current value of the ESP register. ๐Ÿงš
  • UOPS_DECODED.ESP_SYNC โ€” (Event D1H, Umask 08H) counts the number of stack pointer (ESP) sync operations where an ESP instruction is corrected by adding the ESP offset register to the current value of the ESP register.
  • RAT_STALLS.FLAGS โ€” (Event D2H, Umask 01H) counts the number of cycles during which execution stalled due to several reasons, one of which is a partial flag register stall. A partial register stall may occur when two conditions are met: 1) an instruction modifies some, but not all, of the flags in the flag register and 2) the next instruction, which depends on flags, depends on flags that were not modified by this instruction. ๐Ÿ˜ญ
  • RAT_STALLS.REGISTERS โ€” (Event D2H, Umask 02H) this event counts the number of cycles instruction execution latency became longer than the defined latency because the instruction used a register that was partially written by previous instruction.
  • RAT_STALLS.ROB_READ_PORT โ€” (Event D2H, Umask 04H) counts the number of cycles when ROB read port stalls occurred, which did not allow new micro-ops to enter the out-of-order pipeline. Ngl this one's a little messy: at this stage in the pipeline, additional stalls may occur at the same cycle and prevent the stalled micro-ops from entering the pipe. In such a case, micro-ops retry entering the execution pipe in the next cycle and the ROB-read port stall is counted again.
  • RAT_STALLS.SCOREBOARD โ€” (Event D2H, Umask 08H) counts the cycles where we stall due to microarchitecturally required serialization. Microcode scoreboarding stalls.
  • RAT_STALLS.ANY โ€” (Event D2H, Umask 0FH) counts all Register Allocation Table stall cycles due to: cycles when ROB read port stalls occurred, which did not allow new micro-ops to enter the execution pipe; cycles when partial register stalls occurred; cycles when flag stalls occurred; cycles floating-point unit (FPU) status word stalls occurred. To count each of these conditions separately use the events: RAT_STALLS.ROB_READ_PORT, RAT_STALLS.PARTIAL, RAT_STALLS.FLAGS, and RAT_STALLS.FPSW. ๐Ÿ”ฅ
  • SEG_RENAME_STALLS โ€” (Event D4H, Umask 01H) counts the number of stall cycles due to the lack of renaming resources for the ES, DS, FS, and GS segment registers. If a segment is renamed but not retired and a second update to the same segment occurs, a stall occurs in the front-end of the pipeline until the renamed segment retires.
  • ES_REG_RENAMES โ€” (Event D5H, Umask 01H) counts the number of times the ES segment register is renamed.
  • UOP_UNFUSION โ€” (Event DBH, Umask 01H) counts unfusion events due to floating point exception to a fused uop. ๐Ÿ’€
  • BR_INST_DECODED โ€” (Event E0H, Umask 01H) counts the number of branch instructions decoded.
  • BPU_MISSED_CALL_RET โ€” (Event E5H, Umask 01H) counts the number of times the Branch Prediction Unit missed predicting a call or return branch. ๐Ÿ™ˆ
  • BACLEAR.CLEAR โ€” (Event E6H, Umask 01H) counts the number of times the front end is resteered, mainly when the Branch Prediction Unit cannot provide a correct prediction and this is corrected by the Branch Address Calculator at the front end. This can occur if the code has many branches such that they cannot be consumed by the BPU. Each BACLEAR asserted by the BAC generates approximately an 8 cycle bubble in the instruction fetch pipeline. The effect on total execution time depends on the surrounding code.
  • BACLEAR.BAD_TARGET โ€” (Event E6H, Umask 02H) counts the number of Branch Address Calculator clears (BACLEAR) asserted due to conditional branch instructions in which there was a target hit but the direction was wrong. Each BACLEAR asserted by the BAC generates approximately an 8 cycle bubble in the instruction fetch pipeline. ๐Ÿซ 
  • BPU_CLEARS.EARLY โ€” (Event E8H, Umask 01H) counts early (normal) Branch Prediction Unit clears: the BPU predicted a taken branch after incorrectly assuming that it was not taken. The BPU clear leads to a 2 cycle bubble in the Front End. ๐ŸŒธ
  • BPU_CLEARS.LATE โ€” (Event E8H, Umask 02H) counts late Branch Prediction Unit clears caused by Most Recently Used conflicts. The PBU clear leads to a 3 cycle bubble in the Front End. ๐Ÿ’€
  • THREAD_ACTIVE โ€” (Event ECH, Umask 01H) counts the cycles threads are active. bestie is booked and busy โœจ
  • L2_TRANSACTIONS.LOAD โ€” (Event F0H, Umask 01H) counts L2 load operations due to HW prefetch or demand loads.
  • L2_TRANSACTIONS.RFO โ€” (Event F0H, Umask 02H) counts L2 RFO operations due to HW prefetch or demand RFOs.
  • L2_TRANSACTIONS.IFETCH โ€” (Event F0H, Umask 04H) counts L2 instruction fetch operations due to HW prefetch or demand ifetch.
  • L2_TRANSACTIONS.PREFETCH โ€” (Event F0H, Umask 08H) counts L2 prefetch operations.
  • L2_TRANSACTIONS.L1D_WB โ€” (Event F0H, Umask 10H) counts L1D writeback operations to the L2.
  • L2_TRANSACTIONS.FILL โ€” (Event F0H, Umask 20H) counts L2 cache line fill operations due to load, RFO, L1D writeback or prefetch.
  • L2_TRANSACTIONS.WB โ€” (Event F0H, Umask 40H) counts L2 writeback operations to the L3.
  • L2_TRANSACTIONS.ANY โ€” (Event F0H, Umask 80H) counts all L2 cache operations. the whole eras tour, basically ๐ŸŽค
  • L2_LINES_IN.S_STATE โ€” (Event F1H, Umask 02H) counts the number of cache lines allocated in the L2 cache in the S (shared) state.
  • L2_LINES_IN.E_STATE โ€” (Event F1H, Umask 04H) counts the number of cache lines allocated in the L2 cache in the E (exclusive) state.
  • L2_LINES_IN.ANY โ€” (Event F1H, Umask 07H) counts the number of cache lines allocated in the L2 cache.
  • L2_LINES_OUT.DEMAND_CLEAN โ€” (Event F2H, Umask 01H) counts L2 clean cache lines evicted by a demand request.
  • L2_LINES_OUT.DEMAND_DIRTY โ€” (Event F2H, Umask 02H) counts L2 dirty (modified) cache lines evicted by a demand request. messy but make it fashion ๐Ÿ’…
  • L2_LINES_OUT.PREFETCH_CLEAN โ€” (Event F2H, Umask 04H) counts L2 clean cache line evicted by a prefetch request.
  • L2_LINES_OUT.PREFETCH_DIRTY โ€” (Event F2H, Umask 08H) counts L2 modified cache line evicted by a prefetch request.
  • L2_LINES_OUT.ANY โ€” (Event F2H, Umask 0FH) counts all L2 cache lines evicted for any reason.
  • SQ_MISC.LRU_HINTS โ€” (Event F4H, Umask 04H) counts number of Super Queue LRU hints sent to L3.
  • SQ_MISC.SPLIT_LOCK โ€” (Event F4H, Umask 10H) counts the number of SQ lock splits across a cache line.
  • SQ_FULL_STALL_CYCLES โ€” (Event F6H, Umask 01H) counts cycles the Super Queue is full. Neither of the threads on this core will be able to access the uncore. no thoughts, queue full ๐Ÿ˜ญ
  • FP_ASSIST.ALL โ€” (Event F7H, Umask 01H) counts the number of floating point operations executed that required micro-code assist intervention. Assists are required in the following cases: SSE instructions, (Denormal input when the DAZ flag is off or Underflow result when the FTZ flag is off): x87 instructions, (NaN or denormal are loaded to a register or used as input from memory, Division by 0 or Underflow output).
  • FP_ASSIST.OUTPUT โ€” (Event F7H, Umask 02H) counts number of floating point micro-code assist when the output value (destination register) is invalid.
  • FP_ASSIST.INPUT โ€” (Event F7H, Umask 04H) counts number of floating point micro-code assist when the input value (one of the source operands to an FP instruction) is invalid.
  • SIMD_INT_64.PACKED_MPY โ€” (Event FDH, Umask 01H) counts number of SID integer 64 bit packed multiply operations.
  • SIMD_INT_64.PACKED_SHIFT โ€” (Event FDH, Umask 02H) counts number of SID integer 64 bit packed shift operations.
  • SIMD_INT_64.PACK โ€” (Event FDH, Umask 04H) counts number of SID integer 64 bit pack operations.
  • SIMD_INT_64.UNPACK โ€” (Event FDH, Umask 08H) counts number of SID integer 64 bit unpack operations.
  • SIMD_INT_64.PACKED_LOGICAL โ€” (Event FDH, Umask 10H) counts number of SID integer 64 bit logical operations.
  • SIMD_INT_64.PACKED_ARITH โ€” (Event FDH, Umask 20H) counts number of SID integer 64 bit arithmetic operations.
  • SIMD_INT_64.SHUFFLE_MOVE โ€” (Event FDH, Umask 40H) counts number of SID integer 64 bit shift or move operations.

๐Ÿซถ SEE ALSO

like, go read these next, they're all in the group chat:

pmc(3), pmc.amd(3), pmc.atom(3), pmc.core(3), pmc.corei7(3), pmc.corei7uc(3), pmc.iaf(3), pmc.soft(3), pmc.tsc(3), pmc.ucf(3), pmc.westmereuc(3), pmc_cpuinfo(3), pmclog(3), hwpmc(4)


๐ŸŒธ HISTORY

okay so the pmc library first appeared in FreeBSD 6.0. vintage. iconic. it's giving elder millennial of libraries ๐Ÿ’œ


๐Ÿ‘‘ AUTHORS

The Performance Counters Library (libpmc, -lpmc) library was written by Joseph Koshy <jkoshy@FreeBSD.org>. thank you king, we stan ๐Ÿซกโœจ


and that's the whole page, bestie โ€” no cap, you now know more about Westmere performance counters than most people know about themselves. go forth and profile responsibly ๐Ÿฆ‹๐Ÿ’–

this one's from the Debian edition, dated February 25, 2012 โ€” a little time capsule of a manpage, still slaying in the terminal to this day ๐ŸŽ€

๐Ÿ“ฆ where this page comes from
  • freebsd 15.1: base 15.1
  • ๐Ÿ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms