PMC.ATOMSILVERMONT(3)

📦
version 15.1 · 2 versions
, in freebsd 15.1

💅 PMC.ATOMSILVERMONT(3) — the manual page, but make it make sense

okay so bestie, this is pmc.atomsilvermont from the Library Functions Manual, and it's all about measurement events for Intel Atom Silvermont family CPUs. think of it as the group chat where your CPU finally tells you what it's been up to. it's a libpmc page, we're in section 3, and we are so ready. 🦋

🌸 NAME 🌸

pmc.atomsilvermont — measurement events for Intel Atom Silvermont family CPUs. literally that's the whole vibe of the page. 💖

🎀 LIBRARY 🎀

Performance Counters Library (libpmc, -lpmc). that's the one you link against, no cap. 🔗

✨ SYNOPSIS ✨

#include <pmc.h>

that's it. that's the whole synopsis. iconic behavior honestly. 💅

💜 DESCRIPTION 💜

so, Intel Atom Silvermont CPUs contain PMCs conforming to version 3 of the Intel performance measurement architecture. yes bestie, version 3. we love a numbered era.

these CPUs contain two classes of PMCs, and they are not the same thing:

  • PMC_CLASS_IAF — fixed-function counters that count only one hardware event per counter. one counter, one job. simple. loyal. 🫶
  • PMC_CLASS_IAP — programmable counters that may be configured to count one of a defined set of hardware events. these are the main characters, lowkey. 👑

the number of PMCs available in each class and their widths need to be determined at run time by calling pmc_cpuinfo(3). do not guess, do not assume, do not try to be cute about it. run the function. fr fr. 🧚

also, for the receipts: Intel Atom Silvermont PMCs are documented in “Combined Volumes”, Intel 64 and IA-32 Intel(R) Architecture Software Developer's Manual, Order Number 325462-050US, Intel Corporation, February 2014. that's the source material, keep it in your bookmarks. 📚

🔥 ATOM SILVERMONT FIXED FUNCTION PMCS 🔥

these PMCs and their supported events are documented in pmc.iaf(3). that's it, go read that one, this page isn't gonna hold your hand on the fixed-function side. 🫡

🌈 ATOM SILVERMONT PROGRAMMABLE PMCS 🌈

the programmable PMCs support the following capabilities — and yes, some of them are a hard no, and we respect the honesty:

  • PMC_CAP_CASCADE — No 💀
  • PMC_CAP_EDGE — Yes ✨
  • PMC_CAP_INTERRUPT — Yes 🔔
  • PMC_CAP_INVERT — Yes 🔄
  • PMC_CAP_READ — Yes 📖
  • PMC_CAP_PRECISE — No 😭
  • PMC_CAP_SYSTEM — Yes 🛡️
  • PMC_CAP_TAGGING — No 🙈
  • PMC_CAP_THRESHOLD — Yes 📏
  • PMC_CAP_USER — Yes 🙋‍♀️
  • PMC_CAP_WRITE — Yes ✍️

🦋 Event Qualifiers 🦋

event specifiers for these PMCs support the following common qualifiers. read them, memorize them, sprinkle them like glitter:

  • any — count matching events seen on any logical processor in a package. 🎁
  • cmask=value — configure the PMC to increment only if the number of configured events measured in a cycle is greater than or equal to value.
  • edge — configure the PMC to count the number of de-asserted to asserted transitions of the conditions expressed by the other qualifiers. if specified, the counter will increment only once whenever a condition becomes true, irrespective of the number of clocks during which the condition remains true. one and done. ⚡
  • inv — invert the sense of comparison when the cmask qualifier is present, making the counter increment when the number of events per cycle is less than the value specified by the cmask qualifier. flip it and reverse it. 🔃
  • os — configure the PMC to count events happening at processor privilege level 0. very kernel of it. 🧠
  • usr — configure the PMC to count events occurring at privilege levels 1, 2 or 3. userland girlies rise. 🙋
