LIBPFM(3)

πŸ’– LIBPFM(3) β€” Linux Programmer's Manual πŸ’–

okay bestie, so this page is libpfm_intel_ivbep_unc_cbo, straight out of the Linux Programmer's Manual, and it's literally just the lore on how libpfm handles one very specific little guy. sit down, hydrate, let's go 🫢


✨ NAME ✨

libpfm_intel_ivbep_unc_cbo β€” support for Intel Ivy Bridge-EP C-Box uncore PMU

like. that's the whole name. it does what it says on the tin, no cap πŸ’…


🌸 SYNOPSIS 🌸

#include <perfmon/pfmlib.h>

PMU name: ivbep_unc_cbo[0-7]

PMU desc: Intel Ivy Bridge-EP C-Box uncore PMU


πŸ¦‹ DESCRIPTION πŸ¦‹

so the library supports the Intel Ivy Bridge C-Box (coherency engine) uncore PMU. iconic of it, honestly.

and listen β€” this PMU model only exists on Ivy Bridge model 62. that's the vibe check. if you're not on model 62, this whole page is not for you, sorry babe 😭

here's the layout: there is one C-box PMU per physical core. so that means there are up to fifteen identical C-Box PMU instances, numbered from 0 to 14. fifteen. not sixteen. don't come for me, that's just what it says πŸ’€

and here's the spicy part β€” on dual-socket systems, the number refers to the C-Box PMU on the socket where the program runs. so like:

  • if you're running on CPU15, then ivbep_unc_cbo0 refers to the C-Box for physical core 0 on socket 1.
  • conversely, if you're running on CPU0, then that same ivbep_unc_cbo0 refers to the C-Box for physical core 0 but on socket 0.

same name, different socket, depending on where you're standing. it's giving multiverse. it's giving "who am I when I'm not perceived." periodt ✨

also: each C-Box PMU implements 4 generic counters and two filter registers that are used only with certain events and umasks. only certain ones. don't get cute with them πŸ™ˆ


πŸ’… MODIFIERS πŸ’…

okay these are the modifiers supported on the Intel Ivy Bridge C-Box uncore PMU. bestie, these are your knobs. turn them responsibly:

  • e β€” Enable edge detection, i.e., count only when there is a state transition from no occurrence of the event to at least one occurrence. This modifier must be combined with a threshold modifier (t) with a value greater or equal to one. This is a boolean modifier.
  • t β€” Set the threshold value. When set to a non-zero value, the counter counts the number of C-Box cycles in which the number of occurrences of the event is greater or equal to the threshold. This is an integer modifier with values in the range [0:255].
  • nf β€” Node filter. Certain events, such as UNC_C_LLC_LOOKUP, UNC_C_LLC_VICTIMS, provide a NID umask. Sometimes the NID is combined with other filtering capabilities, such as opcodes. The node filter is an 8-bit max bitmask. A node corresponds to a processor socket. The legal values therefore depend on the underlying hardware configuration. For dual-socket systems, the bitmask has two valid bits [0:1].
  • cf β€” Core Filter. This is a 3-bit filter which is used to filter based on physical core origin of the C-Box request. Possible values are 0-7. If the filter is not specified, then no filtering takes place.
  • tf β€” Thread Filter. This is a 1-bit filter which is used to filter C-Box requests based on logical processor (hyper-thread) identification. Possibles values are 0-1. If the filter is not specified, then no filtering takes place.
  • nc β€” Non-Coherent. This is a 1-bit filter which is used to filter C-Box requests only for the TOR_INSERTS and TOR_OCCUPANCY umasks using the OPCODE matcher. If the filter is not specified, then no filtering takes place.
  • isoc β€” Isochronous. This is a 1-bit filter which is used to filter C-Box requests only for the TOR_INSERTS and TOR_OCCUPANCY umasks using the OPCODE matcher. If the filter is not specified, then no filtering takes place.
note that nc and isoc are twinsies fr fr β€” same rules, same two umasks, same "no filter = no filtering" energy. read them carefully, bestie, don't mix them up πŸ’–

πŸŽ€ Opcode filtering πŸŽ€

certain events, such as UNC_C_TOR_INSERTS, support opcode matching on the C-BOX transaction type. to use this feature, it's a two-step thing:

  1. first, an opcode matching umask must be selected, e.g., MISS_OPCODE.
  2. second, the opcode to match on must be selected via a second umask among the OPC_* umasks.

for instance, UNC_C_TOR_INSERTS:OPCODE:OPC_RFO, counts the number of TOR insertions for RFO transactions. slay ✨

opcode matching may be combined with node filtering with certain umasks. in general, the filtering support is encoded into the umask name, e.g., NID_OPCODE supports both node and opcode filtering. for instance:

UNC_C_TOR_INSERTS:NID_OPCODE:OPC_RFO:nf=1

see? the umask name is literally telling you what filters it's packing. iykyk πŸ”₯


πŸ‘‘ AUTHORS πŸ‘‘

Stephane Eranian <eranian@gmail.com>


and that's the whole page, bestie!! LIBPFM(3), February, 2014 β€” yeah she's a little vintage but she ate and left no crumbs πŸ’œπŸ¦‹ mwah, go count some C-Box cycles, you got this πŸŽ€

πŸ“¦ where this page comes from