lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