Add two software events that are common to many cpus:
Alignment faults: When a load or store is not aligned properly and must be
performed by the kernel.
Emulation faults: When an instruction must be emulated by the kernel.
Both cause a very significant slowdown (potentially 100x or worse), so
identifying and fixing them is very important.
Signed-off-by: Anton Blanchard <[email protected]>
---
Index: linux.trees.git/include/linux/perf_counter.h
===================================================================
--- linux.trees.git.orig/include/linux/perf_counter.h 2009-07-06 21:50:53.000000000 +1000
+++ linux.trees.git/include/linux/perf_counter.h 2009-07-06 21:51:18.000000000 +1000
@@ -102,6 +102,8 @@
PERF_COUNT_SW_CPU_MIGRATIONS = 4,
PERF_COUNT_SW_PAGE_FAULTS_MIN = 5,
PERF_COUNT_SW_PAGE_FAULTS_MAJ = 6,
+ PERF_COUNT_SW_ALIGNMENT_FAULTS = 7,
+ PERF_COUNT_SW_EMULATION_FAULTS = 8,
PERF_COUNT_SW_MAX, /* non-ABI */
};
Index: linux.trees.git/kernel/perf_counter.c
===================================================================
--- linux.trees.git.orig/kernel/perf_counter.c 2009-07-06 21:50:53.000000000 +1000
+++ linux.trees.git/kernel/perf_counter.c 2009-07-06 21:51:18.000000000 +1000
@@ -3754,6 +3754,8 @@
case PERF_COUNT_SW_PAGE_FAULTS_MAJ:
case PERF_COUNT_SW_CONTEXT_SWITCHES:
case PERF_COUNT_SW_CPU_MIGRATIONS:
+ case PERF_COUNT_SW_ALIGNMENT_FAULTS:
+ case PERF_COUNT_SW_EMULATION_FAULTS:
if (!counter->parent) {
atomic_inc(&perf_swcounter_enabled[event]);
counter->destroy = sw_perf_counter_destroy;
Index: linux.trees.git/tools/perf/design.txt
===================================================================
--- linux.trees.git.orig/tools/perf/design.txt 2009-07-06 21:50:53.000000000 +1000
+++ linux.trees.git/tools/perf/design.txt 2009-07-06 21:51:18.000000000 +1000
@@ -137,6 +137,8 @@
PERF_COUNT_SW_CPU_MIGRATIONS = 4,
PERF_COUNT_SW_PAGE_FAULTS_MIN = 5,
PERF_COUNT_SW_PAGE_FAULTS_MAJ = 6,
+ PERF_COUNT_SW_ALIGNMENT_FAULTS = 7,
+ PERF_COUNT_SW_EMULATION_FAULTS = 8,
};
Counters of the type PERF_TYPE_TRACEPOINT are available when the ftrace event
Index: linux.trees.git/tools/perf/util/parse-events.c
===================================================================
--- linux.trees.git.orig/tools/perf/util/parse-events.c 2009-07-06 21:51:12.000000000 +1000
+++ linux.trees.git/tools/perf/util/parse-events.c 2009-07-06 21:51:18.000000000 +1000
@@ -38,6 +38,8 @@
{ CSW(PAGE_FAULTS_MAJ), "major-faults", "" },
{ CSW(CONTEXT_SWITCHES), "context-switches", "cs" },
{ CSW(CPU_MIGRATIONS), "cpu-migrations", "migrations" },
+ { CSW(ALIGNMENT_FAULTS), "alignment-faults", "" },
+ { CSW(EMULATION_FAULTS), "emulation-faults", "" },
};
#define __PERF_COUNTER_FIELD(config, name) \
@@ -66,6 +68,8 @@
"CPU-migrations",
"minor-faults",
"major-faults",
+ "alignment-faults",
+ "emulation-faults",
};
#define MAX_ALIASES 8
* Anton Blanchard <[email protected]> wrote:
> Add two software events that are common to many cpus:
>
> Alignment faults: When a load or store is not aligned properly and
> must be performed by the kernel.
>
> Emulation faults: When an instruction must be emulated by the
> kernel.
>
> Both cause a very significant slowdown (potentially 100x or
> worse), so identifying and fixing them is very important.
>
> Signed-off-by: Anton Blanchard <[email protected]>
> ---
>
> Index: linux.trees.git/include/linux/perf_counter.h
> ===================================================================
> --- linux.trees.git.orig/include/linux/perf_counter.h 2009-07-06 21:50:53.000000000 +1000
> +++ linux.trees.git/include/linux/perf_counter.h 2009-07-06 21:51:18.000000000 +1000
> @@ -102,6 +102,8 @@
> PERF_COUNT_SW_CPU_MIGRATIONS = 4,
> PERF_COUNT_SW_PAGE_FAULTS_MIN = 5,
> PERF_COUNT_SW_PAGE_FAULTS_MAJ = 6,
> + PERF_COUNT_SW_ALIGNMENT_FAULTS = 7,
> + PERF_COUNT_SW_EMULATION_FAULTS = 8,
Looks useful.
I'm wondering about the enumeration space: in other cases when some
simple event was further refined we went to add a new perf_type_id
and a separate enumeration space, with no limits to extensibility.
We'd have a new 'enum perf_sw_fault_id' space.
Page faults are special anyway, because they carry a 'data'
(faulting address) sample as well.
So i'm wondering how a good, generic enumeration of all things page
faults would look like. If we extend perf_sw_ids linearly we might
lose some structure.
For example major versus minor might be a dimension (bit) in the
enumeration space, so we'd have:
{ major | minor } x { native, unaligned, emulated }
This provides an advantage already: the current 'all' page faults
counter would become the 'major|minor' case in the new enumeration.
We could still keep around the old events as well for some time, but
the tools would use the new enumeration.
Hm?
Ingo
Hi Ingo,
> Looks useful.
>
> I'm wondering about the enumeration space: in other cases when some
> simple event was further refined we went to add a new perf_type_id
> and a separate enumeration space, with no limits to extensibility.
> We'd have a new 'enum perf_sw_fault_id' space.
>
> Page faults are special anyway, because they carry a 'data'
> (faulting address) sample as well.
>
> So i'm wondering how a good, generic enumeration of all things page
> faults would look like. If we extend perf_sw_ids linearly we might
> lose some structure.
>
> For example major versus minor might be a dimension (bit) in the
> enumeration space, so we'd have:
>
> { major | minor } x { native, unaligned, emulated }
>
> This provides an advantage already: the current 'all' page faults
> counter would become the 'major|minor' case in the new enumeration.
>
> We could still keep around the old events as well for some time, but
> the tools would use the new enumeration.
My initial feeling is that emulation and alignment faults shouldn't
roll up into page faults, because that may cause cause someone to think the
problem is something to do with translation. I don't have a strong opinion
on it however :)
Since we are talking about SW events, I thought I'd bring up some ideas
I was discussing with Paul the other day. The hardware guys like to build
CPI stacks, basically breaking down the CPI into its components (CPI due
to TLB misses, CPI due to dcache misses etc). This offers a great
high level view of what needs to be fixed in order to improve performance.
Taking a step back, it would be great if we could have enough SW
events and counters to be able to do this at the kernel level. A few
events/counters that come to mind are cputime lost due to swap, IO
initiated by the process, interrupts and other processes being scheduled.
I wonder if the delay accounting code has anything we can reuse for this.
With these events we could simply run perf stat and instantly see what
needs fixing at both the cpu level (via CPI analysis) and at the kernel
level (via SW counters).
Anton
* Anton Blanchard <[email protected]> wrote:
> Hi Ingo,
>
> > Looks useful.
> >
> > I'm wondering about the enumeration space: in other cases when
> > some simple event was further refined we went to add a new
> > perf_type_id and a separate enumeration space, with no limits to
> > extensibility. We'd have a new 'enum perf_sw_fault_id' space.
> >
> > Page faults are special anyway, because they carry a 'data'
> > (faulting address) sample as well.
> >
> > So i'm wondering how a good, generic enumeration of all things
> > page faults would look like. If we extend perf_sw_ids linearly
> > we might lose some structure.
> >
> > For example major versus minor might be a dimension (bit) in the
> > enumeration space, so we'd have:
> >
> > { major | minor } x { native, unaligned, emulated }
> >
> > This provides an advantage already: the current 'all' page
> > faults counter would become the 'major|minor' case in the new
> > enumeration.
> >
> > We could still keep around the old events as well for some time,
> > but the tools would use the new enumeration.
>
> My initial feeling is that emulation and alignment faults
> shouldn't roll up into page faults, because that may cause cause
> someone to think the problem is something to do with translation.
> I don't have a strong opinion on it however :)
I have no strong feelings either so please pick the variant that
feels most natural. I do think we should try to generalize it a bit
and move it into its own enumeration space, out of the generic sw
counters - do you agree with that?
> Since we are talking about SW events, I thought I'd bring up some
> ideas I was discussing with Paul the other day. The hardware guys
> like to build CPI stacks, basically breaking down the CPI into its
> components (CPI due to TLB misses, CPI due to dcache misses etc).
> This offers a great high level view of what needs to be fixed in
> order to improve performance.
>
> Taking a step back, it would be great if we could have enough SW
> events and counters to be able to do this at the kernel level. A
> few events/counters that come to mind are cputime lost due to
> swap, IO initiated by the process, interrupts and other processes
> being scheduled. I wonder if the delay accounting code has
> anything we can reuse for this.
>
> With these events we could simply run perf stat and instantly see
> what needs fixing at both the cpu level (via CPI analysis) and at
> the kernel level (via SW counters).
Yeah, i like this direction.
Mind extending your patch-set in this way, and also do the more
structured pagefault enumeration thing? (unless you have better
suggestions)
Thanks,
Ingo