From: Ingo Molnar <mingo@elte.hu>
To: Paul Mackerras <paulus@samba.org>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
Date: Tue, 16 Mar 2010 10:34:40 +0100 [thread overview]
Message-ID: <20100316093440.GE7961@elte.hu> (raw)
In-Reply-To: <20100312024100.GA2734@brick.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> On Thu, Mar 11, 2010 at 01:46:08PM +0100, Ingo Molnar wrote:
> >
> > * Corey Ashford <cjashfor@linux.vnet.ibm.com> wrote:
> >
> > > On 3/3/2010 6:30 PM, Corey Ashford wrote:
> > > >For your review, this patch adds support for arch-dependent symbolic
> > > >event names to the "perf stat" tool, and could be expanded to other
> > > >"perf *" commands fairly easily, I suspect.
>
> > I'm quite much against stop-gap measures like this - they tend to become
> > tomorrow's impossible-to-remove quirk.
> >
> > If you want extensible events you can already do it by providing an ftrace
> > tracepoint event via TRACE_EVENT. They are easy to add and ad-hoc, and are
> > supported throughout by perf.
>
> If I've understood correctly what Corey is doing, I think you're missing the
> point. The idea, I thought, was to provide a way to be able to use symbolic
> names for raw hardware events rather than just numbers. I don't see how
> ftrace tracepoint events are relevant to that.
tracepoints are relevant because they are the currently best way of how we
assign symbolic names to various kernel-internal events. For ad-hoc usecases
like this:
http://dri.freedesktop.org/wiki/IntelPerformanceTuning
I'd much rather see that facility used (and, to the extent needed, extended)
to provide support for rare arch events that we dont want to enumerate in a
generic way.
Or, if the events are important enough to be hardcoded into the perf ABI
itself, they should be generalized in a meaningful way - even if you dont
expect them to show up on other CPUs.
Ingo
next prev parent reply other threads:[~2010-03-16 9:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 2:30 [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat" Corey Ashford
2010-03-04 18:39 ` Corey Ashford
2010-03-11 12:46 ` Ingo Molnar
2010-03-11 18:47 ` Corey Ashford
2010-03-11 19:14 ` Ingo Molnar
2010-03-11 20:46 ` Corey Ashford
2010-03-15 23:38 ` Corey Ashford
2010-03-16 9:40 ` Ingo Molnar
2010-03-16 18:24 ` Corey Ashford
2010-03-12 2:41 ` Paul Mackerras
2010-03-12 6:53 ` Corey Ashford
2010-03-16 9:34 ` Ingo Molnar [this message]
2010-03-05 17:42 ` Corey Ashford
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=20100316093440.GE7961@elte.hu \
--to=mingo@elte.hu \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/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