LIBPFM(3)

πŸ’– LIBPFM(3) β€” the girlies' guide to libpfm_intel_adl_glc πŸ’–

okay so welcome to the Linux Programmer's Manual bestie, we're talking about libpfm_intel_adl_glc β€” support for the Intel Alderlake Goldencove (P-Core) core PMU. this is the manual page for libpfm, and she's iconic, no cap. πŸŽ€


✨ NAME ✨

libpfm_intel_adl_glc β€” support for Intel Alderlake Goldencove (P-Core) core PMU

like that's literally her whole thing πŸ’…


🌸 SYNOPSIS 🌸

#include <perfmon/pfmlib.h>
  • PMU name: adl_glc
  • PMU desc: Intel Alderlake Goldencove (P-core)

πŸ¦‹ DESCRIPTION πŸ¦‹

so the library supports the Intel Alderlake Goldencove (P-Core) core PMU. but lowkey important: this PMU model only covers each core's PMU and not the socket level PMU. like, core-level only, she's not doing the whole socket, periodt.

and because this processor is out here living that hybrid architecture life with a P-Core and an E-Core that have a different PMU model, you may need to force a PMU instance name to get the encoding you actually want. it's giving "pick a lane, bestie". for instance:

  • encode for the P-Core: adl_glc::BR_INST_RETIRED
  • encode for the E-core: adl_grt::BR_INST_RETIRED

ngl this distinction matters so much, iykyk.

on Adlerlake Goldencove (P-Core), the number of generic counters depends on the Hyperthreading (HT) mode. yes, HT changes the counter count, she's flexible like that ✨

the pfm_get_pmu_info() function returns the maximum number of generic counters in num_cntrs.


πŸ’… MODIFIERS πŸ’…

the following modifiers are supported on Intel SapphireRapid processors:

  • u β€” measure at user level, which includes privilege levels 1, 2, 3. this corresponds to PFM_PLM3. this is a boolean modifier.
  • k β€” measure at kernel level, which includes privilege level 0. this corresponds to PFM_PLM0. this is a boolean modifier.
  • i β€” invert the meaning of the event. the counter will now count cycles in which the event is not occurring. this is a boolean modifier.
  • 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 counter mask modifier (m) with a value greater or equal to one. this is a boolean modifier.
  • c β€” set the counter mask value. the mask acts as a threshold. the counter will count the number of 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].
  • intx β€” monitor the event only when executing inside a transactional memory region (in tx). event does not count otherwise. this is a boolean modifiers. default value is 0.
  • intxcp β€” do not count occurrences of the event when they are inside an aborted transactional memory region. this is a boolean modifier. default value is 0.
  • ldlat β€” pass a latency threshold in core cycles to the MEM_TRANS_RETIRED:LOAD_LATENCY event. this is an integer attribute that must be in the range [1:65535]. it is required for this event. the library provides a set of presets for specific latencies, such as 128. note that the event must be used with precise sampling (PEBS).

πŸ”₯ FRONTEND_RETIRED event πŸ”₯

for Alderlake Goldencove (P-Core), the library uses the hardcoded bubble width and bubble length provided by Intel preset events. it is not possible to tweak either the latency or the width via the library. sorry bestie, those knobs are not yours to turn πŸ™ˆ


πŸ‘‘ OFFCORE_RESPONSE events πŸ‘‘

Intel Alderlake Goldencove (P-Core) supports two encodings for offcore_response events (0x2a, 0x2b). in the library, these are called OCR0 and OCR1. the two encodings are equivalent.

on Linux, the kernel can schedule any OCR encoding into any of the two OCR counters. the offcore_response events are exposed as a normal events by the library. the extra settings are exposed as regular umasks. the library takes care of encoding the events according to the underlying kernel interface. she handles it, don't worry 🫢

on Intel Alderlake Goldencove (P-Core), the event is treated as a regular event with a flat set of umasks to choose from. it is not possible to combine the various requests, supplier, snoop bits anymore. the library offers the list of validated combinations as per Intel's official event list.

no cap: the combining era is over on this one. flat umasks only, bestie. πŸŽ€

🌈 AUTHORS 🌈

Stephane Eranian <eranian@gmail.com>


and that's the whole page, mwah πŸ’‹ this was LIBPFM(3) from the Linux Programmer's Manual, dated February, 2024 β€” version LIBPFM(3), slay, go read your counters and stay hydrated πŸ“πŸ§šπŸ’œ