From: Michael Ellerman <michael@ellerman.id.au>
To: Vince Weaver <vincent.weaver@maine.edu>
Cc: Peter Zijlstra <peterz@infradead.org>,
Vince Weaver <vince@deater.net>,
Stephane Eranian <eranian@google.com>,
linux-kernel@vger.kernel.org, acme@redhat.com, paulus@samba.org,
xiaoguangrong@linux.vnet.ibm.com,
Runzhen Wang <runzhen@linux.vnet.ibm.com>,
sukadev@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org,
mingo@kernel.org
Subject: Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
Date: Tue, 9 Jul 2013 13:34:02 +1000 [thread overview]
Message-ID: <20130709033402.GA8543@concordia> (raw)
In-Reply-To: <alpine.DEB.2.10.1307082204550.26280@vincent-weaver-1.um.maine.edu>
On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> On Tue, 9 Jul 2013, Michael Ellerman wrote:
>
> > On Thu, Jul 04, 2013 at 02:57:00PM +0200, Peter Zijlstra wrote:
> > >
> > > Right; I think Stephane and Jiri are in favour of creating a 'new' project that
> > > includes just the event definitions in a plain text format and a little library
> > > with parser to be used by all interested parties.
> >
> > OK that would be great.
> >
> > The part that seems to be missing to make that work is we have no way of
> > matching the PMU that appears in /sys with a list of events.
> >
> > Eg. on my system I have /sys/bus/event_source/devices/cpu - but there's
> > nothing in there to identify that it's a Sandy Bridge.
>
> So something like they have on ARM?
>
> vince@pandaboard:/sys/bus/event_source/devices$ ls -l
> lrwxrwxrwx 1 root root 0 Jul 8 21:57 ARMv7 Cortex-A9 -> ../../../devices/ARMv7 Cortex-A9
> lrwxrwxrwx 1 root root 0 Jul 8 21:57 breakpoint -> ../../../devices/breakpoint
> lrwxrwxrwx 1 root root 0 Jul 8 21:57 software -> ../../../devices/software
> lrwxrwxrwx 1 root root 0 Jul 8 21:57 tracepoint -> ../../../devices/tracepoint
Sort of. I wasn't thinking of using the name, rather adding an attribute
with a well defined list of values.
> > For the cpu you can obviously just detect what processor you're on with
> > cpuid or whatever, but it's a bit of a hack. And that really doesn't
> > work for non-cpu PMUs.
>
> why is it a hack to use cpuid?
Because you're assuming that the PMU the kernel has exposed is for the
cpu you happen to be executing on.
But the real issue is with PMUs that are not in the CPU - there is no
easy way for userspace to detect them and determine which event list it
should be consulting.
> People have done event lists in userspace for years. Why must it be the
> kernel's job?
This whole thread is about making the event list not the kernel's job?
The part that _is_ the kernels job is detecting the hardware and
providing an API to access it. What I'm saying is that the kernel API
should include some sort of identifier so that userspace can reliably
determine the event list to use.
cheers
next prev parent reply other threads:[~2013-07-09 3:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-25 14:35 [PATCH v2 0/2] perf tools: Power7 events name available for perf Runzhen Wang
2013-06-25 14:35 ` [PATCH v3 1/2] perf tools: fix a typo of a Power7 event name Runzhen Wang
2013-06-27 14:26 ` Michael Ellerman
2013-06-25 14:35 ` [PATCH v2 2/2] perf tools: Make Power7 events available for perf Runzhen Wang
2013-06-25 16:46 ` Vince Weaver
2013-07-04 12:52 ` Michael Ellerman
2013-07-04 12:57 ` Peter Zijlstra
2013-07-05 10:23 ` Ingo Molnar
2013-07-09 1:29 ` Michael Ellerman
2013-07-09 2:24 ` Vince Weaver
2013-07-09 3:34 ` Michael Ellerman [this message]
2013-07-09 15:20 ` Vince Weaver
2013-07-10 2:37 ` Michael Ellerman
2013-07-09 8:14 ` Peter Zijlstra
2013-07-09 15:05 ` Vince Weaver
2013-07-11 10:58 ` Will Deacon
2013-07-11 17:53 ` Vince Weaver
2013-07-10 3:09 ` Michael Ellerman
2013-07-10 8:34 ` Ingo Molnar
2013-07-11 4:42 ` Vince Weaver
2013-07-11 6:58 ` Michael Ellerman
2013-06-27 14:23 ` Michael Ellerman
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=20130709033402.GA8543@concordia \
--to=michael@ellerman.id.au \
--cc=acme@redhat.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=runzhen@linux.vnet.ibm.com \
--cc=sukadev@linux.vnet.ibm.com \
--cc=vince@deater.net \
--cc=vincent.weaver@maine.edu \
--cc=xiaoguangrong@linux.vnet.ibm.com \
/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).