Since commit bd2756811766 ("perf: Rewrite core context handling") the
relationship between perf_event_context and PMUs has changed so that
the error scenario that PERF_PMU_CAP_HETEROGENEOUS_CPUS originally
silenced no longer exists.
Remove the capability and associated comment to avoid confusion that it
actually influences any perf core behavior. This change should be a
no-op.
Signed-off-by: James Clark <[email protected]>
---
drivers/perf/arm_pmu.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index d8844a9461a2..297906df6628 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -872,15 +872,12 @@ struct arm_pmu *armpmu_alloc(void)
.attr_groups = pmu->attr_groups,
/*
* This is a CPU PMU potentially in a heterogeneous
- * configuration (e.g. big.LITTLE). This is not an uncore PMU,
- * and we have taken ctx sharing into account (e.g. with our
- * pmu::filter callback and pmu::event_init group validation).
- *
+ * configuration (e.g. big.LITTLE) so
* PERF_PMU_CAP_EXTENDED_HW_TYPE is required to open the legacy
* PERF_TYPE_HARDWARE and PERF_TYPE_HW_CACHE events on a
* specific PMU.
*/
- .capabilities = PERF_PMU_CAP_HETEROGENEOUS_CPUS | PERF_PMU_CAP_EXTENDED_REGS |
+ .capabilities = PERF_PMU_CAP_EXTENDED_REGS |
PERF_PMU_CAP_EXTENDED_HW_TYPE,
};
--
2.34.1
On Mon, Jul 10, 2023 at 5:22 AM James Clark <[email protected]> wrote:
>
> Since commit bd2756811766 ("perf: Rewrite core context handling") the
> relationship between perf_event_context and PMUs has changed so that
> the error scenario that PERF_PMU_CAP_HETEROGENEOUS_CPUS originally
> silenced no longer exists.
>
> Remove the capability and associated comment to avoid confusion that it
> actually influences any perf core behavior. This change should be a
> no-op.
>
> Signed-off-by: James Clark <[email protected]>
Acked-by: Ian Rogers <[email protected]>
Thanks,
Ian
> ---
> drivers/perf/arm_pmu.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index d8844a9461a2..297906df6628 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -872,15 +872,12 @@ struct arm_pmu *armpmu_alloc(void)
> .attr_groups = pmu->attr_groups,
> /*
> * This is a CPU PMU potentially in a heterogeneous
> - * configuration (e.g. big.LITTLE). This is not an uncore PMU,
> - * and we have taken ctx sharing into account (e.g. with our
> - * pmu::filter callback and pmu::event_init group validation).
> - *
> + * configuration (e.g. big.LITTLE) so
> * PERF_PMU_CAP_EXTENDED_HW_TYPE is required to open the legacy
> * PERF_TYPE_HARDWARE and PERF_TYPE_HW_CACHE events on a
> * specific PMU.
> */
> - .capabilities = PERF_PMU_CAP_HETEROGENEOUS_CPUS | PERF_PMU_CAP_EXTENDED_REGS |
> + .capabilities = PERF_PMU_CAP_EXTENDED_REGS |
> PERF_PMU_CAP_EXTENDED_HW_TYPE,
> };
>
> --
> 2.34.1
>
On 7/10/23 17:51, James Clark wrote:
> Since commit bd2756811766 ("perf: Rewrite core context handling") the
> relationship between perf_event_context and PMUs has changed so that
> the error scenario that PERF_PMU_CAP_HETEROGENEOUS_CPUS originally
> silenced no longer exists.
>
> Remove the capability and associated comment to avoid confusion that it
> actually influences any perf core behavior. This change should be a
> no-op.
>
> Signed-off-by: James Clark <[email protected]>
> ---
> drivers/perf/arm_pmu.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index d8844a9461a2..297906df6628 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -872,15 +872,12 @@ struct arm_pmu *armpmu_alloc(void)
> .attr_groups = pmu->attr_groups,
> /*
> * This is a CPU PMU potentially in a heterogeneous
> - * configuration (e.g. big.LITTLE). This is not an uncore PMU,
> - * and we have taken ctx sharing into account (e.g. with our
> - * pmu::filter callback and pmu::event_init group validation).
> - *
> + * configuration (e.g. big.LITTLE) so
> * PERF_PMU_CAP_EXTENDED_HW_TYPE is required to open the legacy
> * PERF_TYPE_HARDWARE and PERF_TYPE_HW_CACHE events on a
> * specific PMU.
> */
> - .capabilities = PERF_PMU_CAP_HETEROGENEOUS_CPUS | PERF_PMU_CAP_EXTENDED_REGS |
> + .capabilities = PERF_PMU_CAP_EXTENDED_REGS |
> PERF_PMU_CAP_EXTENDED_HW_TYPE,
Small nit, the second line could be folded back into the first one.
> };
>
On 11/07/2023 13:08, Anshuman Khandual wrote:
>
>
> On 7/10/23 17:51, James Clark wrote:
>> Since commit bd2756811766 ("perf: Rewrite core context handling") the
>> relationship between perf_event_context and PMUs has changed so that
>> the error scenario that PERF_PMU_CAP_HETEROGENEOUS_CPUS originally
>> silenced no longer exists.
>>
>> Remove the capability and associated comment to avoid confusion that it
>> actually influences any perf core behavior. This change should be a
>> no-op.
>>
>> Signed-off-by: James Clark <[email protected]>
>> ---
>> drivers/perf/arm_pmu.c | 7 ++-----
>> 1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
>> index d8844a9461a2..297906df6628 100644
>> --- a/drivers/perf/arm_pmu.c
>> +++ b/drivers/perf/arm_pmu.c
>> @@ -872,15 +872,12 @@ struct arm_pmu *armpmu_alloc(void)
>> .attr_groups = pmu->attr_groups,
>> /*
>> * This is a CPU PMU potentially in a heterogeneous
>> - * configuration (e.g. big.LITTLE). This is not an uncore PMU,
>> - * and we have taken ctx sharing into account (e.g. with our
>> - * pmu::filter callback and pmu::event_init group validation).
>> - *
>> + * configuration (e.g. big.LITTLE) so
>> * PERF_PMU_CAP_EXTENDED_HW_TYPE is required to open the legacy
>> * PERF_TYPE_HARDWARE and PERF_TYPE_HW_CACHE events on a
>> * specific PMU.
>> */
>> - .capabilities = PERF_PMU_CAP_HETEROGENEOUS_CPUS | PERF_PMU_CAP_EXTENDED_REGS |
>> + .capabilities = PERF_PMU_CAP_EXTENDED_REGS |
>> PERF_PMU_CAP_EXTENDED_HW_TYPE,
>
> Small nit, the second line could be folded back into the first one.
.clang-format has a column limit of 80 which is why it gets folded. The
kernel coding style guide also still says 80 is a strongly preferred
limit so I'll probably leave it.
>
>> };
>>