Stephane Eranian wrote:
On Wed, Jan 10, 2007 at 10:11:00AM -0500, William Cohen wrote:
Philip J. Mucci wrote:
HI Stefane,
Couldn't all this be solved by having opcontrol/ophelp use the pfmlib
event tables directory and ignoring everything in the events directory
of oprofile?
Phil
This would simplify things. OProfile does allow user to look at the events
of architectures other than the one that the user is currently on. libpfm
doesn't currently support that type of operation. libpfm only provides
Well, libpfm almost does. there is a pfm_force_pmu() call. You have to
pass a valid libpfm PMU type. The current implementation verifies that
what you chose works on the current HW but we can certainly remove that
check given that libpfm does not actually touch HW.
But how would switch over to libpfm solve the issues I raised in my
previous message and especially the backward compatibility with existing
scripts/tools built on top on OProfile.
I was thinking functionality parity. OProfile allows people to find out what
events and masks are available without actually initializing the performance
monitoring system. It is minor, but there have been times when I have used this
to look up events.
This summer for the consistent naming there was a revision of the AMD64 event
names to match up with the processor event names in documentation. There were
some similar steps for the Core processor event names. These changes in oprofile
cause some problem with backward compatibility. How different are the pfmlib
names from the documented names? For the power4/5/6 the names would be very
different. The group information is included in the name itself for oprofile. It
would be saner to move to the libpfm approach and simplify the event naming for
power.
-Will
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