if neither the os nor the usr qualifiers are specified, the default is to enable both. so like, you get both unless you pick. generous. 💖

🧚 core-specificity qualifier

events that require core-specificity to be specified use an additional qualifier core=core, where the argument core is one of:

  • all — measure event conditions on all cores. every single one. 👯
  • this — measure event conditions on this core. just us. 🫶

the default is this.

🐝 agent qualifier

events that require an agent qualifier to be specified use an additional qualifier agent=agent, where the argument agent is one of:

  • this — measure events associated with this bus agent.
  • any — measure events caused by any bus agent.

the default is this.

🌸 hardware prefetch qualifier

events that require a hardware prefetch qualifier to be specified use an additional qualifier prefetch=prefetch, where the argument prefetch is one of:

  • both — include all prefetches. 🤲
  • only — only count hardware prefetches. 🎯
  • exclude — exclude hardware prefetches. 🚫

the default is both.

💎 cache coherence qualifier

events that require a cache coherence qualifier to be specified use an additional qualifier cachestate=state, where the argument state contains one or more of the following letters:

  • e — count cache lines in the exclusive state.
  • i — count cache lines in the invalid state.
  • m — count cache lines in the modified state.
  • s — count cache lines in the shared state.

the default is eims. all four letters, all the time. alphabetically unbothered. 🔤

🍓 snoop response qualifier

events that require a snoop response qualifier to be specified use an additional qualifier snoopresponse=response, where the argument response comprises of the following keywords separated by + signs:

  • clean — measure CLEAN responses. 🧼
  • hit — measure HIT responses. 👊
  • hitm — measure HITM responses. 💥

the default is to measure all the above responses.

⭐ snoop type qualifier

events that require a snoop type qualifier use an additional qualifier snooptype=type, where the argument type comprises the one of the following keywords:

  • cmp2i — measure CMP2I snoops.
  • cmp2s — measure CMP2S snoops.

the default is to measure both snoops. equality! we love her. ⚖️

👑 Event Specifiers (Programmable PMCs) 👑

