All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vince Weaver <vincent.weaver@maine.edu>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Runzhen Wang <runzhen@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	paulus@samba.org, acme@redhat.com, mingo@kernel.org,
	Stephane Eranian <eranian@google.com>,
	sukadev@linux.vnet.ibm.com, xiaoguangrong@linux.vnet.ibm.com
Subject: Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
Date: Tue, 9 Jul 2013 11:20:50 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1307091113010.675@vincent-weaver-1.um.maine.edu> (raw)
In-Reply-To: <20130709033402.GA8543@concordia>

On Tue, 9 Jul 2013, Michael Ellerman wrote:

> On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> > 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.

what kind of devices are you talking about?  If they have 
kernel/perf_event support then they'd be putting a directory entry
with a unique name into /sys/bus/event_source/devices/, right?

> This whole thread is about making the event list not the kernel's job?

Yes.  This has been debated forever here; I'm firmly in the "event lists 
should be entirely in userspace" camp but that's not the majority 
position.

Hopefully everyone agrees though that including 100k+ of event lists in 
the kernel is a bit silly, especially as only a subset of people would ever 
use them.

There's the other issue that event lists are known to change due to bugs 
and whatnot (Intel likes to change things up every few months and silently 
change the event lists in their documentation).  It's a lot easier 
patching and distributing a new user-space event library [hours to days] 
then trying to get event list changes into the kernel, backported to 
stable, and then out into vendor kernels, and then on updated machines 
[weeks to never].

> 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.

I'm just curious if you have a specific piece of hardware in mind that 
won't fit the current model or if this is a theoretical concern.

Vince

WARNING: multiple messages have this Message-ID (diff)
From: Vince Weaver <vincent.weaver@maine.edu>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org,
	Stephane Eranian <eranian@google.com>,
	xiaoguangrong@linux.vnet.ibm.com, acme@redhat.com,
	paulus@samba.org, 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 11:20:50 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1307091113010.675@vincent-weaver-1.um.maine.edu> (raw)
In-Reply-To: <20130709033402.GA8543@concordia>

On Tue, 9 Jul 2013, Michael Ellerman wrote:

> On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> > 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.

what kind of devices are you talking about?  If they have 
kernel/perf_event support then they'd be putting a directory entry
with a unique name into /sys/bus/event_source/devices/, right?

> This whole thread is about making the event list not the kernel's job?

Yes.  This has been debated forever here; I'm firmly in the "event lists 
should be entirely in userspace" camp but that's not the majority 
position.

Hopefully everyone agrees though that including 100k+ of event lists in 
the kernel is a bit silly, especially as only a subset of people would ever 
use them.

There's the other issue that event lists are known to change due to bugs 
and whatnot (Intel likes to change things up every few months and silently 
change the event lists in their documentation).  It's a lot easier 
patching and distributing a new user-space event library [hours to days] 
then trying to get event list changes into the kernel, backported to 
stable, and then out into vendor kernels, and then on updated machines 
[weeks to never].

> 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.

I'm just curious if you have a specific piece of hardware in mind that 
won't fit the current model or if this is a theoretical concern.

Vince

  reply	other threads:[~2013-07-09 15:15 UTC|newest]

Thread overview: 44+ 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 ` 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-25 14:35   ` Runzhen Wang
2013-06-27 14:26   ` Michael Ellerman
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 14:35   ` Runzhen Wang
2013-06-25 16:46   ` Vince Weaver
2013-06-25 16:46     ` Vince Weaver
2013-07-04 12:52     ` Michael Ellerman
2013-07-04 12:52       ` Michael Ellerman
2013-07-04 12:57       ` Peter Zijlstra
2013-07-04 12:57         ` Peter Zijlstra
2013-07-05 10:23         ` Ingo Molnar
2013-07-05 10:23           ` Ingo Molnar
2013-07-09  1:29         ` Michael Ellerman
2013-07-09  1:29           ` Michael Ellerman
2013-07-09  2:24           ` Vince Weaver
2013-07-09  2:24             ` Vince Weaver
2013-07-09  3:34             ` Michael Ellerman
2013-07-09  3:34               ` Michael Ellerman
2013-07-09 15:20               ` Vince Weaver [this message]
2013-07-09 15:20                 ` Vince Weaver
2013-07-10  2:37                 ` Michael Ellerman
2013-07-10  2:37                   ` Michael Ellerman
2013-07-09  8:14             ` Peter Zijlstra
2013-07-09  8:14               ` Peter Zijlstra
2013-07-09 15:05               ` Vince Weaver
2013-07-09 15:05                 ` Vince Weaver
2013-07-11 10:58                 ` Will Deacon
2013-07-11 10:58                   ` Will Deacon
2013-07-11 17:53                   ` Vince Weaver
2013-07-11 17:53                     ` Vince Weaver
2013-07-10  3:09               ` Michael Ellerman
2013-07-10  3:09                 ` Michael Ellerman
2013-07-10  8:34                 ` Ingo Molnar
2013-07-10  8:34                   ` Ingo Molnar
2013-07-11  4:42                   ` Vince Weaver
2013-07-11  4:42                     ` Vince Weaver
2013-07-11  6:58                     ` Michael Ellerman
2013-07-11  6:58                       ` Michael Ellerman
2013-06-27 14:23   ` 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=alpine.DEB.2.10.1307091113010.675@vincent-weaver-1.um.maine.edu \
    --to=vincent.weaver@maine.edu \
    --cc=acme@redhat.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=michael@ellerman.id.au \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.