perf: Add a few generic stalled-cycles events

From 89cb6a25b9f714e55a379467a832ee015014ed11 Mon Sep 17 00:00:00 2001

From: Sukadev Bhattiprolu <redacted>
Date: Tue, 18 Sep 2012 10:59:01 -0700
Subject: [PATCH] perf: Add a few generic stalled-cycles events

The existing generic event 'stalled-cycles-backend' corresponds to
PM_CMPLU_STALL event in Power7. While this event is useful, detailed
performance analysis often requires us to find more specific reasons
for the stalled cycle. For instance, stalled cycles in Power7 can
occur due to, among others:

	- instruction fetch unit (IFU),
	- Load-store-unit (LSU),
	- Fixed point unit (FXU)
	- Branch unit (BRU)

While it is possible to use raw codes to monitor these events, it quickly
becomes cumbersome with performance analysis frequently requiring mapping
the raw event codes in reports to their symbolic names.

This patch is a proposal to try and generalize such perf events. Since
the code changes are quite simple, I bunched all the 4 events together.

I am not familiar with how readily these events would map to other
architectures. Here is some information on the events for Power7:

	stalled-cycles-fixed-point (PM_CMPLU_STALL_FXU)

		Following a completion stall, the last instruction to finish
		before completion resumes was from the Fixed Point Unit.

		Completion stall is any period when no groups completed and
		the completion table was not empty for that thread.

	stalled-cycles-load-store (PM_CMPLU_STALL_LSU)

		Following a completion stall, the last instruction to finish
		before completion resumes was from the Load-Store Unit.

	stalled-cycles-instruction-fetch (PM_CMPLU_STALL_IFU)

29 more lines

diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 1251e4d..813e7c7 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c

@@ -304,6 +304,10 @@ static int power7_generic_events[] = {
 	[PERF_COUNT_HW_CACHE_MISSES] = 0x400f0,		/* LD_MISS_L1	*/
 	[PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x10068,	/* BRU_FIN	*/
 	[PERF_COUNT_HW_BRANCH_MISSES] = 0x400f6,	/* BR_MPRED	*/
+	[PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT] = 0x20014,/* CMPLU_STALL_FXU */
+	[PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE] = 0x20012,/* CMPLU_STALL_LSU */
+	[PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH] = 0x4004c,/* CMPLU_STALL_IFU */
+	[PERF_COUNT_HW_STALLED_CYCLES_BRANCH] = 0x4004e,/* CMPLU_STALL_BRU */
 };
 
 #define C(x)	PERF_COUNT_HW_CACHE_##x

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index bdb4161..ff9f0a6 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h

@@ -55,6 +55,10 @@ enum perf_hw_id {
 	PERF_COUNT_HW_STALLED_CYCLES_FRONTEND	= 7,
 	PERF_COUNT_HW_STALLED_CYCLES_BACKEND	= 8,
 	PERF_COUNT_HW_REF_CPU_CYCLES		= 9,
+	PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT = 10,
+	PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE	= 11,
+	PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH = 12,
+	PERF_COUNT_HW_STALLED_CYCLES_BRANCH	= 13,
 
 	PERF_COUNT_HW_MAX,			/* non-ABI */
 };

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 861f0ae..6275dbb 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c

@@ -77,6 +77,10 @@ static struct perf_event_attr default_attrs[] = {
   { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_INSTRUCTIONS		},
   { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_BRANCH_INSTRUCTIONS	},
   { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_BRANCH_MISSES		},
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_BRANCH },
 
 };
 

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 2eaae14..17e3190 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c

@@ -77,6 +77,10 @@ static const char *perf_evsel__hw_names[PERF_COUNT_HW_MAX] = {
 	"stalled-cycles-frontend",
 	"stalled-cycles-backend",
 	"ref-cycles",
+	"stalled-cycles-fixed-point",
+	"stalled-cycles-load-store",
+	"stalled-cycles-instruction-fetch",
+	"stalled-cycles-branch",
 };
 
 static const char *__perf_evsel__hw_name(u64 config)

diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 384ca74..0c49c05 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l

@@ -102,6 +102,10 @@ branch-instructions|branches			{ return sym(yyscanner, PERF_TYPE_HARDWARE, PERF_
 branch-misses					{ return sym(yyscanner, PERF_TYPE_HARDWARE, PERF_COUNT_HW_BRANCH_MISSES); }
 bus-cycles					{ return sym(yyscanner, PERF_TYPE_HARDWARE, PERF_COUNT_HW_BUS_CYCLES); }
 ref-cycles					{ return sym(yyscanner, PERF_TYPE_HARDWARE, PERF_COUNT_HW_REF_CPU_CYCLES); }
+stalled-cycles-fixed-point			{ return sym(yyscanner, PERF_TYPE_HARDWARE, PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT); }
+stalled-cycles-load-store			{ return sym(yyscanner, PERF_TYPE_HARDWARE, PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE); }
+stalled-cycles-instruction-fetch		{ return sym(yyscanner, PERF_TYPE_HARDWARE, PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH); }
+stalled-cycles-branch				{ return sym(yyscanner, PERF_TYPE_HARDWARE, PERF_COUNT_HW_STALLED_CYCLES_BRANCH); }
 cpu-clock					{ return sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_CPU_CLOCK); }
 task-clock					{ return sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_TASK_CLOCK); }
 page-faults|faults				{ return sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_PAGE_FAULTS); }

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index 0688bfb..c563b30 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c

