[PATCH 16/19] perf: Introduce positive capability for sampling
Robin Murphy
robin.murphy at arm.com
Tue Aug 26 16:35:15 UTC 2025
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.
More information about the amd-gfx
mailing list