From: kim.phillips@arm.com (Kim Phillips)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 1/3] perf tool: Introduce arch-specific supplemental perf open strerror capability
Date: Wed, 25 Oct 2017 21:22:10 -0500 [thread overview]
Message-ID: <20171025212210.fae60dcd543bafc312583ad3@arm.com> (raw)
In-Reply-To: <20171024202300.de189fde683c939966a6646c@arm.com>
On Tue, 24 Oct 2017 20:23:00 -0500
Kim Phillips <kim.phillips@arm.com> wrote:
> On Tue, 24 Oct 2017 12:27:44 -0200
> Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
>
> > Em Tue, Oct 24, 2017 at 03:04:04AM -0500, Kim Phillips escreveu:
> > > Introduce new tools/perf/arch/*/util/evsel.c:perf_evsel__suppl_strerror()
<snip>
> > But then you're calling it _before_ the existing switch (err), humm...
> > I.e. it will add stuff before the string that will be formatted later...
> > The messages may end up being conflicting, I wonder if the model
> > wouldn't be better as: ask the arch specific if it wants to override
> > that specific error with something, if not, fallback to the existing
> > perf_evsel__open_strerror() code, that could be moved to be
> > __perf_evsel__open_strerror() and called by the arch specific code.
> >
> > Thoughts?
>
> Thanks for your good feedback, yes, very good idea, fully agreed and
> implemented - see below.
I take this back: There's no way for the tool to tell whether it was
the PMU driver that croaked on the perf_event_open, or whether it was
due to another part of the syscall returning an error code.
WRT the CCN strerror code being able to tell whether it was the CCN
driver that did it, technically it could scan the event for strings
like 'vc=', but it still wouldn't be sure.
In the below example, the error being erroneously reported is the
default EINVAL case in the CCN strerror ("Invalid MN..."):
$ sudo ./perf stat -vv -e ccn/cycles/ -p 1330
ccn/cycles/: Invalid MN / XP / node ID, or node type, or node/XP port / vc or event, or mixed PMU group. See dmesg for details
^Cfailed to read counter ccn/cycles/
Performance counter stats for process id '1330':
<not supported> ccn/cycles/
2.343102253 seconds time elapsed
...and nothing was emitted in dmesg by the driver.
Any other ideas?
Kim
prev parent reply other threads:[~2017-10-26 2:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 8:04 [RFC 1/3] perf tool: Introduce arch-specific supplemental perf open strerror capability Kim Phillips
2017-10-24 13:35 ` Will Deacon
2017-10-25 1:11 ` Kim Phillips
2017-10-24 14:27 ` Arnaldo Carvalho de Melo
2017-10-25 1:23 ` Kim Phillips
2017-10-26 2:22 ` Kim Phillips [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171025212210.fae60dcd543bafc312583ad3@arm.com \
--to=kim.phillips@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).