Atom Silvermont programmable PMCs support the following events. buckle up bestie, this is the long part, and every single one matters:

  • REHABQ.LD_BLOCK_ST_FORWARD — (Event 03H, Umask 01H) the number of retired loads that were prohibited from receiving forwarded data from the store because of address mismatch. rude, honestly. 🚫
  • REHABQ.LD_BLOCK_STD_NOTREADY — (Event 03H, Umask 02H) the cases where a forward was technically possible, but did not occur because the store data was not available at the right time. so close, and yet. 😭
  • REHABQ.ST_SPLITS — (Event 03H, Umask 04H) the number of retire stores that experienced cache line boundary splits. 💔
  • REHABQ.LD_SPLITS — (Event 03H, Umask 08H) the number of retire loads that experienced cache line boundary splits. same energy, loads edition. 💔
  • REHABQ.LOCK — (Event 03H, Umask 10H) the number of retired memory operations with lock semantics. these are either implicit locked instructions such as the XCHG instruction or instructions with an explicit LOCK prefix (0xF0). very “don't touch my stuff” of them. 🔒
  • REHABQ.STA_FULL — (Event 03H, Umask 20H) the number of retired stores that are delayed because there is not a store address buffer available. no room at the inn. 😮‍💨
  • REHABQ.ANY_LD — (Event 03H, Umask 40H) the number of load uops reissued from Rehabq. ♻️
  • REHABQ.ANY_ST — (Event 03H, Umask 80H) the number of store uops reissued from Rehabq. ♻️
  • MEM_UOPS_RETIRED.L1_MISS_LOADS — (Event 04H, Umask 01H) the number of load ops retired that miss in L1 Data cache. note that prefetch misses will not be counted. read that again. 🙅
  • MEM_UOPS_RETIRED.L2_HIT_LOADS — (Event 04H, Umask 02H) the number of load micro-ops retired that hit L2. 🎯
  • MEM_UOPS_RETIRED.L2_MISS_LOADS — (Event 04H, Umask 04H) the number of load micro-ops retired that missed L2. 😬
  • MEM_UOPS_RETIRED.DTLB_MISS_LOADS — (Event 04H, Umask 08H) the number of load ops retired that had DTLB miss. 🗺️
  • MEM_UOPS_RETIRED.UTLB_MISS — (Event 04H, Umask 10H) the number of load ops retired that had UTLB miss. 🗺️
  • MEM_UOPS_RETIRED.HITM — (Event 04H, Umask 20H) the number of load ops retired that got data from the other core or from the other module. sharing is caring but it's also a counter. 🤝
  • MEM_UOPS_RETIRED.ALL_LOADS — (Event 04H, Umask 40H) the number of load ops retired. all of them. 📦
  • MEM_UOP_RETIRED.ALL_STORES — (Event 04H, Umask 80H) the number of store ops retired. (yes, that's MEM_UOP with no S — copy it exactly, don't be a hero.) 📦
  • PAGE_WALKS.D_SIDE_CYCLES — (Event 05H, Umask 01H) every cycle when a D-side (walks due to a load) page walk is in progress. page walk duration divided by number of page walks is the average duration of page-walks. the edge trigger bit must be cleared. set Edge to count the number of page walks. 🚶
  • PAGE_WALKS.I_SIDE_CYCLES — (Event 05H, Umask 02H) every cycle when an I-side (walks due to an instruction fetch) page walk is in progress. page walk duration divided by number of page walks is the average duration of page-walks. 🚶
  • PAGE_WALKS.WALKS — (Event 05H, Umask 03H) the number of times a data (D) page walk or an instruction (I) page walk is completed or started. since a page walk implies a TLB miss, the number of TLB misses can be counted by counting the number of pagewalks. iykyk. 🧠
  • LONGEST_LAT_CACHE.MISS — (Event 2EH, Umask 41H) the total number of L2 cache references and the number of L2 cache misses respectively. L3 is not supported in Silvermont microarchitecture. don't go looking for it. 🚫
  • LONGEST_LAT_CACHE.REFERENCE — (Event 2EH, Umask 4FH) the number of requests originating from the core that references a cache line in the L2 cache. L3 is not supported in Silvermont microarchitecture. again: no L3. none. 🚫
  • L2_REJECT_XQ.ALL — (Event 30H, Umask 00H) the number of demand and prefetch transactions that the L2 XQ rejects due to a full or near full condition which likely indicates back pressure from the IDI link. the XQ may reject transactions from the L2Q (non-cacheable requests), BBS (L2 misses) and WOB (L2 write-back victims). busy queue, no vibes. 🈵
  • CORE_REJECT_L2Q.ALL — (Event 31H, Umask 00H) the number of demand and L1 prefetcher requests rejected by the L2Q due to a full or nearly full condition which likely indicates back pressure from L2Q. it also counts requests that would have gone directly to the XQ, but are rejected due to a full or nearly full condition, indicating back pressure from the IDI link. the L2Q may also reject transactions from a core to insure fairness between cores, or to delay a core's dirty eviction when the address conflicts incoming external snoops. (note that L2 prefetcher requests that are dropped are not counted by this event.) 🈵
  • CPU_CLK_UNHALTED.CORE_P — (Event 3CH, Umask 00H) the number of core cycles while the core is not in a halt state. the core enters the halt state when it is running the HLT instruction. in mobile systems the core frequency may change from time to time. for this reason this event may have a changing ratio with regards to time. ⏰
  • CPU_CLK_UNHALTED.REF_P — (Event 3CH, Umask 01H) the number of reference cycles that the core is not in a halt state. the core enters the halt state when it is running the HLT instruction. in mobile systems the core frequency may change from time. this event is not affected by core frequency changes but counts as if the core is running at the maximum frequency all the time. steady queen. 👑
  • ICACHE.HIT — (Event 80H, Umask 01H) the number of instruction fetches from the instruction cache. ✅
  • ICACHE.MISSES — (Event 80H, Umask 02H) the number of instruction fetches that miss the Instruction cache or produce memory requests. this includes uncacheable fetches. an instruction fetch miss is counted only once and not once for every cycle it is outstanding. thank god. 😮‍💨

