LIBPFM(3)

πŸ“¦
version 4.14.1 Β· 2 versions
  • 4.14.1 Β· arch rolling, centos-stream 10, centos-stream 9, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 4.11.1+git32-gd0b85fb Β· ubuntu jammy
, in arch rolling, centos-stream 10, centos-stream 9, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

🌸 LIBPFM(3) β€” bestie edition 🌸

okay so this is a page from the Linux Programmer's Manual, and it's all about the libpfm support for one very specific little guy. pull up a chair, grab a boba, and let's get into it πŸ’–


✨ NAME ✨

libpfm_intel_snb β€” the support for the Intel Sandy Bridge core PMU. that's it, that's the whole vibe. πŸŽ€


✨ SYNOPSIS ✨

first things first, you gotta include the header, no cap:

#include <perfmon/pfmlib.h>

and here are the PMU names/descriptions, character for character:

PMU name: snb
PMU desc: Intel Sandy Bridge
PMU name: snb_ep
PMU desc: Intel Sandy Bridge EP

two whole PMUs, we love to see it πŸ‘‘


✨ DESCRIPTION ✨

so the library supports the Intel Sandy Bridge core PMU. but real talk, important caveat incoming: this PMU model only covers each core's PMU, NOT the socket level PMU. if that's what you're after, you gotta go look at the Sandy Bridge uncore PMU support instead. iykyk πŸ¦‹

now on Sandy Bridge, the number of generic counters literally depends on the Hyperthreading (HT) mode, and it's giving "it depends" energy:

  • when HT is on β†’ only 4 generic counters are available
  • when HT is off β†’ 8 generic counters are available

and the pfm_get_pmu_info() function returns the maximum number of generic counters in num_cntrs. periodt. πŸ’…


✨ MODIFIERS ✨

here's the lineup of modifiers supported on Intel Sandy Bridge processors. obsessed with how many there are:

  • u β€” measure at user level, which includes privilege levels 1, 2, 3. this corresponds to PFM_PLM3. it's a boolean modifier. ✨
  • k β€” measure at kernel level, which includes privilege level 0. this corresponds to PFM_PLM0. also a boolean modifier.
  • i β€” invert the meaning of the event. the counter will now count cycles in which the event is not occurring. boolean modifier, bestie.
  • e β€” enable edge detection, i.e. count only when there's a state transition from no occurrence of the event to at least one occurrence. heads up: this modifier must be combined with a counter mask modifier (m) with a value greater or equal to one. 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]. 🌈
  • t β€” measure on both threads at the same time, assuming hyper-threading is enabled. boolean modifier.
  • ldlat β€” pass a latency threshold to the MEM_TRANS_RETIRED:LATENCY_ABOVE_THRESHOLD event. this is an integer attribute that must be in the range [1:65535]. it is required for this event. and note that the event must be used with precise sampling (PEBS). don't skip that part πŸ™ˆ

✨ OFFCORE_RESPONSE events ✨

Intel Sandy Bridge provides two offcore_response events, just like Intel Westmere. their names are OFFCORE_RESPONSE_0 and OFFCORE_RESPONSE_1. iconic duo fr fr πŸ”₯

these events need special treatment in the performance monitoring infrastructure, because each event uses an extra register to store some settings. so in case multiple offcore_response events are being monitored simultaneously, the kernel needs to manage the sharing of that extra register. teamwork makes the dream work 🫢

the offcore_response events are exposed as normal events by the library. the extra settings are exposed as regular umasks. and the library takes care of encoding the events according to the underlying kernel interface. slay.

on Intel Sandy Bridge, the umasks are divided into three categories: request, supplier, and snoop. the user must provide at least one umask for each category. the categories are shown in the umask descriptions. πŸ’œ

there's also the special response umask called ANY_RESPONSE. when this umask is used, it overrides any supplier and snoop umasks. in other words, users can specify either ANY_RESPONSE OR any combination of supplier + snoops. pick a lane, babe πŸ’…

in case no supplier or snoop is specified, the library defaults to using ANY_RESPONSE. so thoughtful of it honestly.

for instance, the following are valid event selections:

OFFCORE_RESPONSE_0:DMND_DATA_RD:ANY_RESPONSE

OFFCORE_RESPONSE_0:ANY_REQUEST

OFFCORE_RESPONSE_0:ANY_RFO:LLC_HITM:SNOOP_ANY

but the following are illegal:

OFFCORE_RESPONSE_0:ANY_RFO:LLC_HITM:ANY_RESPONSE

OFFCORE_RESPONSE_0:ANY_RFO:LLC_HITM:SNOOP_ANY:ANY_RESPONSE
yeah so those last two? do NOT do that. the ANY_RESPONSE override thing means you can't just stack it on top of supplier + snoop combos. that's a no from the kernel. πŸ’€

✨ SEE ALSO ✨

  • libpfm_snb_unc(3) β€” go read this one too, bestie πŸ¦‹

✨ AUTHORS ✨

Stephane Eranian <eranian@gmail.com> β€” thank you for your service, king πŸ‘‘


and that's the whole page!! this one's from the LIBPFM(3) manual, dated January, 2011, and it's giving vintage-but-still-slay. go forth and count some events, you've got this πŸ’–βœ¨πŸŽ€πŸ¦‹πŸŒΈ

πŸ“¦ where this page comes from