Will, The last couple of days, I have been working on plugging the hole we have with perfmon and OProfile support on x86. I started with your patch and the 2.6.19 perfmon codebase.
I fixed the kernel portion to work with the latest changes, including the disappearance of UUID. I kept your /dev/oprofile/implementation. I have also completed the get_cpu_type() function to work with both x86-64 and i386. At the user level, I simplified opcontrol because we now have automatic loading of the perfmon PMU description module. I also rewrote a fair amount of opd_perfmon.c in the daemon code. I have separated the old (v2.0) IA-64 code into a new file. I fixed a couple of bugs and added detection of available PMC registers. I changed the logic so that the legacy perfmonctl() is ONLY used on IA-64 when perfmon v2.0 is detected. In other words, on IA-64 with v2.3 the new interface is used. As of today, I was able to collect samples on Opteron and my Pentium M laptop. This little exercise raised a few questions: - the code that uses the v2.3 interface (for all architectures) now relies on libpfm. You pass to pfm_dispatch_events() OProfile event names. So that assumes that OProfile and libpfm events match. I am not sure this is the case for all events on all x86 processors. We need to solve this. - In the current code the legacy v2.0 IA-64 support does not use libpfm. There is no real reason for this. The library and kernel interface are distinct. Any opinion on this? Thanks for your contributions. On Mon, Mar 27, 2006 at 11:09:57AM -0500, William Cohen wrote: > I have gotten oprofile to make use of the new perfmon2 mechanism to > collect samples. I currently have this running on my AMD64 laptop. The > oprof_perfmon2-20060327.diff patches the oprofile user space code and > perfmon2_oprof20060327.diff is for the kernel. The patches are still > "work in progress" and there are certainly things that need to be > corrected. The patches borrow heavily from the previous ia64 > oprofile/perfmon support. > > Due to the different sampling mechanism that could be used for x86, > /dev/oprofile/implement has been added so the sampling mechanism being > used can be identify how the samples are being collected. > > Rather than directly setting up the bits for the performance monitoring > hardware libpfm is used to map the name to the appropriate bits. For > processors with complicated constraints on the performance monitoring > hardware this makes more sense than trying to duplicate the constraints > mechanism in oprofile. > > Below are issues that still need to be fixed in the various areas of the > oprofile/perfmon2 monitoring. > > kernel: > - separating oprofiles processor id code from i386 nmi mechanism setup > - have oprofile/perfmon2 identify cpu for real (currently just hardwired > to amd64) > - oprofile always uses perfmon2 if kernel configured with perfmon > - module installation a bit odd: > -install oprofile modules > -opcontrol reads information to determine if perfmon2 used > -opcontrol install appropropriate perfmon module > - oprofile lies that it needs buffer space (perfmon_get_size()) so > perfmon2 actually calls oprofile's perfmon_handler() > > oprofile: > - make translation of events names to bit patterns more robust: > can hang if event is not found > - verify that the event masking support works > - get rid of fatal_error() function in opd_perfmon.c > - ophelp get the available events from libpfm when possible > > libpfm: > -make event mapping complete (lots of events missing for various processors) > -libpfm isn't available on some procesors that perfmon supports (e.g. > p4/ppc64) > > > -Will > _______________________________________________ > perfmon mailing list > [email protected] > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
