All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
@ 2010-03-04  2:30 Corey Ashford
  2010-03-04 18:39 ` Corey Ashford
  2010-03-05 17:42 ` Corey Ashford
  0 siblings, 2 replies; 13+ messages in thread
From: Corey Ashford @ 2010-03-04  2:30 UTC (permalink / raw)
  To: LKML, Peter Zijlstra, Ingo Molnar, Frederic Weisbecker

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

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.

Thanks for your consideration,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@us.ibm.com


[-- Attachment #2: perf_symbolic_event.diff --]
[-- Type: text/plain, Size: 4284 bytes --]

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 54a5b50..20d3255 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -199,7 +199,7 @@ ifndef PERF_DEBUG
 endif
 
 CFLAGS = -ggdb3 -Wall -Wextra -std=gnu99 -Werror $(CFLAGS_OPTIMIZE) -D_FORTIFY_SOURCE=2 $(EXTRA_WARNINGS) $(EXTRA_CFLAGS)
-EXTLIBS = -lpthread -lrt -lelf -lm
+EXTLIBS = -lpthread -lrt -lelf -lm -ldl
 ALL_CFLAGS = $(CFLAGS)
 ALL_LDFLAGS = $(LDFLAGS)
 STRIP ?= strip
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 05d0c5c..ba4a663 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -8,11 +8,13 @@
 #include "cache.h"
 #include "header.h"
 #include "debugfs.h"
+#include "dlfcn.h"
 
 int				nr_counters;
 
 struct perf_event_attr		attrs[MAX_COUNTERS];
 char				*filters[MAX_COUNTERS];
+char 				*event_names[MAX_COUNTERS];
 
 struct event_symbol {
 	u8		type;
@@ -267,10 +269,7 @@ static char *event_cache_name(u8 cache_type, u8 cache_op, u8 cache_result)
 
 const char *event_name(int counter)
 {
-	u64 config = attrs[counter].config;
-	int type = attrs[counter].type;
-
-	return __event_name(type, config);
+	return event_names[counter];
 }
 
 const char *__event_name(int type, u64 config)
@@ -324,6 +323,38 @@ const char *__event_name(int type, u64 config)
 	return "unknown";
 }
 
+#define PERF_ARCH_DEP_LIB_ENV_VAR "PERF_ARCH_DEP_LIB"
+
+static int arch_dep_lib_initialized = 0;
+static int (*parse_arch_dep_event_callout)(const char **strp,
+				   	   struct perf_event_attr *attr) = NULL;
+
+static void initialize_arch_dep_lib(void)
+{
+	char *lib_name = getenv(PERF_ARCH_DEP_LIB_ENV_VAR);
+	void *lib_handle;
+
+	if (!lib_name)
+		return;
+
+	lib_handle = dlopen(lib_name, RTLD_NOW);
+	if (!lib_handle) {
+		fprintf(stderr, "The environment variable %s is set to %s, "
+				"but we couldn't open it.  error: %s\n",
+				PERF_ARCH_DEP_LIB_ENV_VAR, lib_name, dlerror());
+		exit(1);
+	}
+	parse_arch_dep_event_callout = dlsym(lib_handle, "parse_arch_dep_event");
+	if (!parse_arch_dep_event_callout) {
+		fprintf(stderr, "The environment variable %s is set to %s, "
+				"but we couldn't obtain from it the required function - "
+				"parse_arch_dep_event.  error: %s\n",
+				PERF_ARCH_DEP_LIB_ENV_VAR, lib_name, dlerror());
+		exit(1);
+	}
+	arch_dep_lib_initialized = 1;
+}
+
 static int parse_aliases(const char **str, const char *names[][MAX_ALIASES], int size)
 {
 	int i, j;
@@ -686,6 +717,18 @@ parse_numeric_event(const char **strp, struct perf_event_attr *attr)
 	return EVT_FAILED;
 }
 
+static int
+parse_arch_dep_event(const char **strp, struct perf_event_attr *attr)
+{
+	if (! arch_dep_lib_initialized)
+		initialize_arch_dep_lib();
+
+	if (arch_dep_lib_initialized)
+		return parse_arch_dep_event_callout(strp, attr);
+	else
+		return 0;
+}
+
 static enum event_result
 parse_event_modifier(const char **strp, struct perf_event_attr *attr)
 {
@@ -724,6 +767,11 @@ parse_event_symbols(const char **str, struct perf_event_attr *attr)
 {
 	enum event_result ret;
 
+	ret = parse_arch_dep_event(str, attr);
+	if (ret != EVT_FAILED)
+		/* modifiers are already processed */
+		return ret;
+
 	ret = parse_tracepoint_event(str, attr);
 	if (ret != EVT_FAILED)
 		goto modifier;
@@ -784,6 +832,17 @@ static int store_event_type(const char *orgname)
 	return perf_header__push_event(id, orgname);
 }
 
+static char *make_substr(char *start, char *end)
+{
+	int length = end - start;
+	char *result = malloc(length + 1);
+
+	strncpy(result, start, length);
+	result[length] = '\0';
+
+	return result;
+}
+
 int parse_events(const struct option *opt __used, const char *str, int unset __used)
 {
 	struct perf_event_attr attr;
@@ -794,19 +853,23 @@ int parse_events(const struct option *opt __used, const char *str, int unset __u
 			return -1;
 
 	for (;;) {
+		char *start, *end;
 		if (nr_counters == MAX_COUNTERS)
 			return -1;
 
 		memset(&attr, 0, sizeof(attr));
+		start = (char *)str;
 		ret = parse_event_symbols(&str, &attr);
 		if (ret == EVT_FAILED)
 			return -1;
 
 		if (!(*str == 0 || *str == ',' || isspace(*str)))
 			return -1;
+		end = (char *)str;
 
 		if (ret != EVT_HANDLED_ALL) {
 			attrs[nr_counters] = attr;
+			event_names[nr_counters] = make_substr(start, end);
 			nr_counters++;
 		}
 

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  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-05 17:42 ` Corey Ashford
  1 sibling, 1 reply; 13+ messages in thread
From: Corey Ashford @ 2010-03-04 18:39 UTC (permalink / raw)
  To: LKML, Peter Zijlstra, Ingo Molnar, Frederic Weisbecker

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  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-05 17:42 ` Corey Ashford
  1 sibling, 0 replies; 13+ messages in thread
From: Corey Ashford @ 2010-03-05 17:42 UTC (permalink / raw)
  To: LKML

(I posted this yesterday, but I think LKML rejected it because there was more
quoted text than my text.  So I am reposting with no quoted text).

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
cjashfor@us.ibm.com


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-04 18:39 ` Corey Ashford
@ 2010-03-11 12:46   ` Ingo Molnar
  2010-03-11 18:47     ` Corey Ashford
  2010-03-12  2:41     ` Paul Mackerras
  0 siblings, 2 replies; 13+ messages in thread
From: Ingo Molnar @ 2010-03-11 12:46 UTC (permalink / raw)
  To: Corey Ashford; +Cc: LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt


* 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.
> >
> >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.

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.

That could be librarized further by providing an /eventfs or /proc/events 
interface to enumerate them.

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.)

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-11 12:46   ` Ingo Molnar
@ 2010-03-11 18:47     ` Corey Ashford
  2010-03-11 19:14       ` Ingo Molnar
  2010-03-12  2:41     ` Paul Mackerras
  1 sibling, 1 reply; 13+ messages in thread
From: Corey Ashford @ 2010-03-11 18:47 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt

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?

-- 
Regards,

- Corey


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-11 18:47     ` Corey Ashford
@ 2010-03-11 19:14       ` Ingo Molnar
  2010-03-11 20:46         ` Corey Ashford
  0 siblings, 1 reply; 13+ messages in thread
From: Ingo Molnar @ 2010-03-11 19:14 UTC (permalink / raw)
  To: Corey Ashford; +Cc: LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt


* 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-11 19:14       ` Ingo Molnar
@ 2010-03-11 20:46         ` Corey Ashford
  2010-03-15 23:38           ` Corey Ashford
  0 siblings, 1 reply; 13+ messages in thread
From: Corey Ashford @ 2010-03-11 20:46 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt



On 3/11/2010 11:14 AM, Ingo Molnar wrote:
>
> * Corey Ashford<cjashfor@linux.vnet.ibm.com>  wrote:
[snip]
>> 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?

Here are a few examples for the Power A2 processor.  I've distorted the names 
because PMU architecture isn't publicly released yet.

PM_DE_PMC_9:hrd_mask=0xff:hrd=0x22:pma_mask=0x3fff:pma=0x1b2d:culling_mode=3
PM_EX_0x03:lane=2:vlane=1
PM_OWE_ENG_MAC_FULL:usu=3

Note that the attribute fields shown above are fitted into the config field of 
the perf_event_attr struct.

>
> Thanks,
>
> 	Ingo

Regards,

- Corey


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-11 12:46   ` Ingo Molnar
  2010-03-11 18:47     ` Corey Ashford
@ 2010-03-12  2:41     ` Paul Mackerras
  2010-03-12  6:53       ` Corey Ashford
  2010-03-16  9:34       ` Ingo Molnar
  1 sibling, 2 replies; 13+ messages in thread
From: Paul Mackerras @ 2010-03-12  2:41 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Corey Ashford, LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt

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.

Now as to whether an external .so is the best way to provide the
processor-specific mapping of names to raw events, I'm not sure.
If the kernel can provide that mapping via procfs, sysfs or eventfs,
that would be an alternative, but it does mean the kernel has those
tables in unswappable memory (and potentially the tables for all the
processors that the kernel supports), which seems unnecessary.  Or
they can just be added to the perf source code.

Paul.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-12  2:41     ` Paul Mackerras
@ 2010-03-12  6:53       ` Corey Ashford
  2010-03-16  9:34       ` Ingo Molnar
  1 sibling, 0 replies; 13+ messages in thread
From: Corey Ashford @ 2010-03-12  6:53 UTC (permalink / raw)
  To: Paul Mackerras
  Cc: Ingo Molnar, LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt

On 03/11/2010 06:41 PM, Paul Mackerras 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.

Yes, that's what I meant.

 > I don't see how ftrace tracepoint events are relevant to
 > that.
>
> Now as to whether an external .so is the best way to provide the
> processor-specific mapping of names to raw events, I'm not sure.
> If the kernel can provide that mapping via procfs, sysfs or eventfs,
> that would be an alternative, but it does mean the kernel has those
> tables in unswappable memory (and potentially the tables for all the
> processors that the kernel supports), which seems unnecessary.  Or
> they can just be added to the perf source code.

In addition to the names and attributes, we'd also need text-based 
descriptions of the events and attributes.

I'm not opposed to the idea of placing them in sysfs (or other pseudo 
fs), but it's also not clear to me how to represent the event data in a 
clean, extensible, and space/performance efficient way.  That said, I do 
like the idea of being able to navigate events by looking through a 
directory structure which is possibly organized by the physical topology 
of the system and its PMUs.

- Corey



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-11 20:46         ` Corey Ashford
@ 2010-03-15 23:38           ` Corey Ashford
  2010-03-16  9:40             ` Ingo Molnar
  0 siblings, 1 reply; 13+ messages in thread
From: Corey Ashford @ 2010-03-15 23:38 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt

On 3/11/2010 12:46 PM, Corey Ashford wrote:
>
>
> On 3/11/2010 11:14 AM, Ingo Molnar wrote:
>>
>> * Corey Ashford<cjashfor@linux.vnet.ibm.com> wrote:
> [snip]
>>> 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?
>
> Here are a few examples for the Power A2 processor. I've distorted the
> names because PMU architecture isn't publicly released yet.
>
> PM_DE_PMC_9:hrd_mask=0xff:hrd=0x22:pma_mask=0x3fff:pma=0x1b2d:culling_mode=3
>
> PM_EX_0x03:lane=2:vlane=1
> PM_OWE_ENG_MAC_FULL:usu=3

Just a follow-up note to this...

I learned that the much of the high-level architecture of the new chip that IBM 
is working on has been publicly released recently, so I have "undistorted" the 
event names below:

PM_DC_PMC_9:lpid_mask=0xff:lpid=0x22:pid_mask=0x3fff:pid=0x1b2d:marking_mode=3
PM_REGX_0x03:lane=2:vlane=1
PM_XML_ENG_MAC_FULL:sus=3


DC = Decompression/Compression accelerator
PMC_9 = Peformance monitoring event 9
REGX = Regular eXpression accelerator
XML = XML parsing accelerator
pid = process id to match
pid_mask = process id match mask
lpid = logical partition id
lpid_mask = logical partition id mask
sus = source unit select
lane, vlane = signal routing fields
marking_mode = used to determine which accelerator work units to mark for 
performance monitoring

- Corey


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-12  2:41     ` Paul Mackerras
  2010-03-12  6:53       ` Corey Ashford
@ 2010-03-16  9:34       ` Ingo Molnar
  1 sibling, 0 replies; 13+ messages in thread
From: Ingo Molnar @ 2010-03-16  9:34 UTC (permalink / raw)
  To: Paul Mackerras
  Cc: Corey Ashford, LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt


* 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-15 23:38           ` Corey Ashford
@ 2010-03-16  9:40             ` Ingo Molnar
  2010-03-16 18:24               ` Corey Ashford
  0 siblings, 1 reply; 13+ messages in thread
From: Ingo Molnar @ 2010-03-16  9:40 UTC (permalink / raw)
  To: Corey Ashford
  Cc: LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt,
	Arnaldo Carvalho de Melo


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

> On 3/11/2010 12:46 PM, Corey Ashford wrote:
> >
> >
> >On 3/11/2010 11:14 AM, Ingo Molnar wrote:
> >>
> >>* Corey Ashford<cjashfor@linux.vnet.ibm.com> wrote:
> >[snip]
> >>>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?
> >
> >Here are a few examples for the Power A2 processor. I've distorted the
> >names because PMU architecture isn't publicly released yet.
> >
> >PM_DE_PMC_9:hrd_mask=0xff:hrd=0x22:pma_mask=0x3fff:pma=0x1b2d:culling_mode=3
> >
> >PM_EX_0x03:lane=2:vlane=1
> >PM_OWE_ENG_MAC_FULL:usu=3
> 
> Just a follow-up note to this...
> 
> I learned that the much of the high-level architecture of the new
> chip that IBM is working on has been publicly released recently, so
> I have "undistorted" the event names below:
> 
> PM_DC_PMC_9:lpid_mask=0xff:lpid=0x22:pid_mask=0x3fff:pid=0x1b2d:marking_mode=3
> PM_REGX_0x03:lane=2:vlane=1
> PM_XML_ENG_MAC_FULL:sus=3
> 
> 
> DC = Decompression/Compression accelerator
> PMC_9 = Peformance monitoring event 9
> REGX = Regular eXpression accelerator
> XML = XML parsing accelerator
> pid = process id to match
> pid_mask = process id match mask
> lpid = logical partition id
> lpid_mask = logical partition id mask
> sus = source unit select
> lane, vlane = signal routing fields
> marking_mode = used to determine which accelerator work units to
> mark for performance monitoring

Are these special-purpose instructions for compression/regex/xml-parsing 
speedups?

I think it would be rather useful to merge the hw (and sw) perf events with 
the ftrace/tracepoints symbolic events space. That would be a one-stop-shop 
for both perf and other tools to figure out the events we offer, their 
characteristics, format, relationship to other events, etc.

	Ingo

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
  2010-03-16  9:40             ` Ingo Molnar
@ 2010-03-16 18:24               ` Corey Ashford
  0 siblings, 0 replies; 13+ messages in thread
From: Corey Ashford @ 2010-03-16 18:24 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: LKML, Peter Zijlstra, Frederic Weisbecker, Steven Rostedt,
	Arnaldo Carvalho de Melo

On 3/16/2010 2:40 AM, Ingo Molnar wrote:
>
> * Corey Ashford<cjashfor@linux.vnet.ibm.com>  wrote:
>
>> On 3/11/2010 12:46 PM, Corey Ashford wrote:
>>>
>>>
>>> On 3/11/2010 11:14 AM, Ingo Molnar wrote:
>>>>
>>>> * Corey Ashford<cjashfor@linux.vnet.ibm.com>  wrote:
>>> [snip]
>>>>> 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?
>>>
>>> Here are a few examples for the Power A2 processor. I've distorted the
>>> names because PMU architecture isn't publicly released yet.
>>>
>>> PM_DE_PMC_9:hrd_mask=0xff:hrd=0x22:pma_mask=0x3fff:pma=0x1b2d:culling_mode=3
>>>
>>> PM_EX_0x03:lane=2:vlane=1
>>> PM_OWE_ENG_MAC_FULL:usu=3
>>
>> Just a follow-up note to this...
>>
>> I learned that much of the high-level architecture of the new
>> chip that IBM is working on has been publicly released recently, so
>> I have "undistorted" the event names below:
>>
>> PM_DC_PMC_9:lpid_mask=0xff:lpid=0x22:pid_mask=0x3fff:pid=0x1b2d:marking_mode=3
>> PM_REGX_0x03:lane=2:vlane=1
>> PM_XML_ENG_MAC_FULL:sus=3
>>
>>
>> DC = Decompression/Compression accelerator
>> PMC_9 = Peformance monitoring event 9
>> REGX = Regular eXpression accelerator
>> XML = XML parsing accelerator
>> pid = process id to match
>> pid_mask = process id match mask
>> lpid = logical partition id
>> lpid_mask = logical partition id mask
>> sus = source unit select
>> lane, vlane = signal routing fields
>> marking_mode = used to determine which accelerator work units to
>> mark for performance monitoring
>
> Are these special-purpose instructions for compression/regex/xml-parsing
> speedups?

No, these events are for nest (aka uncore) accelerators for 
compression/regex/xml-parsing.  These accelerators operate independently of the 
CPU threads and are given work units via request blocks which are then queued up 
by the accelerator.

>
> I think it would be rather useful to merge the hw (and sw) perf events with
> the ftrace/tracepoints symbolic events space. That would be a one-stop-shop
> for both perf and other tools to figure out the events we offer, their
> characteristics, format, relationship to other events, etc.
>
> 	Ingo

Ok, I will look into this.  Thank you for your advice.

- Corey


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2010-03-16 18:24 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2010-03-05 17:42 ` Corey Ashford

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.