From: Corey Ashford <cjashfor@linux.vnet.ibm.com>
To: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
Date: Thu, 04 Mar 2010 10:39:17 -0800 [thread overview]
Message-ID: <4B8FFE55.5070008@linux.vnet.ibm.com> (raw)
In-Reply-To: <4B8F1B58.5000702@linux.vnet.ibm.com>
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.
>
> To support arch-dependent event names without adding arch-dependent code
> to perf, I added a callout mechanism whereby perf will look for the
> environment variable: PERF_ARCH_DEP_LIB, and if it exists, it will try
> to open it as a shared object. If that succeeds, it looks for the symbol
> "parse_arch_dep_event". If that exists, that function will be called by
> parse_events() before all of the other event parsing functions in
> parse-events.c. It is passed the same arguments as the other
> parse_*_event functions, namely the event string and a pointer to an
> event attribute structure.
>
> As the code existed, "perf stat" would print out the count results, but
> for raw events (which is how arch-dependent events are supported in
> perf_events), it would just print out a raw code. This is not
> acceptable, especially when a symbolic name was placed on the command
> line. So I changed the code to save away the event name that was passed
> on the command line, rather than doing a reverse translation to an event
> string based on the event type and config fields of the attr structure.
> In this way, there's no need for a reverse translation function in the
> arch-dependent library; only a event string->attr struct function is
> needed.
>
> I could well be missing something, but I don't understand why reverse
> translation is ever needed in perf, as long as the tool keeps track of
> the original event strings.
A couple of follow-up comments on this patch:
This functionality was designed to provide a generalized interface to an
external event name -> attr struct library, such as libpfm4. libpfm4 has an
interface that nearly exactly matches parse_*_event() profiles, so it's quite
easy to write a small wrapper function to call libpfm4's function.
Ingo Molnar discussed adding some visibility to the arch-dependent event names
through some other interface, such as through /sys/devices/pmus perhaps, but
that discussion is a long way (as far as I know) from having something usable
today. So you could think of this external library approach to be a stop-gap
until something better is developed. When/if that new event naming mechanism
becomes available, we can easily remove this external library support from perf.
--
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@us.ibm.com
next prev parent reply other threads:[~2010-03-04 18:39 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 [this message]
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
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=4B8FFE55.5070008@linux.vnet.ibm.com \
--to=cjashfor@linux.vnet.ibm.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.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