[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090710093757.GG27445@elte.hu>
Date: Fri, 10 Jul 2009 11:37:57 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Anton Blanchard <anton@...ba.org>
Cc: a.p.zijlstra@...llo.nl, paulus@...ba.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf_counter: Add alignment-faults and
emulation-faults sw events
* Anton Blanchard <anton@...ba.org> 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@...ba.org>
> ---
>
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists