Em Mon, Oct 02, 2017 at 03:14:05PM +0100, Will Deacon escreveu:

On Fri, Sep 29, 2017 at 05:19:40PM -0500, Kim Phillips wrote:

quoted

On Thu, 28 Sep 2017 15:09:50 +0100
Will Deacon [off-list ref] wrote:

quoted

+	if (arm_spe_event_to_pmsevfr(event) & SYS_PMSEVFR_EL1_RES0)
+		return -EOPNOTSUPP;
+	if (attr->exclude_idle)
+		return -EOPNOTSUPP;

quoted

"PMU Hardware doesn't support sampling/overflow-interrupts." will be
printed if the user didn't specify a sample period.  Otherwise, a
string with "/bin/dmesg may provide additional information." will be
printed.

quoted

I was hoping for a response from acme by now for this:

quoted

https://www.spinics.net/lists/linux-perf-users/msg04066.html

quoted

Alas, nothing.  Looking at the #ifdef x86 in evsel.c, I'm guessing
it'll be ok, although I'm still not sure how PMU-specific we can get in
evsel.c, nor whether it's ok to communicate lists of h/w supported
sample periods through /sys/bus/event_source/devices/...

acme?  OK to refactor evsel messaging for Arm, including parsing for
which PMUs are being used, so customize the message?

Arnaldo's probably got enough on his plate maintaining perf tool, so my
advice would be to post a patch as an RFC and use that as a concrete basis
for discussion. It often works out better starting with code, even if none
of it ends up getting merged (and you can include bits of your email above
in the cover letter).

I'm all for more informative messages, and if you guys agree on how to
provide the info in a way that combined with logic in evsel.c, I'd say
do what Will suggested, post a patch series and include usage examples,
before and after.

- Arnaldo