PMC.WESTMEREUC(3)

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

๐ŸŒธ NAME ๐ŸŒธ

bestie, this is pmc.westmere โ€” the uncore measurement events for Intel Westmere family CPUs, straight out of section 3 of the manual. iykyk โœจ

๐Ÿซถ LIBRARY ๐Ÿซถ

Performance Counters Library (libpmc, -lpmc)

๐Ÿ’œ SYNOPSIS ๐Ÿ’œ

#include <pmc.h>

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

okay so. Intel Westmere CPUs are packing PMCs that conform to version 2 of the Intel performance measurement architecture โ€” like, they're certified for the vibe. these CPUs contain two classes of PMCs:

  • PMC_CLASS_UCF โ€” fixed-function counters. they count only one hardware event per counter, no choices, no negotiation, main character energy but make it singular ๐Ÿ’…
  • PMC_CLASS_UCP โ€” programmable counters. these you can configure to count one of a defined set of hardware events, which is honestly the more fun class.
ngl, the number of PMCs available in each class and their widths are not something you can just assume โ€” you have to determine them at run time by calling pmc_cpuinfo(3). do not skip the vibe check ๐Ÿ”

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. (yes, "Developes" โ€” that's literally how it's printed, i'm not touching it ๐Ÿซฃ)


๐ŸŽ€ WESTMERE UNCORE FIXED FUNCTION PMCS ๐ŸŽ€

these PMCs and their supported events are documented over in pmc.ucf(3). important caveat bestie: not all CPUs in this family implement fixed-function counters, so don't just assume they're there โ€” check at runtime, fr fr.

โญ WESTMERE UNCORE PROGRAMMABLE PMCS โญ

the programmable PMCs support the following capabilities โ€” presenting them as a list because we're cute and tables are not:

  • PMC_CAP_CASCADE โ€” No ๐Ÿ™…
  • PMC_CAP_EDGE โ€” Yes โœจ
  • PMC_CAP_INTERRUPT โ€” No
  • PMC_CAP_INVERT โ€” Yes
  • PMC_CAP_READ โ€” Yes
  • PMC_CAP_PRECISE โ€” No
  • PMC_CAP_SYSTEM โ€” No
  • PMC_CAP_TAGGING โ€” No
  • PMC_CAP_THRESHOLD โ€” Yes
  • PMC_CAP_USER โ€” No
  • PMC_CAP_WRITE โ€” Yes

๐ŸŒˆ Event Qualifiers ๐ŸŒˆ

event specifiers for these PMCs support the following common qualifiers โ€” these are basically the little add-on accessories for your event, the earrings if you will ๐Ÿ’–:

  • 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 โ†’ asserted transitions of the conditions expressed by the other qualifiers. if you spec this, the counter increments only once whenever a condition becomes true, no matter how many clocks the condition stays true for. one and done, periodt.
  • 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. the opposite girlie ๐Ÿฉท

๐Ÿงš Event Specifiers (Programmable PMCs) ๐Ÿงš

Westmere uncore programmable PMCs support the following events. yes, all of them. grab a snack, we're going through every single one ๐Ÿ“

  • GQ_CYCLES_FULL.READ_TRACKER โ€” (Event 00H, Umask 01H) Uncore cycles Global Queue read tracker is full.
  • GQ_CYCLES_FULL.WRITE_TRACKER โ€” (Event 00H, Umask 02H) Uncore cycles Global Queue write tracker is full.
  • GQ_CYCLES_FULL.PEER_PROBE_TRACKER โ€” (Event 00H, Umask 04H) Uncore cycles Global Queue peer probe tracker is full. the peer probe tracker queue tracks snoops from the IOH and remote sockets.
  • GQ_CYCLES_NOT_EMPTY.READ_TRACKER โ€” (Event 01H, Umask 01H) Uncore cycles were Global Queue read tracker has at least one valid entry.
  • GQ_CYCLES_NOT_EMPTY.WRITE_TRACKER โ€” (Event 01H, Umask 02H) Uncore cycles were Global Queue write tracker has at least one valid entry.
  • GQ_CYCLES_NOT_EMPTY.PEER_PROBE_TRACKER โ€” (Event 01H, Umask 04H) Uncore cycles were Global Queue peer probe tracker has at least one valid entry. the peer probe tracker queue tracks IOH and remote socket snoops.
  • GQ_OCCUPANCY.READ_TRACKER โ€” (Event 02H, Umask 01H) Increments the number of queue entries (code read, data read, and RFOs) in the tread tracker. the GQ read tracker allocate to deallocate occupancy count is divided by the count to obtain the average read tracker latency.
  • GQ_ALLOC.READ_TRACKER โ€” (Event 03H, Umask 01H) Counts the number of tread tracker allocate to deallocate entries. the GQ read tracker allocate to deallocate occupancy count is divided by the count to obtain the average read tracker latency.
  • GQ_ALLOC.RT_L3_MISS โ€” (Event 03H, Umask 02H) Counts the number GQ read tracker entries for which a full cache line read has missed the L3. the GQ read tracker L3 miss to fill occupancy count is divided by this count to obtain the average cache line read L3 miss latency. the latency represents the time after which the L3 has determined that the cache line has missed. the time between a GQ read tracker allocation and the L3 determining that the cache line has missed is the average L3 hit latency. the total L3 cache line read miss latency is the hit latency + L3 miss latency. math girlie behavior ๐Ÿงฎ
  • GQ_ALLOC.RT_TO_L3_RESP โ€” (Event 03H, Umask 04H) Counts the number of GQ read tracker entries that are allocated in the read tracker queue that hit or miss the L3. the GQ read tracker L3 hit occupancy count is divided by this count to obtain the average L3 hit latency.
  • GQ_ALLOC.RT_TO_RTID_ACQUIRED โ€” (Event 03H, Umask 08H) Counts the number of GQ read tracker entries that are allocated in the read tracker, have missed in the L3 and have not acquired a Request Transaction ID. the GQ read tracker L3 miss to RTID acquired occupancy count is divided by this count to obtain the average latency for a read L3 miss to acquire an RTID.
  • GQ_ALLOC.WT_TO_RTID_ACQUIRED โ€” (Event 03H, Umask 10H) Counts the number of GQ write tracker entries that are allocated in the write tracker, have missed in the L3 and have not acquired a Request Transaction ID. the GQ write tracker L3 miss to RTID occupancy count is divided by this count to obtain the average latency for a write L3 miss to acquire an RTID.
  • GQ_ALLOC.WRITE_TRACKER โ€” (Event 03H, Umask 20H) Counts the number of GQ write tracker entries that are allocated in the write tracker queue that miss the L3. the GQ write tracker occupancy count is divided by the this count to obtain the average L3 write miss latency.
  • GQ_ALLOC.PEER_PROBE_TRACKER โ€” (Event 03H, Umask 40H) Counts the number of GQ peer probe tracker (snoop) entries that are allocated in the peer probe tracker queue that miss the L3. the GQ peer probe occupancy count is divided by this count to obtain the average L3 peer probe miss latency.
  • GQ_DATA.FROM_QPI โ€” (Event 04H, Umask 01H) Cycles Global Queue Quickpath Interface input data port is busy importing data from the Quickpath Interface. each cycle the input port can transfer 8 or 16 bytes of data.
  • GQ_DATA.FROM_QMC โ€” (Event 04H, Umask 02H) Cycles Global Queue Quickpath Memory Interface input data port is busy importing data from the Quickpath Memory Interface. each cycle the input port can transfer 8 or 16 bytes of data.
  • GQ_DATA.FROM_L3 โ€” (Event 04H, Umask 04H) Cycles GQ L3 input data port is busy importing data from the Last Level Cache. each cycle the input port can transfer 32 bytes of data.
  • GQ_DATA.FROM_CORES_02 โ€” (Event 04H, Umask 08H) Cycles GQ Core 0 and 2 input data port is busy importing data from processor cores 0 and 2. each cycle the input port can transfer 32 bytes of data.
  • GQ_DATA.FROM_CORES_13 โ€” (Event 04H, Umask 10H) Cycles GQ Core 1 and 3 input data port is busy importing data from processor cores 1 and 3. each cycle the input port can transfer 32 bytes of data.
  • GQ_DATA.TO_QPI_QMC โ€” (Event 05H, Umask 01H) Cycles GQ QPI and QMC output data port is busy sending data to the Quickpath Interface or Quickpath Memory Interface. each cycle the output port can transfer 32 bytes of data.
  • GQ_DATA.TO_L3 โ€” (Event 05H, Umask 02H) Cycles GQ L3 output data port is busy sending data to the Last Level Cache. each cycle the output port can transfer 32 bytes of data.
  • GQ_DATA.TO_CORES โ€” (Event 05H, Umask 04H) Cycles GQ Core output data port is busy sending data to the Cores. each cycle the output port can transfer 32 bytes of data.
  • SNP_RESP_TO_LOCAL_HOME.I_STATE โ€” (Event 06H, Umask 01H) Number of snoop responses to the local home that L3 does not have the referenced cache line.
  • SNP_RESP_TO_LOCAL_HOME.S_STATE โ€” (Event 06H, Umask 02H) Number of snoop responses to the local home that L3 has the referenced line cached in the S state.
  • SNP_RESP_TO_LOCAL_HOME.FWD_S_STATE โ€” (Event 06H, Umask 04H) Number of responses to code or data read snoops to the local home that the L3 has the referenced cache line in the E state. the L3 cache line state is changed to the S state and the line is forwarded to the local home in the S state.
  • SNP_RESP_TO_LOCAL_HOME.FWD_I_STATE โ€” (Event 06H, Umask 08H) Number of responses to read invalidate snoops to the local home that the L3 has the referenced cache line in the M state. the L3 cache line state is invalidated and the line is forwarded to the local home in the M state.
  • SNP_RESP_TO_LOCAL_HOME.CONFLICT โ€” (Event 06H, Umask 10H) Number of conflict snoop responses sent to the local home.
  • SNP_RESP_TO_LOCAL_HOME.WB โ€” (Event 06H, Umask 20H) Number of responses to code or data read snoops to the local home that the L3 has the referenced line cached in the M state.
  • SNP_RESP_TO_REMOTE_HOME.I_STATE โ€” (Event 07H, Umask 01H) Number of snoop responses to a remote home that L3 does not have the referenced cache line.
  • SNP_RESP_TO_REMOTE_HOME.S_STATE โ€” (Event 07H, Umask 02H) Number of snoop responses to a remote home that L3 has the referenced line cached in the S state.
  • SNP_RESP_TO_REMOTE_HOME.FWD_S_STATE โ€” (Event 07H, Umask 04H) Number of responses to code or data read snoops to a remote home that the L3 has the referenced cache line in the E state. the L3 cache line state is changed to the S state and the line is forwarded to the remote home in the S state.
  • SNP_RESP_TO_REMOTE_HOME.FWD_I_STATE โ€” (Event 07H, Umask 08H) Number of responses to read invalidate snoops to a remote home that the L3 has the referenced cache line in the M state. the L3 cache line state is invalidated and the line is forwarded to the remote home in the M state.
  • SNP_RESP_TO_REMOTE_HOME.CONFLICT โ€” (Event 07H, Umask 10H) how many conflict snoop responses got sent to the local home โœจ
  • SNP_RESP_TO_REMOTE_HOME.WB โ€” (Event 07H, Umask 20H) the number of responses to code read or data read snoops headed to a remote home where the L3 lowkey already has the referenced line cached in the M state ๐Ÿ’…
  • SNP_RESP_TO_REMOTE_HOME.HITM โ€” (Event 07H, Umask 24H) how many HITM snoop responses went to a remote home ๐Ÿซถ

  • L3_HITS.READ โ€” (Event 08H, Umask 01H) code read, data read and RFO requests that hit in the L3, counted up ๐ŸŒธ
  • L3_HITS.WRITE โ€” (Event 08H, Umask 02H) writeback requests that hit in the L3. ngl, writebacks from the cores always land as L3 hits because the L3 is inclusive, so this one's kind of a guaranteed slay ๐Ÿ’–
  • L3_HITS.PROBE โ€” (Event 08H, Umask 04H) snoops coming in from IOH or remote sockets that hit in the L3 ๐Ÿ‘‘
  • L3_HITS.ANY โ€” (Event 08H, Umask 03H) reads and writes that hit the L3, all together, one number โœจ
  • L3_MISS.READ โ€” (Event 09H, Umask 01H) code read, data read and RFO requests that miss the L3 ๐Ÿ˜ญ
  • L3_MISS.WRITE โ€” (Event 09H, Umask 02H) writeback requests that miss the L3. bestie this should literally always be zero โ€” writebacks from the cores will always result in L3 hits thanks to the inclusive property of the L3 ๐Ÿ’€
  • L3_MISS.PROBE โ€” (Event 09H, Umask 04H) snoops from IOH or remote sockets that miss the L3 ๐Ÿ™ˆ
  • L3_MISS.ANY โ€” (Event 09H, Umask 03H) reads and writes that miss the L3, bundled up ๐ŸŽ€

  • L3_LINES_IN.M_STATE โ€” (Event 0AH, Umask 01H) counts how many L3 lines get allocated in M state. the only time a cache line is allocated in the M state is when the line was forwarded in M state because of a Snoop Read Invalidate Own request ๐Ÿ”ฅ
  • L3_LINES_IN.E_STATE โ€” (Event 0AH, Umask 02H) counts the L3 lines allocated in E state ๐Ÿฆ‹
  • L3_LINES_IN.S_STATE โ€” (Event 0AH, Umask 04H) counts the L3 lines allocated in S state ๐ŸŒˆ
  • L3_LINES_IN.F_STATE โ€” (Event 0AH, Umask 08H) counts the L3 lines allocated in F state โญ
  • L3_LINES_IN.ANY โ€” (Event 0AH, Umask 0FH) counts the L3 lines allocated in any state โ€” the whole vibe check ๐Ÿ’œ
  • L3_LINES_OUT.M_STATE โ€” (Event 0BH, Umask 01H) counts the L3 lines that got victimized while they were in the M state. when the victim cache line is in M state, the line gets written to its home cache agent, which can be either local or remote ๐Ÿ‘€
  • L3_LINES_OUT.E_STATE โ€” (Event 0BH, Umask 02H) counts the L3 lines victimized while in the E state ๐Ÿงš
  • L3_LINES_OUT.S_STATE โ€” (Event 0BH, Umask 04H) counts the L3 lines victimized while in the S state ๐ŸŒธ
  • L3_LINES_OUT.I_STATE โ€” (Event 0BH, Umask 08H) counts the L3 lines victimized while in the I state ๐Ÿ“
  • L3_LINES_OUT.F_STATE โ€” (Event 0BH, Umask 10H) counts the L3 lines victimized while in the F state โœจ
  • L3_LINES_OUT.ANY โ€” (Event 0BH, Umask 1FH) counts the L3 lines victimized in any state at all ๐Ÿ’ซ

  • GQ_SNOOP.GOTO_S โ€” (Event 0CH, Umask 01H) counts remote snoops that asked for a cache line to be set to the S state ๐Ÿ™Œ
  • GQ_SNOOP.GOTO_I โ€” (Event 0CH, Umask 02H) counts remote snoops that asked for a cache line to be set to the I state ๐Ÿ’…
  • GQ_SNOOP.GOTO_S_HIT_E โ€” (Event 0CH, Umask 04H) counts remote snoops that asked for a cache line to be set to the S state from E state. this one requires writing MSR 301H with mask = 2H ๐ŸŽ€
  • GQ_SNOOP.GOTO_S_HIT_F โ€” (Event 0CH, Umask 04H) counts remote snoops that asked for a cache line to be set to the S state from F (forward) state. requires writing MSR 301H with mask = 8H ๐Ÿฆ‹
  • GQ_SNOOP.GOTO_S_HIT_M โ€” (Event 0CH, Umask 04H) counts remote snoops that asked for a cache line to be set to the S state from M state. requires writing MSR 301H with mask = 1H ๐Ÿ”ฅ
  • GQ_SNOOP.GOTO_S_HIT_S โ€” (Event 0CH, Umask 04H) counts remote snoops that asked for a cache line to be set to the S state from S state. requires writing MSR 301H with mask = 4H ๐ŸŒˆ
  • GQ_SNOOP.GOTO_I_HIT_E โ€” (Event 0CH, Umask 08H) counts remote snoops that asked for a cache line to be set to the I state from E state. requires writing MSR 301H with mask = 2H โญ
  • GQ_SNOOP.GOTO_I_HIT_F โ€” (Event 0CH, Umask 08H) counts remote snoops that asked for a cache line to be set to the I state from F (forward) state. requires writing MSR 301H with mask = 8H ๐Ÿ’œ
  • GQ_SNOOP.GOTO_I_HIT_M โ€” (Event 0CH, Umask 08H) counts remote snoops that asked for a cache line to be set to the I state from M state. requires writing MSR 301H with mask = 1H ๐Ÿ‘‘
  • GQ_SNOOP.GOTO_I_HIT_S โ€” (Event 0CH, Umask 08H) counts remote snoops that asked for a cache line to be set to the I state from S state. requires writing MSR 301H with mask = 4H ๐ŸŒธ

  • QHL_REQUESTS.IOH_READS โ€” (Event 20H, Umask 01H) counts the Quickpath Home Logic read requests coming from the IOH ๐Ÿ“–
  • QHL_REQUESTS.IOH_WRITES โ€” (Event 20H, Umask 02H) counts the Quickpath Home Logic write requests coming from the IOH โœ๏ธ
  • QHL_REQUESTS.REMOTE_READS โ€” (Event 20H, Umask 04H) counts the Quickpath Home Logic read requests coming from a remote socket ๐ŸŒ
  • QHL_REQUESTS.REMOTE_WRITES โ€” (Event 20H, Umask 08H) counts the Quickpath Home Logic write requests coming from a remote socket ๐Ÿ’Œ
  • QHL_REQUESTS.LOCAL_READS โ€” (Event 20H, Umask 10H) counts the Quickpath Home Logic read requests coming from the local socket ๐Ÿ 
  • QHL_REQUESTS.LOCAL_WRITES โ€” (Event 20H, Umask 20H) counts the Quickpath Home Logic write requests coming from the local socket ๐Ÿซถ
  • QHL_CYCLES_FULL.IOH โ€” (Event 21H, Umask 01H) counts uclk cycles where all the entries in the Quickpath Home Logic IOH are full ๐Ÿ˜ณ
  • QHL_CYCLES_FULL.REMOTE โ€” (Event 21H, Umask 02H) counts uclk cycles where all the entries in the Quickpath Home Logic remote tracker are full ๐Ÿ’€
  • QHL_CYCLES_FULL.LOCAL โ€” (Event 21H, Umask 04H) counts uclk cycles where all the entries in the Quickpath Home Logic local tracker are full ๐Ÿ˜ญ
  • QHL_CYCLES_NOT_EMPTY.IOH โ€” (Event 22H, Umask 01H) counts uclk cycles where all the entries in the Quickpath Home Logic IOH are busy ๐ŸŒ€
  • QHL_CYCLES_NOT_EMPTY.REMOTE โ€” (Event 22H, Umask 02H) counts uclk cycles where all the entries in the Quickpath Home Logic remote tracker are busy ๐Ÿ”„
  • QHL_CYCLES_NOT_EMPTY.LOCAL โ€” (Event 22H, Umask 04H) counts uclk cycles where all the entries in the Quickpath Home Logic local tracker are busy โœจ
  • QHL_OCCUPANCY.IOH โ€” (Event 23H, Umask 01H) QHL IOH tracker allocate-to-deallocate read occupancy ๐ŸŽ€
  • QHL_OCCUPANCY.REMOTE โ€” (Event 23H, Umask 02H) QHL remote tracker allocate-to-deallocate read occupancy ๐Ÿฆ‹
  • QHL_OCCUPANCY.LOCAL โ€” (Event 23H, Umask 04H) QHL local tracker allocate-to-deallocate read occupancy ๐ŸŒธ

  • QHL_ADDRESS_CONFLICTS.2WAY โ€” (Event 24H, Umask 02H) counts the QHL Active Address Table (AAT) entries that saw a max of 2 conflicts. the AAT is a structure that tracks requests which are in conflict โ€” the requests themselves live in the home tracker entries โ€” and the count gets reported when an AAT entry deallocates ๐Ÿ‘€
  • QHL_ADDRESS_CONFLICTS.3WAY โ€” (Event 24H, Umask 04H) counts the QHL Active Address Table (AAT) entries that saw a max of 3 conflicts. same deal: the AAT tracks requests that are in conflict, the requests themselves hang out in the home tracker entries, and the count is reported when an AAT entry deallocates ๐Ÿ’…
  • QHL_CONFLICT_CYCLES.IOH โ€” (Event 25H, Umask 01H) counts cycles where the Quickpath Home Logic IOH Tracker holds two or more requests with an address conflict. a max of 3 requests can be in conflict ๐Ÿ”ฅ
  • QHL_CONFLICT_CYCLES.REMOTE โ€” (Event 25H, Umask 02H) counts cycles where the Quickpath Home Logic Remote Tracker holds two or more requests with an address conflict. a max of 3 requests can be in conflict ๐ŸŒˆ
  • QHL_CONFLICT_CYCLES.LOCAL โ€” (Event 25H, Umask 04H) counts cycles where the Quickpath Home Logic Local Tracker holds two or more requests with an address conflict. a max of 3 requests can be in conflict โญ
  • QHL_TO_QMC_BYPASS โ€” (Event 26H, Umask 01H) counts the requests to the Quickpath Memory Controller that bypass the Quickpath Home Logic. all local accesses can be bypassed; for remote requests, only read requests can be bypassed ๐Ÿš€

  • QMC_ISOC_FULL.READ.CH0 โ€” (Event 28H, Umask 01H) counts cycles where all the entries in the DRAM channel 0 high priority queue are occupied with isochronous read requests ๐ŸŒŠ
  • QMC_ISOC_FULL.READ.CH1 โ€” (Event 28H, Umask 02H) counts cycles where all the entries in the DRAM channel 1 high priority queue are occupied with isochronous read requests ๐ŸŒŠ
  • QMC_ISOC_FULL.READ.CH2 โ€” (Event 28H, Umask 04H) counts cycles where all the entries in the DRAM channel 2 high priority queue are occupied with isochronous read requests ๐ŸŒŠ
  • QMC_ISOC_FULL.WRITE.CH0 โ€” (Event 28H, Umask 08H) counts cycles where all the entries in the DRAM channel 0 high priority queue are occupied with isochronous write requests ๐Ÿ–Š๏ธ
  • QMC_ISOC_FULL.WRITE.CH1 โ€” (Event 28H, Umask 10H) counts cycles where all the entries in the DRAM channel 1 high priority queue are occupied with isochronous write requests ๐Ÿ–Š๏ธ
  • QMC_ISOC_FULL.WRITE.CH2 โ€” (Event 28H, Umask 20H) counts cycles where all the entries in the DRAM channel 2 high priority queue are occupied with isochronous write requests ๐Ÿ–Š๏ธ
  • QMC_BUSY.READ.CH0 โ€” (Event 29H, Umask 01H) counts cycles where the Quickpath Memory Controller has at least 1 outstanding read request to DRAM channel 0 ๐Ÿ’ซ
  • QMC_BUSY.READ.CH1 โ€” (Event 29H, Umask 02H) counts cycles where the Quickpath Memory Controller has at least 1 outstanding read request to DRAM channel 1 ๐Ÿ’ซ
  • QMC_BUSY.READ.CH2 โ€” (Event 29H, Umask 04H) counts the cycles where the Quickpath Memory Controller has at least one outstanding read request hanging out to DRAM channel 2. โœจ
  • QMC_BUSY.WRITE.CH0 โ€” (Event 29H, Umask 08H) counts cycles where the Quickpath Memory Controller has one or more outstanding write requests to DRAM channel 0.
  • QMC_BUSY.WRITE.CH1 โ€” (Event 29H, Umask 10H) same deal but for DRAM channel 1 โ€” cycles with at least 1 outstanding write request ๐Ÿ’…
  • QMC_BUSY.WRITE.CH2 โ€” (Event 29H, Umask 20H) and again for DRAM channel 2: cycles where the Quickpath Memory Controller has at least 1 outstanding write request.
  • QMC_OCCUPANCY.CH0 โ€” (Event 2AH, Umask 01H) IMC channel 0 normal read request occupancy ๐Ÿซถ
  • QMC_OCCUPANCY.CH1 โ€” (Event 2AH, Umask 02H) IMC channel 1 normal read request occupancy.
  • QMC_OCCUPANCY.CH2 โ€” (Event 2AH, Umask 04H) IMC channel 2 normal read request occupancy.
  • QMC_OCCUPANCY.ANY โ€” (Event 2AH, Umask 07H) normal read request occupancy, any channel, we're not picking favorites ๐Ÿ’–
  • QMC_ISSOC_OCCUPANCY.CH0 โ€” (Event 2BH, Umask 01H) IMC channel 0 issoc read request occupancy.
  • QMC_ISSOC_OCCUPANCY.CH1 โ€” (Event 2BH, Umask 02H) IMC channel 1 issoc read request occupancy.
  • QMC_ISSOC_OCCUPANCY.CH2 โ€” (Event 2BH, Umask 04H) IMC channel 2 issoc read request occupancy.
  • QMC_ISSOC_READS.ANY โ€” (Event 2BH, Umask 07H) IMC issoc read request occupancy, any channel โœจ

the latency math ones ๐Ÿงฎ

  • QMC_NORMAL_READS.CH0 โ€” (Event 2CH, Umask 01H) counts the number of Quickpath Memory Controller channel 0 medium and low priority read requests. Now bestie, the fun part: divide the QMC channel 0 normal read occupancy by this count and you get the average QMC channel 0 read latency. That's the whole trick iykyk.
  • QMC_NORMAL_READS.CH1 โ€” (Event 2CH, Umask 02H) counts Quickpath Memory Controller channel 1 medium and low priority read requests. Same story: channel 1 normal read occupancy รท this count = average QMC channel 1 read latency ๐Ÿ’œ
  • QMC_NORMAL_READS.CH2 โ€” (Event 2CH, Umask 04H) counts Quickpath Memory Controller channel 2 medium and low priority read requests. Occupancy for channel 2 divided by this = average QMC channel 2 read latency.
  • QMC_NORMAL_READS.ANY โ€” (Event 2CH, Umask 07H) counts Quickpath Memory Controller medium and low priority read requests across the board. QMC normal read occupancy รท this count = average QMC read latency, periodt ๐Ÿ‘‘
  • QMC_HIGH_PRIORITY_READS.CH0 โ€” (Event 2DH, Umask 01H) counts Quickpath Memory Controller channel 0 high priority isochronous read requests ๐Ÿ”ฅ
  • QMC_HIGH_PRIORITY_READS.CH1 โ€” (Event 2DH, Umask 02H) counts Quickpath Memory Controller channel 1 high priority isochronous read requests.
  • QMC_HIGH_PRIORITY_READS.CH2 โ€” (Event 2DH, Umask 04H) counts Quickpath Memory Controller channel 2 high priority isochronous read requests.
  • QMC_HIGH_PRIORITY_READS.ANY โ€” (Event 2DH, Umask 07H) counts Quickpath Memory Controller high priority isochronous read requests, all the channels together ๐Ÿซถ
  • QMC_CRITICAL_PRIORITY_READS.CH0 โ€” (Event 2EH, Umask 01H) counts Quickpath Memory Controller channel 0 critical priority isochronous read requests. even more urgent than high, main character energy fr ๐Ÿ’…
  • QMC_CRITICAL_PRIORITY_READS.CH1 โ€” (Event 2EH, Umask 02H) counts Quickpath Memory Controller channel 1 critical priority isochronous read requests.
  • QMC_CRITICAL_PRIORITY_READS.CH2 โ€” (Event 2EH, Umask 04H) counts Quickpath Memory Controller channel 2 critical priority isochronous read requests.
  • QMC_CRITICAL_PRIORITY_READS.ANY โ€” (Event 2EH, Umask 07H) counts Quickpath Memory Controller critical priority isochronous read requests from any channel โœจ

writes to DRAM ๐Ÿ“

  • QMC_WRITES.FULL.CH0 โ€” (Event 2FH, Umask 01H) counts the number of full cache line writes to DRAM channel 0.
  • QMC_WRITES.FULL.CH1 โ€” (Event 2FH, Umask 02H) counts full cache line writes to DRAM channel 1.
  • QMC_WRITES.FULL.CH2 โ€” (Event 2FH, Umask 04H) counts full cache line writes to DRAM channel 2.
  • QMC_WRITES.FULL.ANY โ€” (Event 2FH, Umask 07H) counts full cache line writes to DRAM. all of it, no cap ๐Ÿ’–
  • QMC_WRITES.PARTIAL.CH0 โ€” (Event 2FH, Umask 08H) counts the number of partial cache line writes to DRAM channel 0.
  • QMC_WRITES.PARTIAL.CH1 โ€” (Event 2FH, Umask 10H) counts partial cache line writes to DRAM channel 1.
  • QMC_WRITES.PARTIAL.CH2 โ€” (Event 2FH, Umask 20H) counts partial cache line writes to DRAM channel 2.
  • QMC_WRITES.PARTIAL.ANY โ€” (Event 2FH, Umask 38H) counts partial cache line writes to DRAM. (yes, 38H โ€” that one's a little different from the usual 07H, don't come for me ๐Ÿ™ˆ)
  • QMC_CANCEL.CH0 โ€” (Event 30H, Umask 01H) counts the number of DRAM channel 0 cancel requests ๐Ÿ’€
  • QMC_CANCEL.CH1 โ€” (Event 30H, Umask 02H) counts DRAM channel 1 cancel requests.
  • QMC_CANCEL.CH2 โ€” (Event 30H, Umask 04H) counts DRAM channel 2 cancel requests.
  • QMC_CANCEL.ANY โ€” (Event 30H, Umask 07H) counts DRAM cancel requests, any channel.

priority updates ๐Ÿ‘‘

  • QMC_PRIORITY_UPDATES.CH0 โ€” (Event 31H, Umask 01H) counts the number of DRAM channel 0 priority updates. So what even is a priority update? It's when the QHL receives an ISOC high or critical request, and there's already a matching normal-priority request that's been issued to the QMC. In that case the QHL sends a priority update to the QMC to expedite the request. iconic behavior honestly.
  • QMC_PRIORITY_UPDATES.CH1 โ€” (Event 31H, Umask 02H) counts DRAM channel 1 priority updates. Same definition: an ISOC high or critical request lands at the QHL while a matching normal priority request is already issued to the QMC, so the QHL fires off a priority update to the QMC to expedite it ๐Ÿซถ
  • QMC_PRIORITY_UPDATES.CH2 โ€” (Event 31H, Umask 04H) counts DRAM channel 2 priority updates. ISOC high or critical request + matching already-issued normal priority request = QHL sends a priority update to QMC to expedite. you get it ๐Ÿ’…
  • QMC_PRIORITY_UPDATES.ANY โ€” (Event 31H, Umask 07H) counts DRAM priority updates overall. A priority update happens when the QHL gets an ISOC high or critical request and there's a matching normal priority request already issued to the QMC โ€” the QHL then sends a priority update to QMC to expedite that request. โœจ

retries (RAS mode only, heads up) ๐Ÿ”

  • IMC_RETRY.CH0 โ€” (Event 32H, Umask 01H) counts the number of IMC DRAM channel 0 retries. Lowkey important caveat: DRAM retry only occurs when configured in RAS mode.
  • IMC_RETRY.CH1 โ€” (Event 32H, Umask 02H) counts IMC DRAM channel 1 retries. Again โ€” DRAM retry only occurs when configured in RAS mode.
  • IMC_RETRY.CH2 โ€” (Event 32H, Umask 04H) counts IMC DRAM channel 2 retries. And yes: DRAM retry only occurs when configured in RAS mode.
  • IMC_RETRY.ANY โ€” (Event 32H, Umask 07H) counts IMC DRAM retries from any channel. DRAM retry only occurs when configured in RAS mode โ€” that part is not optional, bestie ๐Ÿ˜ญ

QHL messaging stuff ๐Ÿ“จ

  • QHL_FRC_ACK_CNFLTS.IOH โ€” (Event 33H, Umask 01H) counts the number of Force Acknowledge Conflict messages the Quickpath Home Logic sent to the IOH.
  • QHL_FRC_ACK_CNFLTS.REMOTE โ€” (Event 33H, Umask 02H) counts Force Acknowledge Conflict messages sent by the Quickpath Home Logic to the remote home ๐ŸŒˆ
  • QHL_FRC_ACK_CNFLTS.LOCAL โ€” (Event 33H, Umask 04H) counts Force Acknowledge Conflict messages sent by the Quickpath Home Logic to the local home.
  • QHL_FRC_ACK_CNFLTS.ANY โ€” (Event 33H, Umask 07H) counts all the Force Acknowledge Conflict messages sent by the Quickpath Home Logic, no destination filter ๐Ÿ’–

when requests go to sleep ๐Ÿ’ค

  • QHL_SLEEPS.IOH_ORDER โ€” (Event 34H, Umask 01H) counts how many times a request got put to sleep because of IOH ordering (write after read) conflicts. While it's in the sleep state, the request is not eligible to be scheduled to the QMC. nap time, no scheduling ๐Ÿ™ˆ
  • QHL_SLEEPS.REMOTE_ORDER โ€” (Event 34H, Umask 02H) counts occurrences of a request being put to sleep due to remote socket ordering (write after read) conflicts. While in the sleep state, it can't be scheduled to the QMC.
  • QHL_SLEEPS.LOCAL_ORDER โ€” (Event 34H, Umask 04H) counts occurrences of a request put to sleep due to local socket ordering (write after read) conflicts. Same deal โ€” while asleep, not eligible for scheduling to the QMC.
  • QHL_SLEEPS.IOH_CONFLICT โ€” (Event 34H, Umask 08H) counts occurrences of a request put to sleep due to IOH address conflicts. While in the sleep state, the request is not eligible to be scheduled to the QMC ๐Ÿซถ
  • QHL_SLEEPS.REMOTE_CONFLICT โ€” (Event 34H, Umask 10H) counts occurrences of a request put to sleep due to remote socket address conflicts. While asleep โ€” you guessed it โ€” not eligible to be scheduled to the QMC.
  • QHL_SLEEPS.LOCAL_CONFLICT โ€” (Event 34H, Umask 20H) counts occurrences of a request put to sleep due to local socket address conflicts. While in the sleep state, not eligible to be scheduled to the QMC โœจ

the MSR matching one ๐Ÿงš

  • ADDR_OPCODE_MATCH.IOH โ€” (Event 35H, Umask 01H) counts requests coming from the IOH where the address/opcode of the request is qualified by the mask value written to MSR 396H. These are the supported mask values:
0:                      NONE
40000000_00000000H:     RSPFWDI
40001A00_00000000H:     RSPFWDS
40001D00_00000000H:     RSPIWB

Match opcode/address by writing MSR 396H with a supported mask value. That's the vibe check for this one, fr fr ๐Ÿ’œ

  • ADDR_OPCODE_MATCH.REMOTE โ€” (Event 35H, Umask 02H) counts the number of requests coming in from the remote socket โœจ and the address/opcode of each request is qualified by whatever mask value you wrote to MSR 396H. Bestie, these are the mask values that are supported:
    • 0: NONE
    • 40000000_00000000H:RSPFWDI
    • 40001A00_00000000H:RSPFWDS
    • 40001D00_00000000H:RSPIWB

To match on opcode/address you literally just write MSR 396H with one of those supported mask values and you're so set ๐Ÿ’…

  • ADDR_OPCODE_MATCH.LOCAL โ€” (Event 35H, Umask 04H) counts the number of requests from the local socket, and same deal, the address/opcode of the request is qualified by the mask value you wrote to MSR 396H. Supported mask values, no cap:
    • 0: NONE
    • 40000000_00000000H:RSPFWDI
    • 40001A00_00000000H:RSPFWDS
    • 40001D00_00000000H:RSPIWB

Match opcode/address by writing MSR 396H with a supported mask value. That's the whole vibe ๐Ÿฆ‹

  • QPI_TX_STALLED_SINGLE_FLIT.HOME.LINK_0 โ€” (Event 40H, Umask 01H) counts the cycles where the Quickpath outbound link 0 HOME virtual channel is stalled because it's lacking a VNA and VN0 credit ๐Ÿ˜ญ Heads up though: this event does not filter out the case where a flit wouldn't have been picked for arbitration anyway, on account of another virtual channel getting arbitrated. It just counts stalls, periodt.
  • QPI_TX_STALLED_SINGLE_FLIT.SNOOP.LINK_0 โ€” (Event 40H, Umask 02H) counts cycles the Quickpath outbound link 0 SNOOP virtual channel sits there stalled due to lack of a VNA and VN0 credit. Same caveat, queen: it won't filter out the situation where a flit wouldn't even have been selected for arbitration because some other virtual channel is the one getting arbitrated ๐Ÿ’€
  • QPI_TX_STALLED_SINGLE_FLIT.NDR.LINK_0 โ€” (Event 40H, Umask 04H) counts cycles the Quickpath outbound link 0 non-data response virtual channel is stalled, lacking a VNA and VN0 credit. And again โ€” this event does not filter out when a flit would not have been selected for arbitration because another virtual channel is getting arbitrated ๐Ÿ™ˆ
  • QPI_TX_STALLED_SINGLE_FLIT.HOME.LINK_1 โ€” (Event 40H, Umask 08H) counts cycles the Quickpath outbound link 1 HOME virtual channel is stalled due to lack of a VNA and VN0 credit. Caveat carried over like a good bestie: no filtering of the "flit wouldn't have been selected for arbitration because another virtual channel is getting arbitrated" case ๐ŸŒธ
  • QPI_TX_STALLED_SINGLE_FLIT.SNOOP.LINK_1 โ€” (Event 40H, Umask 10H) counts cycles the Quickpath outbound link 1 SNOOP virtual channel is stalled due to lack of a VNA and VN0 credit. Note (and like, actually note it ๐Ÿ“): this event does not filter out when a flit would not have been selected for arbitration because another virtual channel is getting arbitrated.
  • QPI_TX_STALLED_SINGLE_FLIT.NDR.LINK_1 โ€” (Event 40H, Umask 20H) counts cycles the Quickpath outbound link 1 non-data response virtual channel is stalled due to lack of a VNA and VN0 credit. Doesn't filter out the case where a flit wouldn't have been selected for arbitration because another virtual channel is getting arbitrated โ€” iconic, consistent, same energy every time ๐Ÿ’œ
  • QPI_TX_STALLED_SINGLE_FLIT.LINK_0 โ€” (Event 40H, Umask 07H) counts cycles the Quickpath outbound link 0 virtual channels (plural, all up in there) are stalled due to lack of a VNA and VN0 credit. And yes, the same non-filtering note applies: it won't filter out when a flit would not have been selected for arbitration because another virtual channel is getting arbitrated โญ
  • QPI_TX_STALLED_SINGLE_FLIT.LINK_1 โ€” (Event 40H, Umask 38H) counts cycles the Quickpath outbound link 1 virtual channels are stalled due to lack of a VNA and VN0 credit. Note that this event does not filter out when a flit would not have been selected for arbitration because another virtual channel is getting arbitrated, iykyk ๐Ÿงš

  • QPI_TX_STALLED_MULTI_FLIT.DRS.LINK_0 โ€” (Event 41H, Umask 01H) counts cycles the Quickpath outbound link 0 Data ResponSe virtual channel is stalled due to lack of VNA and VN0 credits (multi-flit era, we love to see it ๐Ÿ”ฅ). Standard disclaimer applies: this event does not filter out when a flit would not have been selected for arbitration because another virtual channel is getting arbitrated.
  • QPI_TX_STALLED_MULTI_FLIT.NCB.LINK_0 โ€” (Event 41H, Umask 02H) counts cycles the Quickpath outbound link 0 Non-Coherent Bypass virtual channel is stalled due to lack of VNA and VN0 credits. And no, it doesn't filter out the "flit wouldn't have been selected for arbitration because another virtual channel is getting arbitrated" scenario โ€” same rule, every single time ๐Ÿ’…
  • QPI_TX_STALLED_MULTI_FLIT.NCS.LINK_0 โ€” (Event 41H, Umask 04H) counts cycles the Quickpath outbound link 0 Non-Coherent Standard virtual channel is stalled due to lack of VNA and VN0 credits. Caveat incoming ๐ŸŽ€: this event does not filter out when a flit would not have been selected for arbitration because another virtual channel is getting arbitrated.
  • QPI_TX_STALLED_MULTI_FLIT.DRS.LINK_1 โ€” (Event 41H, Umask 08H) counts cycles the Quickpath outbound link 1 Data ResponSe virtual channel is stalled due to lack of VNA and VN0 credits. Does not filter out the flit-wouldn't-have-been-selected-for-arbitration case caused by another virtual channel getting arbitrated โ€” say it with me now ๐Ÿซถ
  • QPI_TX_STALLED_MULTI_FLIT.NCB.LINK_1 โ€” (Event 41H, Umask 10H) counts cycles the Quickpath outbound link 1 Non-Coherent Bypass virtual channel is stalled due to lack of VNA and VN0 credits. Note that it does not filter out when a flit would not have been selected for arbitration because another virtual channel is getting arbitrated ๐ŸŒˆ
  • QPI_TX_STALLED_MULTI_FLIT.NCS.LINK_1 โ€” (Event 41H, Umask 20H) counts cycles the Quickpath outbound link 1 Non-Coherent Standard virtual channel is stalled due to lack of VNA and VN0 credits. Same note, bestie: no filtering of the case where a flit wouldn't have been selected for arbitration because another virtual channel is getting arbitrated ๐Ÿ‘‘
  • QPI_TX_STALLED_MULTI_FLIT.LINK_0 โ€” (Event 41H, Umask 07H) counts cycles the Quickpath outbound link 0 virtual channels are stalled due to lack of VNA and VN0 credits. Note that this event does not filter out when a flit would not have been selected for arbitration because another virtual channel is getting arbitrated ๐Ÿ’–
  • QPI_TX_STALLED_MULTI_FLIT.LINK_1 โ€” (Event 41H, Umask 38H) counts cycles the Quickpath outbound link 1 virtual channels are stalled due to lack of VNA and VN0 credits. And, one more time for the people in the back ๐Ÿ“ฃ: it does not filter out when a flit would not have been selected for arbitration because another virtual channel is getting arbitrated.

  • QPI_TX_HEADER.FULL.LINK_0 โ€” (Event 42H, Umask 01H) the number of cycles that the header buffer in the Quickpath Interface outbound link 0 is full ๐Ÿซ 
  • QPI_TX_HEADER.BUSY.LINK_0 โ€” (Event 42H, Umask 02H) the number of cycles that the header buffer in the Quickpath Interface outbound link 0 is busy ๐Ÿ˜ฎโ€๐Ÿ’จ
  • QPI_TX_HEADER.FULL.LINK_1 โ€” (Event 42H, Umask 04H) the number of cycles that the header buffer in the Quickpath Interface outbound link 1 is full ๐Ÿ˜ญ
  • QPI_TX_HEADER.BUSY.LINK_1 โ€” (Event 42H, Umask 08H) the number of cycles that the header buffer in the Quickpath Interface outbound link 1 is busy ๐ŸŒธ

  • QPI_RX_NO_PPT_CREDIT.STALLS.LINK_0 โ€” (Event 43H, Umask 01H) the number of cycles that snoop packets coming into the Quickpath Interface link 0 are stalled and not sent to the GQ, because the GQ Peer Probe Tracker (PPT) has zero available entries ๐Ÿ™…โ€โ™€๏ธ
  • QPI_RX_NO_PPT_CREDIT.STALLS.LINK_1 โ€” (Event 43H, Umask 02H) the number of cycles that snoop packets incoming to the Quickpath Interface link 1 are stalled and not sent to the GQ, on account of the GQ Peer Probe Tracker (PPT) having no available entries ๐Ÿ’€

  • DRAM_OPEN.CH0 โ€” (Event 60H, Umask 01H) counts the number of DRAM Channel 0 open commands issued, whether for read or for write. Quick reminder of the lore ๐Ÿง : to read or write data, the referenced DRAM page must first be opened.
  • DRAM_OPEN.CH1 โ€” (Event 60H, Umask 02H) counts the number of DRAM Channel 1 open commands issued either for read or write. Same lore applies โ€” that referenced DRAM page has to get opened first before any reading or writing happens โญ
  • DRAM_OPEN.CH2 โ€” (Event 60H, Umask 04H) counts the number of DRAM Channel 2 open commands issued either for read or write. And yep, to read or write data, the referenced DRAM page must first be opened ๐Ÿ’…
  • DRAM_PAGE_CLOSE.CH0 โ€” (Event 61H, Umask 01H) DRAM channel 0 command issued to CLOSE a page because the page idle timer expired. Closing a page is done by issuing a precharge ๐Ÿ”’
  • DRAM_PAGE_CLOSE.CH1 โ€” (Event 61H, Umask 02H) DRAM channel 1 command issued to CLOSE a page due to page idle timer expiration. The closing itself? Done by issuing a precharge ๐Ÿ’…
  • DRAM_PAGE_CLOSE.CH2 โ€” (Event 61H, Umask 04H) DRAM channel 2 command issued to CLOSE a page due to page idle timer expiration, and closing a page is done by issuing a precharge ๐ŸŽ€
  • DRAM_PAGE_MISS.CH0 โ€” (Event 62H, Umask 01H) counts the number of precharges (PRE) issued to DRAM channel 0 because there was a page miss. So like โ€” what even is a page miss? It's when a page is currently open and another page from the same bank needs to be opened, and that new page experiences the page miss ๐Ÿ˜ตโ€๐Ÿ’ซ The old page gets closed by issuing a precharge.
  • DRAM_PAGE_MISS.CH1 โ€” (Event 62H, Umask 02H) counts the number of precharges (PRE) issued to DRAM channel 1 because of a page miss. A page miss is the situation where a page is currently open and another page from the same bank needs to be opened โ€” the new page is the one experiencing the miss. Closing the old page is done by issuing a precharge ๐Ÿ™ˆ
  • DRAM_PAGE_MISS.CH2 โ€” (Event 62H, Umask 04H) counts the number of precharges (PRE) issued to DRAM channel 2 because there was a page miss. Page miss = a page is currently open and another page from the same bank needs to be opened, so the new page experiences a page miss. Closing of the old page is done by issuing a precharge, no cap ๐Ÿฆ‹
  • DRAM_READ_CAS.CH0 โ€” (Event 63H, Umask 01H) counts the number of times a read CAS command was issued on DRAM channel 0 ๐Ÿ”ฅ
  • DRAM_READ_CAS.AUTOPRE_CH0 โ€” (Event 63H, Umask 02H) Counts every time a read CAS command got issued on DRAM channel 0 and that command used auto-precharge mode (aka auto page close). ๐Ÿ’…
  • DRAM_READ_CAS.CH1 โ€” (Event 63H, Umask 04H) Counts every time a read CAS command got issued on DRAM channel 1. That's it, that's the whole vibe.
  • DRAM_READ_CAS.AUTOPRE_CH1 โ€” (Event 63H, Umask 08H) Counts every time a read CAS command got issued on DRAM channel 1 where the command used the auto-precharge (auto page close) mode. ๐ŸŽ€
  • DRAM_READ_CAS.CH2 โ€” (Event 63H, Umask 10H) Counts every time a read CAS command got issued on DRAM channel 2.
  • DRAM_READ_CAS.AUTOPRE_CH2 โ€” (Event 63H, Umask 20H) Counts every time a read CAS command got issued on DRAM channel 2 where the command used the auto-precharge (auto page close) mode. โœจ
  • DRAM_WRITE_CAS.CH0 โ€” (Event 64H, Umask 01H) Counts every time a write CAS command got issued on DRAM channel 0.
  • DRAM_WRITE_CAS.AUTOPRE_CH0 โ€” (Event 64H, Umask 02H) Counts every time a write CAS command got issued on DRAM channel 0 where the command used the auto-precharge (auto page close) mode.
  • DRAM_WRITE_CAS.CH1 โ€” (Event 64H, Umask 04H) Counts every time a write CAS command got issued on DRAM channel 1.
  • DRAM_WRITE_CAS.AUTOPRE_CH1 โ€” (Event 64H, Umask 08H) Counts every time a write CAS command got issued on DRAM channel 1 where the command used the auto-precharge (auto page close) mode. ๐Ÿฆ‹
  • DRAM_WRITE_CAS.CH2 โ€” (Event 64H, Umask 10H) Counts every time a write CAS command got issued on DRAM channel 2.
  • DRAM_WRITE_CAS.AUTOPRE_CH2 โ€” (Event 64H, Umask 20H) Counts every time a write CAS command got issued on DRAM channel 2 where the command used the auto-precharge (auto page close) mode.

  • DRAM_REFRESH.CH0 โ€” (Event 65H, Umask 01H) Counts the number of DRAM channel 0 refresh commands. Bestie, real talk: DRAM loses its data content over time ๐Ÿ˜ญ โ€” to keep the data content correct, the data values have to be refreshed periodically. Iconic little memory-maintenance ritual.
  • DRAM_REFRESH.CH1 โ€” (Event 65H, Umask 02H) Counts the number of DRAM channel 1 refresh commands. Same deal: DRAM loses data content over time, and to keep correct data content the data values have to be refreshed periodically. ๐Ÿซถ
  • DRAM_REFRESH.CH2 โ€” (Event 65H, Umask 04H) Counts the number of DRAM channel 2 refresh commands. And yeah โ€” DRAM loses data content over time, so to keep correct data content the data values have to be refreshed periodically. Periodt. ๐Ÿ’–

  • DRAM_PRE_ALL.CH0 โ€” (Event 66H, Umask 01H) Counts the number of DRAM Channel 0 precharge-all (PREALL) commands, which close all open pages in a rank. PREALL gets issued when the DRAM needs to be refreshed or needs to go into a power down mode. Closing time, everyone out ๐ŸŒธ
  • DRAM_PRE_ALL.CH1 โ€” (Event 66H, Umask 02H) Counts the number of DRAM Channel 1 precharge-all (PREALL) commands that close all open pages in a rank. PREALL is issued when the DRAM needs to be refreshed or needs to go into a power down mode.
  • DRAM_PRE_ALL.CH2 โ€” (Event 66H, Umask 04H) Counts the number of DRAM Channel 2 precharge-all (PREALL) commands that close all open pages in a rank. PREALL is issued when the DRAM needs to be refreshed or needs to go into a power down mode. ๐Ÿ’œ

  • DRAM_THERMAL_THROTTLED โ€” (Event 67H, Umask 01H) Uncore cycles DRAM was throttled because its temperature was above the thermal throttling threshold. She's hot, she's slowing down, she's doing her best ๐Ÿ”ฅ
  • THERMAL_THROTTLING_TEMP.CORE_0 โ€” (Event 80H, Umask 01H) Cycles that the PCU records that core 0 is above the thermal throttling threshold temperature.
  • THERMAL_THROTTLING_TEMP.CORE_1 โ€” (Event 80H, Umask 02H) Cycles that the PCU records that core 1 is above the thermal throttling threshold temperature.
  • THERMAL_THROTTLING_TEMP.CORE_2 โ€” (Event 80H, Umask 04H) Cycles that the PCU records that core 2 is above the thermal throttling threshold temperature.
  • THERMAL_THROTTLING_TEMP.CORE_3 โ€” (Event 80H, Umask 08H) Cycles that the PCU records that core 3 is above the thermal throttling threshold temperature. ๐Ÿฅต
  • THERMAL_THROTTLED_TEMP.CORE_0 โ€” (Event 81H, Umask 01H) Cycles that the PCU records that core 0 is in the power throttled state due to the core's temperature being above the thermal throttling threshold.
  • THERMAL_THROTTLED_TEMP.CORE_1 โ€” (Event 81H, Umask 02H) Cycles that the PCU records that core 1 is in the power throttled state due to the core's temperature being above the thermal throttling threshold.
  • THERMAL_THROTTLED_TEMP.CORE_2 โ€” (Event 81H, Umask 04H) Cycles that the PCU records that core 2 is in the power throttled state due to the core's temperature being above the thermal throttling threshold.
  • THERMAL_THROTTLED_TEMP.CORE_3 โ€” (Event 81H, Umask 08H) Cycles that the PCU records that core 3 is in the power throttled state due to the core's temperature being above the thermal throttling threshold. ๐ŸŒก๏ธ
  • PROCHOT_ASSERTION โ€” (Event 82H, Umask 01H) Number of system assertions of PROCHOT, indicating the entire processor has exceeded the thermal limit. The whole chip, not just one core. Main character emergency ๐Ÿšจ
  • THERMAL_THROTTLING_PROCHOT.CORE_0 โ€” (Event 83H, Umask 01H) Cycles that the PCU records that core 0 is in a low power state due to the system asserting PROCHOT โ€” the entire processor has exceeded the thermal limit.
  • THERMAL_THROTTLING_PROCHOT.CORE_1 โ€” (Event 83H, Umask 02H) Cycles that the PCU records that core 1 is in a low power state due to the system asserting PROCHOT โ€” the entire processor has exceeded the thermal limit.
  • THERMAL_THROTTLING_PROCHOT.CORE_2 โ€” (Event 83H, Umask 04H) Cycles that the PCU records that core 2 is in a low power state due to the system asserting PROCHOT โ€” the entire processor has exceeded the thermal limit.
  • THERMAL_THROTTLING_PROCHOT.CORE_3 โ€” (Event 83H, Umask 08H) Cycles that the PCU records that core 3 is in a low power state due to the system asserting PROCHOT โ€” the entire processor has exceeded the thermal limit. ๐Ÿ˜ฎโ€๐Ÿ’จ

  • TURBO_MODE.CORE_0 โ€” (Event 84H, Umask 01H) Uncore cycles that core 0 is operating in turbo mode. Zoom zoom โœจ
  • TURBO_MODE.CORE_1 โ€” (Event 84H, Umask 02H) Uncore cycles that core 1 is operating in turbo mode.
  • TURBO_MODE.CORE_2 โ€” (Event 84H, Umask 04H) Uncore cycles that core 2 is operating in turbo mode.
  • TURBO_MODE.CORE_3 โ€” (Event 84H, Umask 08H) Uncore cycles that core 3 is operating in turbo mode. ๐ŸŽ๏ธ
  • CYCLES_UNHALTED_L3_FLL_ENABLE โ€” (Event 85H, Umask 02H) Uncore cycles that at least one core is unhalted and all L3 ways are enabled. Fully fed, fully on ๐Ÿ‘‘
  • CYCLES_UNHALTED_L3_FLL_DISABLE โ€” (Event 86H, Umask 01H) Uncore cycles that at least one core is unhalted and all L3 ways are disabled. Yeahโ€ฆ that's the other one ๐Ÿ’€

๐ŸŒˆ SEE ALSO

Like, go read your other besties too, they're all connected:

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.westmere(3), pmc_cpuinfo(3), pmclog(3), hwpmc(4)


๐ŸŒธ HISTORY

The pmc library first appeared in FreeBSD 6.0. Vintage, but make it cute ๐ŸŽ€


๐Ÿ’– AUTHORS

The Performance Counters Library (libpmc, -lpmc) library was written by Joseph Koshy <jkoshy@FreeBSD.org>. Shoutout to the icon who built it ๐Ÿซถ


Ok that's the whole page bestie, you made it to the end! ๐Ÿฆ‹ This one's from the Debian source, dated March 24, 2010, and it lives at PMC.WESTMEREUC(3). Go forth and count those uncore events, no cap ๐Ÿ’…โœจ
๐Ÿ“ฆ 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