linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: Vince Weaver <vince@deater.net>
Cc: vincent.weaver@maine.edu, 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: Thu, 4 Jul 2013 22:52:18 +1000	[thread overview]
Message-ID: <20130704125218.GA21134@concordia> (raw)
In-Reply-To: <alpine.DEB.2.02.1306251240440.25443@pianoman.cluster.toy>

On Tue, Jun 25, 2013 at 12:46:42PM -0400, Vince Weaver wrote:
> On Tue, 25 Jun 2013, Runzhen Wang wrote:
> 
> > This patch makes all the POWER7 events available in sysfs.
> > 
> > ...
> >
> > $ size arch/powerpc/perf/power7-pmu.o
> >    text	   data	    bss	    dec	    hex	filename
> >    3073	   2720	      0	   5793	   16a1	arch/powerpc/perf/power7-pmu.o
> > 
> > and after the patch is applied, it is:
> > 
> > $ size arch/powerpc/perf/power7-pmu.o
> >    text	   data	    bss	    dec	    hex	filename
> >   15950	  31112	      0	  47062	   b7d6	arch/powerpc/perf/power7-pmu.o
> 
> So if I'm reading this right, there's 45k of overhead for just one cpu 
> type?

I think there's another ~56K at runtime too, at least on my system where
each sysfs_dirent is 112 bytes.
 
> What happens if we do this on x86?
> 
> If we have similar for p6/p4/core2/nehalem/ivb/snb/amd10h/amd15h/amd16h/knb
> that's 450k of event defintions in the kernel.  And may I remind everyone 
> that you can't compile perf_event support as a module, nor can you 
> unconfigure it on x86 (it's always built in, no option to disable).

To be honest on Power7 systems we're not really bothered about ~100K,
that's less than two pages. But I agree with your point that it's
getting a bit silly.

Various folks have tried over the years to get alternative approaches
adopted (as I'm sure you know), and this has just ended up as the path
of least resistance.

> I'd like to repeat my unpopular position that we just link perf against 
> libpfm4 and keep event tables in userspace where they belong.

I don't think it even needs libpfm4, just some csv files in tools/perf
would do the trick.

Instead we have Google using gooda, which provides event decoding on top
of perf (via libpfm4). Andi Kleen at Intel has a tool that provides
event decoding on top of perf. Presumably Facebook do too? And at IBM
most folks still use oprofile, because it provides event decoding. 

cheers

  reply	other threads:[~2013-07-04 12:52 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 [this message]
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
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=20130704125218.GA21134@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).