Phil, On Tue, Jan 09, 2007 at 11:53:14AM +0100, Philip J. Mucci wrote: > On Tue, 2007-01-09 at 02:43 -0800, Stephane Eranian wrote: > > Phil, > > > > On Tue, Jan 09, 2007 at 10:54:07AM +0100, Philip J. Mucci wrote: > > > Stefane, > > > > > > How did you handle the processor type detection? I had to change lots of > > > the oprofile kernel code to do this... Attached is my patch that works > > > on the PIII (and most likely MIPS). This patch is probably significantly > > > less involved that Stefanes. > > > > > I simply extended the get_cpu_type() function by cloning what was already > > in nmi_int.c and other x86 related OProfile files. Is there another place > > that needs to be fixed? > > I'm not sure about nmi_int.c, but when setting the oprofile processor > type, you have to set it to that what is listed in the events directory. > Things like 'i386/piii'. You can't use what perfmon2 uses as the pmu > name. So I have a big table in the initialization function that maps > things.
In the kernel I have clone the code that produces the "i386/piii" string. At the user level, the sequence of code in opcontrol which is as follows: > case $OP_IMPLEMENTATION in > perfmon2) > IS_PERFMON=$KERNEL_SUPPORT > # need to get the appropriate perfmon module installed > # FIXME need to remove them when they are not needed > case "$CPUTYPE" in > i386/ppro|i386/pii|i386/piii) > PERFMON_MOD="perfmon_p6" > ;; > i386/p6_mobile) > PERFMON_MOD="perfmon_pm" > ;; > #FIXME need to handle em64t > i386/p4|i386/p4-ht) > PERFMON_MOD="perfmon_p4" > ;; > i386/athlon|x86-64/hammer) > PERFMON_MOD="perfmon_amd" > ;; > mips/20K|mips/5K|mips/24K|mips/25K) > PERFMON_MOD="perfmon_mips64" > ;; > mips/ice9a|mips/ice9b) > PERFMON_MOD="perfmon_ice9" > ;; > esac > modprobe $PERFMON_MOD > if test "$?" != "0"; then > echo "Unable to load module $PERFMON_MOD." > # couldn't load the module > exit 1 > fi is removed. The latest perfmon2 does automatic loading of the PMU description module (at least on IA-64 and X86) on context create. You can never force a module because it has its own probe function. Given that the OProfile and PMU description modules use the same source for the information, namely VENDOR_ID, FAMILY, MODEL, I don't see a problem. So in my version this whole switch-case is mostly empty: no more modprobe. I see a problem if you use the OProfile event assignement code because I don't think it knows about the perfmon register mapping between PMC/PMD and actual hardware registers. If we use libpfm, then we do not have this problem. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
