On Fri, Aug 27, 2004 at 04:33:20PM -0400, Yaoping Ruan wrote:
> I agree that having the synthetic events in userspace probably is the
> best way to go.
> But from what I observed, and compared to other performance counter
> tools such as perfctr+PAPI, and others, I though Oprofile doesn't want
> to bring out synthetic events to the first place.
This isn't the case.
> An evidence of this is that every event in Oprofile is exactly the
> original shape as in the Intel manual.
This is true, mainly because Intel managed to keep their perfctr
configuration at least vaguely sane until the P4, where, as you know,
they made it unusably complicated.
> Otherwise, providing these events
> such as REPLAY_EVNETS, EXECUTION_EVENTS, and FRONT_END_EVENTS doesn't
> make any sense. They don't work alone at all.
And indeed, this is an existing bug that was overlooked in the initial
integration of P4 support. They're wrong and they have to go.
> in the list but doing any real work is simply confusing. (To be honest, I
> spent quite a lot time figuring it out that they doesn't make sense alone)
Minimally, they should be removed.
> well, of course I agree that providing users with the most straight
> forward events is the best way. But in that way, some of the unit mask
> won't be compatible with Intel's manual. Or in other words, some of the
> unit mask in Oprofile will have different meaning than the unit mask in
> the manual. So it is your dicision now.
We need to make clear that these are synthetic events, and document
somewhere how they actually map into the real hardware setup.
> Maybe it is worthy to bring another topic now. There are couple of new
> events on P4 which need two more registers, IA32_PENS_ENABLE and
> MSR_PENS_MATRIX_VERT, (please refer to Intel manual: IA-32 Intel
> Architecture Software Developer's Manual, Volume 3: System Programming
> Guide, Table A-6) and both of them needs some mask for different
> events. So maybe it is better to think about these events as well. Again,
> I'd better ask you for user interface first.
I haven't looked but I imagine we just need some more synthetic events
again designed in a user-friendly manner.
As it is, it looks like your changes will need incompatible kernel
changes (it's impossible to avoid just additions to kernel space, right
?). With the new kernel development policy, I have no idea when we
can actually make this change. But when we do, we should make sure it
only happens once.
So if you're interested in doing the work on these synthetic events to
support what's currently not handled, I strongly encourage you to do so,
and we'll work out a schedule for how it can be integrated.
One alternative, if deemed necessary, would be to version the
/dev/oprofile/cpu_type file so we can pick between the older events
setup, and a new, fixed, version.