[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44587738-ad0f-4c7e-b1ca-230a62605724@arm.com>
Date: Wed, 13 Mar 2024 12:02:50 +0000
From: Robin Murphy <robin.murphy@....com>
To: James Clark <james.clark@....com>
Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, x86@...nel.org,
linux-perf-users@...r.kernel.org, jialong.yang@...ngroup.cn,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
Will Deacon <will@...nel.org>
Subject: Re: [PATCH 05/10] drivers/perf: Use PERF_PMU_CAP_NO_SAMPLING
consistently
On 2024-03-13 11:11 am, James Clark wrote:
>
>
> On 12/03/2024 17:34, Robin Murphy wrote:
>> Our system PMUs fundamentally cannot support the current notion of
>> sampling events, so now that the core capability has been clarified,
>> apply it consistently and purge yet more boilerplate.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@....com>
>> ---
>> drivers/perf/alibaba_uncore_drw_pmu.c | 6 +-----
>> drivers/perf/amlogic/meson_ddr_pmu_core.c | 3 ++-
>> drivers/perf/arm-cci.c | 3 ++-
>> drivers/perf/arm-ccn.c | 12 +-----------
>> drivers/perf/arm-cmn.c | 3 ++-
>> drivers/perf/arm_cspmu/arm_cspmu.c | 17 ++++-------------
>> drivers/perf/arm_dmc620_pmu.c | 4 ++--
>> drivers/perf/arm_dsu_pmu.c | 12 +-----------
>> drivers/perf/arm_smmuv3_pmu.c | 6 +-----
>> drivers/perf/cxl_pmu.c | 3 ++-
>> drivers/perf/dwc_pcie_pmu.c | 5 +----
>> drivers/perf/fsl_imx8_ddr_perf.c | 3 ++-
>> drivers/perf/fsl_imx9_ddr_perf.c | 3 ++-
>> drivers/perf/hisilicon/hisi_pcie_pmu.c | 4 ++--
>> drivers/perf/hisilicon/hisi_uncore_pmu.c | 3 ++-
>> drivers/perf/hisilicon/hns3_pmu.c | 4 ++--
>> drivers/perf/marvell_cn10k_ddr_pmu.c | 6 +-----
>> drivers/perf/qcom_l2_pmu.c | 7 +------
>> drivers/perf/qcom_l3_pmu.c | 7 +------
>> drivers/perf/thunderx2_pmu.c | 4 ++--
>> drivers/perf/xgene_pmu.c | 4 ++--
>> 21 files changed, 36 insertions(+), 83 deletions(-)
>>
> [...]
>>
>> diff --git a/drivers/perf/arm-ccn.c b/drivers/perf/arm-ccn.c
>> index ce26bb773a56..4114349e62dd 100644
>> --- a/drivers/perf/arm-ccn.c
>> +++ b/drivers/perf/arm-ccn.c
>> @@ -713,7 +713,6 @@ static void arm_ccn_pmu_event_release(struct perf_event *event)
>> static int arm_ccn_pmu_event_init(struct perf_event *event)
>> {
>> struct arm_ccn *ccn;
>> - struct hw_perf_event *hw = &event->hw;
>> u32 node_xp, type, event_id;
>> int valid;
>> int i;
>> @@ -721,16 +720,6 @@ static int arm_ccn_pmu_event_init(struct perf_event *event)
>>
>> ccn = pmu_to_arm_ccn(event->pmu);
>>
>> - if (hw->sample_period) {
>> - dev_dbg(ccn->dev, "Sampling not supported!\n");
>> - return -EOPNOTSUPP;
>> - }
>> -
>> - if (has_branch_stack(event)) {
>> - dev_dbg(ccn->dev, "Can't exclude execution levels!\n");
>> - return -EINVAL;
>> - }
>> -
>
> [...]
>
>> diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
>> index f5ea5acaf2f3..3424d165795c 100644
>> --- a/drivers/perf/arm_dsu_pmu.c
>> +++ b/drivers/perf/arm_dsu_pmu.c
>> @@ -544,23 +544,12 @@ static int dsu_pmu_event_init(struct perf_event *event)
>> {
>> struct dsu_pmu *dsu_pmu = to_dsu_pmu(event->pmu);
>>
>> - /* We don't support sampling */
>> - if (is_sampling_event(event)) {
>> - dev_dbg(dsu_pmu->pmu.dev, "Can't support sampling events\n");
>> - return -EOPNOTSUPP;
>> - }
>> -
>> /* We cannot support task bound events */
>> if (event->cpu < 0 || event->attach_state & PERF_ATTACH_TASK) {
>> dev_dbg(dsu_pmu->pmu.dev, "Can't support per-task counters\n");
>> return -EINVAL;
>> }
>>
>> - if (has_branch_stack(event)) {
>> - dev_dbg(dsu_pmu->pmu.dev, "Can't support filtering\n");
>> - return -EINVAL;
>> - }
>> -
>
> I'm assuming that this and the other has_branch_stack() check were
> removed because branch stacks don't actually do anything unless sampling
> is enabled?
>
> It's a small difference that there is now no error message if you ask
> for branch stacks, but it wouldn't have done anything anyway? I suppose
> this error message was also not applied very consistently across the
> different devices.
Right - the rarity of these checks, plus the fact that in both cases
here they give a nonsensical debug message that has nothing whatsoever
to do with the actual failing condition, seems to make it clear that
they aren't realistically useful.
In general I don't see any good reason for a non-sampling event to be
picky about the exact type of samples it isn't collecting.
Thanks,
Robin.
Powered by blists - more mailing lists