All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: 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: Thu, 11 Mar 2010 20:14:41 +0100	[thread overview]
Message-ID: <20100311191441.GA7593@elte.hu> (raw)
In-Reply-To: <4B993AAF.9050507@linux.vnet.ibm.com>


* Corey Ashford <cjashfor@linux.vnet.ibm.com> wrote:

> On 3/11/2010 4:46 AM, Ingo Molnar wrote:
> [snip]
> >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.
> 
> Is TRACE_EVENT an appropriate way to add hardware-specific counter
> events?  I will look into this.  Thanks for the pointer.
> 
> >
> >That could be librarized further by providing an /eventfs or /proc/events
> >interface to enumerate them.
> 
> We can enumerate events this way, but there are other aspects to
> events than just their names (see below).
> 
> >
> >Or if you want to extend the perf events namespace ABI you can send patches
> >for that as well. (It's not a big issue if a particular event is currently
> >only supported on Power for example - as long as you make a good effort naming
> >and structuring it in a reasonably generic way.)
> 
> I'm not sure how that would work.  The issue I am trying to solve
> here is that Power arch chips have a large number of very
> hardware-specific events that are not generalizable.  Many of these
> events not only have names, but other user-configurable bits as well
> that select or narrow the scope of which exact events are recorded.
> This issue is dealt with nicely in libpfm4, as it has mechanisms for
> parsing event names and attributes (aka modifiers or unit masks),
> and then produces a usable config field for the perf_events_attr
> struct.
> 
> Should I take it from the above that you are completely against the
> idea of using an external library for hardware-specific event and
> attribute naming?

Could you give a few relevant examples of events in question, and the kind of 
configurability/attributes they have on Power?

Thanks,

	Ingo

  reply	other threads:[~2010-03-11 19:15 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 [this message]
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
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=20100311191441.GA7593@elte.hu \
    --to=mingo@elte.hu \
    --cc=cjashfor@linux.vnet.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.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 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.