linux-kernel - Re: [PATCH 2/2] perf_events: add event constraints support for Intel processors

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]

Date:	Mon, 12 Oct 2009 11:05:15 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	eranian@...il.com
Cc:	David Miller <davem@...emloft.net>, paulus@...ba.org,
	a.p.zijlstra@...llo.nl, linux-kernel@...r.kernel.org,
	perfmon2-devel@...ts.sf.net
Subject: Re: [PATCH 2/2] perf_events: add event constraints support for
	Intel processors


* stephane eranian <eranian@...glemail.com> wrote:

> On Thu, Oct 8, 2009 at 10:08 PM, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * David Miller <davem@...emloft.net> wrote:
> >
> >> From: stephane eranian <eranian@...glemail.com>
> >> Date: Wed, 7 Oct 2009 14:31:58 +0200
> >>
> >> > What PPC does is probably the only way to do this given the interface between
> >> > generic and machine-specific code. The one advantage I see is that it works
> >> > inside an event group but also across event groups because that code does not
> >> > look at group boundary, it only looks at the events and the number of available
> >> > registers. The downside is that you duplicate state.
> >> >
> >> > Did I get this right, Paul?
> >>
> >> That's basically how his code works, yes.  I intend on duplicating it
> >> to some extent on sparc64 since I'm operating in a similar problem
> >> space.
> >>
> >> So if at least some of this engine went to a generic place, there'd be
> >> at least a 3rd user :-)
> >
> > Yeah, i'd definitely suggest to generalize this. We've missed updating
> > PowerPC lowlevel details a couple of times in perf core updates, just
> > because it's in a non-obvious place. Even if it's used by just a single
> > arch, generic code is much more visible.
> >
> 
> It is not clear how you can do this without creating a monster. As I 
> said the constraints can be far more difficult than just event X => 
> allowed_counter_bitmask.

The event constraints we are interested in come from the physics of 
CPUs, not from inherent properties of particular architectures.

If you check the various constraints you'll see there's many repeating 
patterns and many of those will repeat between architectures.

Arbitrary, random constraints (that stem from design stupidity/laziness) 
can be kept at arch level, as a quirk in essence.

Spreading them all out into architecture code is the far worse solution, 
it creates a fragile distributed monster with repeating patterns - 
instead we want a manageable central monster ;-) [We are also quite good 
at controlling and shrinking monsters in the core kernel.]

So we could start all this by factoring out the sane looking bits of 
PowerPC and x86 constraints into generic helpers, and go step by step 
starting from that point.

Would you be interested in trying that, to finish what you started with 
'struct event_constraint' in arch/x86/kernel/cpu/perf_event.c?

Thanks,

	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/