perf_events: add support for Intel fixed counter 2
cover perf_events: add support for Intel fixed counter 2
This short series of patches adds support for Intel fixed counter 2 on processors which implement architectural perfmon v2 and later.
Fixed counter 2 is wired to count reference cycles. It corrresponds to architected event UNHALTED_REFERENCE_CYCLES. This is a very useful event because:
- it is imune to Turbo Mode on Intel Nehalem and follow-ons
- it is imune to frequency scaling, including during idle
In other words, it keeps a constant correlation to time. It is therefore a good source a reliable timings comparable to TSC.
The other advantage of providing access to this counter is that it offers an additional cycle-counting counter. This is useful when the NMI watchdog is active because it already consumes one such counter.
The difficulty in providing access to the counter (and event) is that the encoding 0x013c is ambiguous. It also corresponds to event CPU_CLK_UNHALTED:REF_P (or BUS) which is measured on generic counters. The issue is that this event counts a different kind of cycles: bus cycles. Thus, the event code 0x13c is not enough to differentiate what the user wants.
This series of patches solves this problem by introducing a custom encoding for UNHALTED_REFERENCE_CYCLES (0xff3c) and improving the constraint infrastructure to handle events which can ONLY be measured on fixed counters.
The UNHALTED_REFERENCE_CYCLES (and fixed counter 2) is available on all Intel processors since architectural perfmon v2 (Intel Yonah).
[PATCH 0/2] - Introduction
[PATCH 1/2] - Improvement to X86 constraints management [PATCH 0/2] - add fixed counter 2 support
---
Quoted 4 lines · Stephane Eranian
This series of patches solves this problem by introducing a custom encoding for
UNHALTED_REFERENCE_CYCLES(0xff3c) and improving the constraint infrastructure to handle events which can ONLY be measured on fixed counters.
Right, so the only problem I can see with this is that Intel will at some point in the future put an actual event there.
Quoted 10 lines · Peter Zijlstra
Quoted 4 lines · Stephane Eranian
This series of patches solves this problem by introducing a custom encoding for
UNHALTED_REFERENCE_CYCLES(0xff3c) and improving the constraint infrastructure to handle events which can ONLY be measured on fixed counters.Right, so the only problem I can see with this is that Intel will at some point in the future put an actual event there.
I doubt that but I will check with them.
The alternative I thought about would be to use a bit in the upper 32 bit section
of attr.config and use the constraint->cmask to catch it. That would be a special
cmask. That would probably work because ALL events have to go through get_constraints().
Hi,
Ok, another, easier, choice would be to use event code 0 (and umaks 0x1 for instance). I doubt that one will ever be used.
Quoted 20 lines · Stephane Eranian
Quoted 10 lines · Peter Zijlstra
Quoted 4 lines · Stephane Eranian
This series of patches solves this problem by introducing a custom encoding for
UNHALTED_REFERENCE_CYCLES(0xff3c) and improving the constraint infrastructure to handle events which can ONLY be measured on fixed counters.Right, so the only problem I can see with this is that Intel will at some point in the future put an actual event there.
I doubt that but I will check with them.
The alternative I thought about would be to use a bit in the upper 32 bit section
of attr.config and use theconstraint->cmaskto catch it. That would be a special
cmask. That would probably work because ALL events have to go throughget_constraints().
Quoted 6 lines · Stephane Eranian
Hi,
Ok, another, easier, choice would be to use event code 0 (and umaks
0x1for instance). I doubt that one will ever be used.
Seems so, but there is no guarantee I think (at least for p4 there is 0x0 event (tc-deliver-mode)) though 0x1 should make it unique enough.
Signature · 1 line
Cyrill