[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1231fd60-79cd-fcdf-8b99-a3be746bf2d1@arm.com>
Date: Fri, 17 Jan 2020 15:00:37 +0000
From: James Clark <James.Clark@....com>
To: Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will@...nel.org>
CC: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, nd <nd@....com>,
Mark Rutland <Mark.Rutland@....com>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Tan Xiaojun <tanxiaojun@...wei.com>,
Al Grant <Al.Grant@....com>,
Namhyung Kim <namhyung@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] Return EINVAL when precise_ip perf events are
requested on Arm
Hi Peter,
Do you mean something like this?
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 43d1d4945433..f74acd085bea 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10812,6 +10812,12 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
goto err_pmu;
}
+ if (event->attr.precise_ip &&
+ !(pmu->capabilities & PERF_PMU_CAP_PRECISE_IP)) {
+ err = -EOPNOTSUPP;
+ goto err_pmu;
+ }
+
err = exclusive_event_init(event);
if (err)
goto err_pmu;
Or should it only be done via sysfs to not break userspace?
If this was done via sysfs would it be possible to express that some events support
some attributes and others don't? It seems like the "caps" folder couldn't be
that fine grained.
On 17/01/2020 14:01, Peter Zijlstra wrote:
> On Fri, Jan 17, 2020 at 12:39:21PM +0000, Will Deacon wrote:
>
>> Perhaps a better way would be to expose something under sysfs, a bit like
>> the caps directory for the SPE PMU, which identifies the fields of the attr
>> structure that the driver does not ignore. I think doing this as an Arm-PMU
>> specific thing initially would be fine, but it would be even better to have
>> something where a driver can tell perf core about the parts it responds to
>> and have this stuff populated automatically. The current design makes it
>> inevitable that PMU drivers will have issues like the one you point out in
>> the cover letter.
>>
>> Thoughts?
>
> We have PERF_PMU_CAP_ flags we could extend to that purpose.
>
Powered by blists - more mailing lists