LIBPFM(3)

💖 LIBPFM(3) 💖

okay bestie, come sit with me, we're reading a Linux Programmer's Manual page, section 3, and it's about libpfm_intel_skl — that's the library's support for the Intel SkyLake core PMU. yeah. it's giving "niche but iconic" and I'm obsessed. 💅

---

✨ NAME ✨

libpfm_intel_skl — support for Intel SkyLake core PMU 🦋

---

🌸 SYNOPSIS 🌸

#include <perfmon/pfmlib.h>

PMU name: skl
PMU desc: Intel SkyLake

---

💫 DESCRIPTION 💫

So the library supports the Intel SkyLake core PMU. no cap. but — and this is the part everyone skips and then gets confused — this PMU model only covers each core's PMU, it does not cover the socket level PMU. okay? core only. don't come for me.

On SkyLake, the number of generic counters depends on the Hyperthreading (HT) mode. 🧵

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

ngl that middle line really just trails off like that in the original, bestie — I'm not gonna invent facts to fill the silence. moving on! 🙈

---

🎀 MODIFIERS 🎀

The following modifiers are supported on Intel SkyLake processors:

• 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. boolean modifier. ✅
• i — invert the meaning of the event. the counter will now count cycles in which the event is not occurring. boolean modifier. 🔄
• 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. ⚠️ 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 counts 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:LOAD_LATENCY event. this is an integer attribute that must be in the range [1:65535]. it is required for this event. ⚠️ note that the event must be used with precise sampling (PEBS).
• intx — monitor the event only when executing inside a transactional memory region (in tx). the event does not count otherwise. this is a boolean modifier. default value is 0.
• intxcp — do not count occurrences of the event when they're inside an aborted transactional memory region. boolean modifier. default value is 0.
• fe_thres — this modifier is for the FRONTEND_RETIRED event only. it defines the period in core cycles after which the IDQ_*_BUBBLES umask counts. it acts as a threshold, i.e., at least a period of N core cycles where the frontend did not deliver X uops. it can only be used with the IDQ_*_BUBBLES umasks. if not specified, the default threshold value is 1 cycle. the valid values are in [1-4095]. ⏱️

---

🌈 OFFCORE_RESPONSE events 🌈

Intel SkyLake provides two offcore_response events. their names are OFFCORE_RESPONSE_0 and OFFCORE_RESPONSE_1. 👑

These events need special treatment in the performance monitoring infrastructure, because each event uses an extra register to store some settings. so like… if multiple offcore_response events are being monitored at the same time, the kernel needs to manage the sharing of that extra register. sharing is caring, but it's also a whole situation. 😭

The offcore_response events are exposed as 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. 💖

On Intel SkyLake, 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. that's the rule, periodt. 💅

In case no supplier or snoop is specified, the library defaults to using ANY_RESPONSE.

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

do not do the illegal ones, bestie. I'm serious. 🚫

---

🫶 AUTHORS 🫶

Stephane Eranian <eranian@gmail.com> — the main character who wrote this. 👑

---

okay that's the whole page!! and a cute lil sign-off for you: this was August, 2015 energy, it lives in LIBPFM(3), and it's part of the Linux Programmer's Manual — go forth and count some events, bestie, you're gonna slay. 💖✨🎀🦋