okay we're pausing right here bestie — there's more coming in part 2, so don't go anywhere 💖✨

  • ICACHE.ACCESSES (Event 80H, Umask 03H) — the number of instruction fetches, uncacheable ones included, bestie 💖
  • NIP_STALL.ICACHE_MISS (Event B6H, Umask 04H) — how many cycles the NIP stalls because of an icache miss. It's a cumulative count of cycles the NIP stalled for all the icache misses, so yeah, it stacks up 😭
  • OFFCORE_RESPONSE_0 (Event B7H, Umask 01H) — this one needs MSR_OFFCORE_RESP0 to specify the request type and response 🫶
  • OFFCORE_RESPONSE_1 (Event B7H, Umask 02H) — same vibes, but it needs MSR_OFFCORE_RESP to specify the request type and response ✨
  • INST_RETIRED.ANY_P (Event C0H, Umask 00H) — the number of instructions that retire execution. For instructions made of multiple micro-ops, this counts the retirement of the last micro-op of the instruction. And lowkey it just keeps counting during hardware interrupts, traps, and inside interrupt handlers — she does not pause 💅
  • UOPS_RETIRED.MS (Event C2H, Umask 01H) — the number of micro-ops retired that came supplied from MSROM 👑
  • UOPS_RETIRED.ALL (Event C2H, Umask 10H) — the number of micro-ops retired, periodt 🌈
  • MACHINE_CLEARS.SMC (Event C3H, Umask 01H) — the number of times a program writes to a code section. Heads up: self-modifying code causes a severe penalty in all Intel architecture processors, so like… don't 🫣
  • MACHINE_CLEARS.MEMORY_ORDERING (Event C3H, Umask 02H) — the number of times the pipeline got cleared because of memory ordering issues 💀
  • MACHINE_CLEARS.FP_ASSIST (Event C3H, Umask 04H) — the number of times the pipeline stalled because FP operations needed assists 🍓
  • MACHINE_CLEARS.ALL (Event C3H, Umask 08H) — the number of times the pipeline stalled due to any causes at all — SMC, MO, FP assist, the whole squad 😭
  • BR_INST_RETIRED.ALL_BRANCHES (Event C4H, Umask 00H) — the number of branch instructions retired ✨
  • BR_INST_RETIRED.JCC (Event C4H, Umask 7EH) — the number of retired branch instructions that were conditional jumps 🦋
  • BR_INST_RETIRED.FAR_BRANCH (Event C4H, Umask BFH) — the number of far branch instructions retired 🌸
  • BR_INST_RETIRED.NON_RETURN_IND (Event C4H, Umask EBH) — the number of retired branch instructions that were near indirect call or near indirect jmp 👑
  • BR_INST_RETIRED.RETURN (Event C4H, Umask F7H) — the number of near RET branch instructions retired 💜
  • BR_INST_RETIRED.CALL (Event C4H, Umask F9H) — the number of near CALL branch instructions retired 🎀
  • BR_INST_RETIRED.IND_CALL (Event C4H, Umask FBH) — the number of near indirect CALL branch instructions retired 🔥
  • BR_INST_RETIRED.REL_CALL (Event C4H, Umask FDH) — the number of near relative CALL branch instructions retired ⭐
  • BR_INST_RETIRED.TAKEN_JCC (Event C4H, Umask FEH) — the number of retired branch instructions that were conditional jumps predicted taken 🧚
  • BR_MISP_RETIRED.ALL_BRANCHES (Event C5H, Umask 00H) — the number of mispredicted branch instructions retired 🙈
  • BR_MISP_RETIRED.JCC (Event C5H, Umask 7EH) — the number of retired mispredicted branch instructions that were conditional jumps 😭
  • BR_MISP_RETIRED.FAR (Event C5H, Umask BFH) — the number of mispredicted far branch instructions retired 💀
  • BR_MISP_RETIRED.NON_RETURN_IND (Event C5H, Umask EBH) — the number of retired mispredicted branch instructions that were near indirect call or near indirect jmp 🌈
  • BR_MISP_RETIRED.RETURN (Event C5H, Umask F7H) — the number of mispredicted near RET branch instructions retired 🌸
  • BR_MISP_RETIRED.CALL (Event C5H, Umask F9H) — the number of mispredicted near CALL branch instructions retired 🫶
  • BR_MISP_RETIRED.IND_CALL (Event C5H, Umask FBH) — the number of mispredicted near indirect CALL branch instructions retired 💖
  • BR_MISP_RETIRED.REL_CALL (Event C5H, Umask FDH) — the number of mispredicted near relative CALL branch instructions retired ✨
  • BR_MISP_RETIRED.TAKEN_JCC (Event C5H, Umask FEH) — the number of retired mispredicted branch instructions that were conditional jumps predicted taken 🦋
  • NO_ALLOC_CYCLES.ROB_FULL (Event CAH, Umask 01H) — the number of cycles when no uops get allocated and the ROB is full — and by "full" we mean less than 2 entries available, no cap 💅
  • NO_ALLOC_CYCLES.RAT_STALL (Event CAH, Umask 20H) — the number of cycles when no uops are allocated and a RATstall is asserted 👑
  • NO_ALLOC_CYCLES.ALL (Event CAH, Umask 3FH) — the number of cycles when the front-end doesn't provide any instructions to be allocated, for literally any reason 🍓
  • NO_ALLOC_CYCLES.NOT_DELIVERED (Event CAH, Umask 50H) — the number of cycles when the front-end doesn't provide any instructions to be allocated, but the back end isn't stalled 🔥
  • RS_FULL_STALL.MEC (Event CBH, Umask 01H) — the number of cycles the allocation pipe line stalled because the RS for the MEC cluster is full 😭
  • RS_FULL_STALL.ALL (Event CBH, Umask 1FH) — the number of cycles the allocation pipe line stalled because any one of the RS is full 💜
  • CYCLES_DIV_BUSY.ANY (Event CDH, Umask 01H) — the number of cycles the divider is busy ⭐
  • BACLEARS.ALL (Event E6H, Umask 01H) — the number of baclears for any type of branch 🌈
  • BACLEARS.RETURN (Event E6H, Umask 08H) — the number of baclears for return branches 🧚
  • BACLEARS.COND (Event E6H, Umask 10H) — the number of baclears for conditional branches 🎀
  • MS_DECODED.MS_ENTRY (Event E7H, Umask 01H)) — the number of times the MSROM starts a flow of UOPS ✨ (yes, the original has that extra ) — we keep it exactly as-is, iykyk 💅)

🌸 SEE ALSO 🌸

pmc(3), pmc.amd(3), pmc.atom(3), pmc.core(3), pmc.core2(3), pmc.iaf(3), pmc.soft(3), pmc.tsc(3), pmc_cpuinfo(3), pmclog(3), hwpmc(4)

💜 HISTORY 💜

The pmc library first appeared in FreeBSD 6.0 🎀

👑 AUTHORS 👑

The Performance Counters Library (libpmc, -lpmc) library was written by Joseph Koshy <jkoshy@FreeBSD.org>. The support for the Atom Silvermont microarchitecture was written by Hiren Panchasara <hiren@FreeBSD.org>. Absolute icons, both of them 🫶

and that's a wrap bestie — this page is from Debian, dated April 6, 2017, and it's PMC.ATOMSILVERMONT(3). slay, go count those cycles 💖✨

📦 where this page comes from
  • freebsd 15.1: base 15.1
  • Copyright (c) 2014 Hiren Panchasara <hiren@FreeBSD.org>
  • 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms