Re: [PATCH] perf_counter: Add alignment-faults andemulation-faults sw events

[Ingo Molnar]

* Anton Blanchard <anton@xxxxxxxxx> 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 <anton@xxxxxxxxx>
> ---
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/