@@ -952,6 +952,10 @@ static struct {
 
 	{ "COUNT_HW_STALLED_CYCLES_FRONTEND",	  PERF_COUNT_HW_STALLED_CYCLES_FRONTEND },
 	{ "COUNT_HW_STALLED_CYCLES_BACKEND",	  PERF_COUNT_HW_STALLED_CYCLES_BACKEND },
+	{ "COUNT_HW_STALLED_CYCLES_FIXED_POINT",  PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
+	{ "COUNT_HW_STALLED_CYCLES_LOAD_STORE",  PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
+	{ "COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH",  PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
+	{ "COUNT_HW_STALLED_CYCLES_BRANCH",  PERF_COUNT_HW_STALLED_CYCLES_BRANCH },
 
 	{ "COUNT_SW_CPU_CLOCK",	       PERF_COUNT_SW_CPU_CLOCK },
 	{ "COUNT_SW_TASK_CLOCK",       PERF_COUNT_SW_TASK_CLOCK },

-- 
1.7.1

On 10/12/2012 06:58 AM, Sukadev Bhattiprolu wrote:

From 89cb6a25b9f714e55a379467a832ee015014ed11 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <redacted>
Date: Tue, 18 Sep 2012 10:59:01 -0700
Subject: [PATCH] perf: Add a few generic stalled-cycles events

The existing generic event 'stalled-cycles-backend' corresponds to
PM_CMPLU_STALL event in Power7. While this event is useful, detailed
performance analysis often requires us to find more specific reasons
for the stalled cycle. For instance, stalled cycles in Power7 can
occur due to, among others:

	- instruction fetch unit (IFU),
	- Load-store-unit (LSU),
	- Fixed point unit (FXU)
	- Branch unit (BRU)

While it is possible to use raw codes to monitor these events, it quickly
becomes cumbersome with performance analysis frequently requiring mapping
the raw event codes in reports to their symbolic names.

This patch is a proposal to try and generalize such perf events. Since
the code changes are quite simple, I bunched all the 4 events together.

I am not familiar with how readily these events would map to other
architectures. Here is some information on the events for Power7:

	stalled-cycles-fixed-point (PM_CMPLU_STALL_FXU)

		Following a completion stall, the last instruction to finish
		before completion resumes was from the Fixed Point Unit.

		Completion stall is any period when no groups completed and
		the completion table was not empty for that thread.

	stalled-cycles-load-store (PM_CMPLU_STALL_LSU)

		Following a completion stall, the last instruction to finish
		before completion resumes was from the Load-Store Unit.

20 more quoted lines

Here we should try to come up with a generic list of places in the processor where
the cycles can stall.

PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT
PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE
PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH
PERF_COUNT_HW_STALLED_CYCLES_BRANCH
PERF_COUNT_HW_STALLED_CYCLES_<ANY_OTHER_PLACE1>
PERF_COUNT_HW_STALLED_CYCLES_<ANY_OTHER_PLACE2>
PERF_COUNT_HW_STALLED_CYCLES_<ANY_OTHER_PLACE3>
-----------------------------------------------

This generic list can be a superset which can accommodate all the architecture
giving the flexibility to implement selectively there after. Stall locations are
very important from CPI analysis stand point with real world use cases. This will
definitely help us in that direction.

Regards
Anshuman

On 11.10.12 18:28:39, Sukadev Bhattiprolu wrote:

Instead of adding new hardware event types I would prefer to use raw
events in conjunction with sysfs, see e.g. the intel-uncore
implementation. Something like:

 $ find /sys/bus/event_source/devices/cpu/events/
 ...
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-load-store
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-instruction-fetch
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-branch
 ...
 $ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
 event=0xff,umask=0x00

Perf tool works then out-of-the-box with:

 $ perf record -e cpu/stalled-cycles-fixed-point/ ...

The event string can easily be reused by other architectures as a
quasi standard.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

On 10/15/12 8:55 AM, Robert Richter wrote:

[..]

Perf tool works then out-of-the-box with:

  $ perf record -e cpu/stalled-cycles-fixed-point/ ...

The event string can easily be reused by other architectures as a
quasi standard.

I like Robert's proposal better. It's hard to model all the stall events (eg: instruction decoder related stalls on x86) in a hardware independent way.

Another area to think about: software engineers are generally busy and have a limited amount of time to devote to hardware event based optimizations. The most common question I hear is: what is the expected perf gain if I fix this? It's hard to answer that with just the stall events.

 -Arun

On 10/15/2012 10:53 PM, Arun Sharma wrote:

On 10/15/12 8:55 AM, Robert Richter wrote:

[..]

quoted

Perf tool works then out-of-the-box with:

  $ perf record -e cpu/stalled-cycles-fixed-point/ ...

The event string can easily be reused by other architectures as a
quasi standard.

I like Robert's proposal better. It's hard to model all the stall events
(eg: instruction decoder related stalls on x86) in a hardware
independent way.

Another area to think about: software engineers are generally busy and
have a limited amount of time to devote to hardware event based
optimizations. The most common question I hear is: what is the expected
perf gain if I fix this? It's hard to answer that with just the stall
events.

Hardware event based optimization is a very important aspect of real world application
tuning. CPI stack analysis is a good reason why perf should have stall events as generic
ones. But I am not clear on situations where we consider adding these new generic events
into linux/perf_event.h and the situations where we should go with the sys fs interface.
Could you please elaborate on this ?

Regards
Anshuman

Sukadev,

On 15.10.12 17:55:34, Robert Richter wrote:

On 11.10.12 18:28:39, Sukadev Bhattiprolu wrote:

quoted

+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_BRANCH },

Instead of adding new hardware event types I would prefer to use raw
events in conjunction with sysfs, see e.g. the intel-uncore
implementation. Something like:

 $ find /sys/bus/event_source/devices/cpu/events/
 ...
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-load-store
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-instruction-fetch
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-branch
 ...
 $ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
 event=0xff,umask=0x00

Perf tool works then out-of-the-box with:

 $ perf record -e cpu/stalled-cycles-fixed-point/ ...

I refer here to arch/x86/kernel/cpu/perf_event_intel_uncore.c (should
be in v3.7-rc1 or tip:perf/core). See the INTEL_UNCORE_EVENT_DESC()
macro and 'if (type->event_descs) ...' in uncore_type_init(). The code
should be reworked to be non-architectural.

PMU registration is implemented for a longer time already for all
architectures and pmu types:

 /sys/bus/event_source/devices/*

But

 /sys/bus/event_source/devices/*/events/

exists only for a small number of pmus. Perf tool support of this was
implemented with:

 a6146d5 perf/tool: Add PMU event alias support

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

On Tue, Oct 16, 2012 at 12:08 PM, Robert Richter [off-list ref] wrote:

Sukadev,

On 15.10.12 17:55:34, Robert Richter wrote:

quoted

On 11.10.12 18:28:39, Sukadev Bhattiprolu wrote:

quoted

+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
+  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_BRANCH },

Instead of adding new hardware event types I would prefer to use raw
events in conjunction with sysfs, see e.g. the intel-uncore
implementation. Something like:

In general, I don't like generic events and especially stall events. I
have not seen a clear definition of
what they mean. Without it, there is no way to understand how to map
them across architecture. If
the definition is too precise, you may not be able to find an exact
mapping. If the definition is to loose
then it is unclear what you are measuring.

Also this opens another can of worms which is that on some processors,
you may need more than
one event to encapsulate what the generic event is supposed to
measure. That means developing
a lot of code in the kernel to express and manage that. And of course,
you would not be able
to sample on those events (you cannot sample on a difference, for
instance). So all in all, I think
this is not a very good idea. You have to put this into the tool or a
library that auto-detects the
host CPU and programs the right set of events.

We've had that discussion many times. Just reiterating my personal
opinion on this.

quoted

 $ find /sys/bus/event_source/devices/cpu/events/
 ...
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-load-store
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-instruction-fetch
 /sys/bus/event_source/devices/cpu/events/stalled-cycles-branch
 ...
 $ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
 event=0xff,umask=0x00

Perf tool works then out-of-the-box with:

 $ perf record -e cpu/stalled-cycles-fixed-point/ ...

I refer here to arch/x86/kernel/cpu/perf_event_intel_uncore.c (should
be in v3.7-rc1 or tip:perf/core). See the INTEL_UNCORE_EVENT_DESC()
macro and 'if (type->event_descs) ...' in uncore_type_init(). The code
should be reworked to be non-architectural.

PMU registration is implemented for a longer time already for all
architectures and pmu types:

 /sys/bus/event_source/devices/*

But

 /sys/bus/event_source/devices/*/events/

exists only for a small number of pmus. Perf tool support of this was
implemented with:

 a6146d5 perf/tool: Add PMU event alias support

-Robert

--
Advanced Micro Devices, Inc.
Operating System Research Center

Robert Richter [robert.richter@amd.com] wrote:
| Sukadev,
| 
| On 15.10.12 17:55:34, Robert Richter wrote:
| > On 11.10.12 18:28:39, Sukadev Bhattiprolu wrote:
| > > +  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
| > > +  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
| > > +  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
| > > +  { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_BRANCH },
| > 
| > Instead of adding new hardware event types I would prefer to use raw
| > events in conjunction with sysfs, see e.g. the intel-uncore
| > implementation. Something like:
| > 
| >  $ find /sys/bus/event_source/devices/cpu/events/
| >  ...
| >  /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
| >  /sys/bus/event_source/devices/cpu/events/stalled-cycles-load-store
| >  /sys/bus/event_source/devices/cpu/events/stalled-cycles-instruction-fetch
| >  /sys/bus/event_source/devices/cpu/events/stalled-cycles-branch
| >  ...
| >  $ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
| >  event=0xff,umask=0x00
| > 
| > Perf tool works then out-of-the-box with:
| > 
| >  $ perf record -e cpu/stalled-cycles-fixed-point/ ...
| 
| I refer here to arch/x86/kernel/cpu/perf_event_intel_uncore.c (should
| be in v3.7-rc1 or tip:perf/core). See the INTEL_UNCORE_EVENT_DESC()
| macro and 'if (type->event_descs) ...' in uncore_type_init(). The code
| should be reworked to be non-architectural.


Ok. I will look through that code. Does that mean we are trying to avoid
any more new hardware generic events ?

Also a broader question - is the sysfs approach intended for all raw events
or just for the generic events supported in the kernel ?

54 more lines

Stephane Eranian [eranian@google.com] wrote:
| So all in all, I think this is not a very good idea. You have to put
| this into the tool or a library that auto-detects the
| host CPU and programs the right set of events.
| 
| We've had that discussion many times. Just reiterating my personal
| opinion on this.

Yes that would work too. One drawback is that the hardware events
will be in the tool, while the software/tracepoint events in the
kernel sysfs representation.

Or is that the reason we want all events in one place (sysfs) ?

Sukadev

On Tue, 2012-10-16 at 11:31 -0700, Sukadev Bhattiprolu wrote:

On a side note, how does the kernel on x86 use the 'config' information i=

n=20

say /sys/bus/event_source/devices/cpu/format/cccr ? On Power7, the raw
code encodes the information such as the PMC to use for the event. Is tha=

t

how the 'config' info in Intel is used ?
=20
Does the 'config' info change from system to system or is it static for
a given event on a given CPU ?=20

Have a look at commits (tip/master):

  641cc938815dfd09f8fa1ec72deb814f0938ac33
  a47473939db20e3961b200eb00acf5fcf084d755
  43c032febde48aabcf6d59f47cdcb7b5debbdc63


So basically

 /sys/bus/event_source/devices/cpu/format/event

contains something like:

  config:0-7

Which says that for the 'cpu' PMU, field 'event' fills
perf_event_attr::config bits 0 through 7 (for type=3DPERF_TYPE_RAW).

The perf tool syntax for this is:

  perf stat -e 'cpu/event=3D0x3c/'

This basically allows you to expose bitfields in the 'raw' event format
for ease of writing raw events. I do not know if the Power PMU has such
or not.

Using this,

  /sys/bus/event_source/devices/cpu/events/cpu-cycles

would contain something like:

  event=3D0x3c

which one can use as:

  perf stat -e 'cpu/event=3Dcpu-cycles/'
  perf stat -e 'cpu/cpu-cycles/'

19 more lines

Peter Zijlstra [peterz@infradead.org] wrote:
| On Tue, 2012-10-16 at 11:31 -0700, Sukadev Bhattiprolu wrote:
| > On a side note, how does the kernel on x86 use the 'config' information in 
| > say /sys/bus/event_source/devices/cpu/format/cccr ? On Power7, the raw
| > code encodes the information such as the PMC to use for the event. Is that
| > how the 'config' info in Intel is used ?
| > 
| > Does the 'config' info change from system to system or is it static for
| > a given event on a given CPU ? 
| 
| Have a look at commits (tip/master):
| 
|   641cc938815dfd09f8fa1ec72deb814f0938ac33
|   a47473939db20e3961b200eb00acf5fcf084d755
|   43c032febde48aabcf6d59f47cdcb7b5debbdc63
| 
| 
| So basically
| 
|  /sys/bus/event_source/devices/cpu/format/event
| 
| contains something like:
| 
|   config:0-7
| 
| Which says that for the 'cpu' PMU, field 'event' fills
| perf_event_attr::config bits 0 through 7 (for type=PERF_TYPE_RAW).
| 
| The perf tool syntax for this is:
| 
|   perf stat -e 'cpu/event=0x3c/'
| 
| This basically allows you to expose bitfields in the 'raw' event format
| for ease of writing raw events. I do not know if the Power PMU has such
| or not.

Thanks for the detailed explanation.

Power does not support this yet, but I have started working on it now.

10 more lines

On Tue, 2012-10-30 at 23:40 -0700, Sukadev Bhattiprolu wrote:

So instead of the names I came up with in this patch, stalled-cycles-fixe=

d-point

we could use the name used in the CPU spec - 'cmplu_stall_fxu' in the arc=

h

specific code ?=20

You could, but I would advise against it. Human readable names are so
much more accessible.