On 2025-08-26 2:28 pm, Mark Rutland wrote:
On Tue, Aug 26, 2025 at 03:08:06PM +0200, Peter Zijlstra wrote:
On Wed, Aug 13, 2025 at 06:01:08PM +0100, Robin Murphy wrote:
Sampling is inherently a feature for CPU PMUs, given that the thing
to be sampled is a CPU context. These days, we have many more
uncore/system PMUs than CPU PMUs, so it no longer makes much sense to
assume sampling support by default and force the ever-growing majority
of drivers to opt out of it (or erroneously fail to). Instead, let's
introduce a positive opt-in capability that's more obvious and easier to
maintain.
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 4d439c24c901..bf2cfbeabba2 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -294,7 +294,7 @@ struct perf_event_pmu_context;
/**
* pmu::capabilities flags
*/
-#define PERF_PMU_CAP_NO_INTERRUPT 0x0001
+#define PERF_PMU_CAP_SAMPLING 0x0001
#define PERF_PMU_CAP_NO_NMI 0x0002
#define PERF_PMU_CAP_AUX_NO_SG 0x0004
#define PERF_PMU_CAP_EXTENDED_REGS 0x0008
@@ -305,6 +305,7 @@ struct perf_event_pmu_context;
#define PERF_PMU_CAP_EXTENDED_HW_TYPE 0x0100
#define PERF_PMU_CAP_AUX_PAUSE 0x0200
#define PERF_PMU_CAP_AUX_PREFER_LARGE 0x0400
+#define PERF_PMU_CAP_NO_INTERRUPT 0x0800
So NO_INTERRUPT was supposed to be the negative of your new SAMPLING
(and I agree with your reasoning).
What I'm confused/curious about is why we retain NO_INTERRUPT?
I see from your other reply that you spotted the next patch does that.
For the sake of other reviewers or anyone digging through the git
history it's probably worth adding a line to this commit message to say:
| A subsequent patch will remove PERF_PMU_CAP_NO_INTERRUPT as this
| requires some additional cleanup.
Yup, the main reason is the set of drivers getting the new cap is
smaller than the set of drivers currently not rejecting sampling events,
so I wanted it to be clearly visible in the patch. Indeed I shall
clarify the relationship to NO_INTERRUPT in the commit message.
Thanks,
Robin.
