All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vince Weaver <vince@deater.net>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: mingo@kernel.org, hpa@zytor.com, paulus@samba.org,
	linux-kernel@vger.kernel.org, acme@redhat.com,
	runzhen@linux.vnet.ibm.com, runzhew@clemson.edu,
	xiaoguangrong@linux.vnet.ibm.com, sukadev@linux.vnet.ibm.com,
	tglx@linutronix.de, linux-tip-commits@vger.kernel.org,
	torvalds@linux-foundation.org
Subject: Re: [tip:perf/core] perf tools: Make Power7 events available for perf
Date: Tue, 23 Jul 2013 17:38:21 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1307231731020.27628@pianoman.cluster.toy> (raw)
In-Reply-To: <1374558969.5545.30.camel@concordia>


I wish I were as good as cursing as Linus, ccing him in case he's willing 
to donate a few choice expressions.

On Tue, 23 Jul 2013, Michael Ellerman wrote:

> On Tue, 2013-07-23 at 01:33 -0400, Vince Weaver wrote:

> > > $ 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 we're really going down this road?
> 
> _We_ are going down this road, at least until there is a better
> solution. You'll notice I haven't merged any events for power8.

No, you are going down this road permanently, because if you commit this, 
it becomes ABI, and we have to maintain it forever.

> x86 can do what it wants. I don't think anyone in x86 land has proposed
> putting all the events in the kernel, so you can stop worrying about
> your 300k of memory.

I thought the prime directive of perf_event was nothing in the kernel that 
wasn't generic and applied to all architectures?  Why is Power7 special?

Abusing sysfs to waste 100k of non-swappable kernel memory on every 
running Linux kernel everwhere to hold static event tables that could be a 
simple CSV file in the perf tools directory is crazy.

Especially as it's likely this becomes stable ABI, and then you'll 
promptly break it as has already happenend in the last kernel release 
with the existing in-kernel powerpc events.

> I thought it was pretty clear from the last thread that folks agreed the
> event _lists_ should be in userspace. The discovery of the PMUs should
> be done in the kernel, and that should be communicated to userspace via
> something in sys.

I agree.  So why is this patch in tip?

> What it needs now is someone with some free time to actually code it up.
> Right now that's not me.

The code exists; it's called libpfm4.  Just becase you're lazy doesn't 
mean we commit garbage code into the kenrel.

For what it's worth, as the unofficial perf_event ABI documentation 
maintainer I strongly NAK this patch.

Vince



  reply	other threads:[~2013-07-23 21:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-28  8:14 [PATCH v3 0/2] perf tools: Power7 events name available for perf Runzhen Wang
2013-06-28  8:14 ` Runzhen Wang
2013-06-28  8:14 ` [PATCH v3 1/2] perf tools: fix a typo of a Power7 event name Runzhen Wang
2013-06-28  8:14   ` Runzhen Wang
2013-07-12  8:51   ` [tip:perf/urgent] " tip-bot for Runzhen Wang
2013-06-28  8:14 ` [PATCH v3 2/2] perf tools: Make Power7 events available for perf Runzhen Wang
2013-06-28  8:14   ` Runzhen Wang
2013-07-19  7:44   ` [tip:perf/core] " tip-bot for Runzhen Wang
2013-07-23  5:33     ` Vince Weaver
2013-07-23  5:56       ` Michael Ellerman
2013-07-23 21:38         ` Vince Weaver [this message]
2013-07-25 13:41           ` Michael Ellerman
2013-07-26  4:25             ` Vince Weaver
2013-07-01  1:53 ` [PATCH v3 0/2] perf tools: Power7 events name " Michael Ellerman
2013-07-01  1:53   ` 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.02.1307231731020.27628@pianoman.cluster.toy \
    --to=vince@deater.net \
    --cc=acme@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=michael@ellerman.id.au \
    --cc=mingo@kernel.org \
    --cc=paulus@samba.org \
    --cc=runzhen@linux.vnet.ibm.com \
    --cc=runzhew@clemson.edu \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --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.