* stephane eranian <eran...@googlemail.com> wrote:
> On Thu, Oct 8, 2009 at 10:08 PM, Ingo Molnar <mi...@elte.hu> wrote:
> >
> > * David Miller <da...@davemloft.net> wrote:
> >
> >> From: stephane eranian <eran...@googlemail.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
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
