All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Vince Weaver <vincent.weaver@maine.edu>,
	Vince Weaver <vince@deater.net>,
	Runzhen Wang <runzhen@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	paulus@samba.org, acme@redhat.com,
	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: Wed, 10 Jul 2013 10:34:35 +0200	[thread overview]
Message-ID: <20130710083435.GA24070@gmail.com> (raw)
In-Reply-To: <20130710030926.GD7491@concordia>


* Michael Ellerman <michael@ellerman.id.au> wrote:

> On Tue, Jul 09, 2013 at 10:14:34AM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> > > 
> > > 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
> > 
> > Right so what I remember of the ARM case is that their /proc/cpuinfo isn't
> > sufficient to identify their PMU. And they don't have a cpuid like instruction
> > at all.
> > 
> > > > 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?
> > 
> > I agree, for x86 cpuid is perfectly fine, as would /proc/cpuinfo be, I suspect
> > that just the model number is sufficient in most cases, even for uncore stuff.
>  
> What about things on PCI? Other strange buses?
> 
> As long as everything's in /sys then it should be _possible_ for 
> userspace to work out what's what, but it's going to end up with a bunch 
> of detection logic and heuristics in the library.
> 
> At which point you've just rewritten libpfm4.

Exactly - PMUs enumerated in /sys should be self-identifying, it's a 
hardware topology after all ...

Anytime userspace is forced to look into /proc, or into weird places in 
/sys it's a FAIL really.

perf ABIs want to be self-identifying and self-sufficient, anytime 
userspace is forced to look elsewhere it adds another source of fragility.

And duplication with something that is 'already in /proc' is not a problem 
_at all_, these are computers that provide us different views into the 
same physical reality with dozens of different abstractions, so 
duplication of information is natural and _good_.

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: Vince Weaver <vincent.weaver@maine.edu>,
	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
Subject: Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
Date: Wed, 10 Jul 2013 10:34:35 +0200	[thread overview]
Message-ID: <20130710083435.GA24070@gmail.com> (raw)
In-Reply-To: <20130710030926.GD7491@concordia>


* Michael Ellerman <michael@ellerman.id.au> wrote:

> On Tue, Jul 09, 2013 at 10:14:34AM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> > > 
> > > 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
> > 
> > Right so what I remember of the ARM case is that their /proc/cpuinfo isn't
> > sufficient to identify their PMU. And they don't have a cpuid like instruction
> > at all.
> > 
> > > > 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?
> > 
> > I agree, for x86 cpuid is perfectly fine, as would /proc/cpuinfo be, I suspect
> > that just the model number is sufficient in most cases, even for uncore stuff.
>  
> What about things on PCI? Other strange buses?
> 
> As long as everything's in /sys then it should be _possible_ for 
> userspace to work out what's what, but it's going to end up with a bunch 
> of detection logic and heuristics in the library.
> 
> At which point you've just rewritten libpfm4.

Exactly - PMUs enumerated in /sys should be self-identifying, it's a 
hardware topology after all ...

Anytime userspace is forced to look into /proc, or into weird places in 
/sys it's a FAIL really.

perf ABIs want to be self-identifying and self-sufficient, anytime 
userspace is forced to look elsewhere it adds another source of fragility.

And duplication with something that is 'already in /proc' is not a problem 
_at all_, these are computers that provide us different views into the 
same physical reality with dozens of different abstractions, so 
duplication of information is natural and _good_.

Thanks,

	Ingo

  reply	other threads:[~2013-07-10  8:34 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
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 [this message]
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=20130710083435.GA24070@gmail.com \
    --to=mingo@kernel.org \
    --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=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 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.