LIBPFM(3)

✨ LIBPFM(3) ✨ — the Linux Programmer's Manual one, bestie

okay so picture this: it's a libpfm man page, it lives in section 3 of the Linux Programmer's Manual, and today's episode is all about Intel Tremont. sit down, grab a strawberry 🍓, we're doing this.

🌸 NAME 🌸

libpfm_intel_tmt — support for Intel Tremont core PMU

like, that's the whole vibe. the library does Tremont. iconic behavior honestly 👑

🎀 SYNOPSIS 🎀

first things first, you gotta pull in the header:

#include <perfmon/pfmlib.h>

and here's the tea you actually need:

• PMU name: tmt
• PMU desc: Intel Tremont

no cap, those two strings are the whole synopsis situation. remember them, you'll be typing tmt a lot 🦋

💖 DESCRIPTION 💖

the library supports the Intel Tremont core PMU. that's it. that's the sentence. short, sweet, ate 💅

✨ MODIFIERS ✨

so on Intel Tremont processors you've got these little modifier besties you can sprinkle onto your events. here's the full roster, no skips, no cuts:

• u — measure at user level, which includes privilege levels 1, 2, and 3. this one corresponds to PFM_PLM3. it's a boolean modifier, so it's just on or off, no in-between 💜
• k — measure at kernel level, which includes privilege level 0. this corresponds to PFM_PLM0. also a boolean modifier, also just vibes 🫶
• i — invert the meaning of the event. the counter will now count cycles in which the event is not occurring. yes bestie, it's the "count the opposite" button. 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. real talk: this modifier must be combined with a counter mask modifier (m) with a value greater or equal to one. also 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 one is an integer modifier with values in the range [0:255]. so like, not a yes/no girlie, she's got range 🌈

🔥 OFFCORE_RESPONSE events 🔥

this is the spicy section, pay attention 👀

Intel Tremont provides two offcore_response events: OFFCORE_RESPONSE_0 and OFFCORE_RESPONSE_1. and plot twist — the OCR event is aliased to OFFCORE_RESPONSE_0. so when you say OCR, you mean OFFCORE_RESPONSE_0, periodt.

those events need special treatment in the performance monitoring infrastructure, because each event uses an extra register to store some settings. so if multiple offcore_response events are being monitored simultaneously, the kernel has to manage the sharing of that extra register. the kernel is out here doing group project coordination so you don't have to 😭

the offcore_response event is exposed as a normal event by the library. the extra settings are exposed as regular umasks. the library takes care of encoding the events according for the underlying kernel interface — that's a direct quote from the original energy, keep it, it's canon.

and now the important part, the part where you don't freestyle:

On Intel Tremont, it is not possible to combine the request, supplier, snoop, fields anymore to avoid invalid combinations. as such, the umasks provided by the library are the only ones supported and validated. so please bestie, use the library's umasks, don't go inventing your own combos, it will not slay 💀

👑 AUTHORS 👑

• Stephane Eranian <eranian@gmail.com>

that's the whole page, you're officially fluent in libpfm_intel_tmt 🧚

cute sign-off time: this little masterpiece is from March, 2020, and it's filed under LIBPFM(3) — the Linux Programmer's Manual, section 3, exactly where it belongs. bye bestie, go read some counters 💖