Re: [perfmon] 2.6.20 new perfmon code base + libpfm + pfmon

[Stephane Eranian <eranian@hpl.hp.com>]

Will,

On Wed, Feb 14, 2007 at 12:05:31PM -0500, William Cohen wrote:

> >The oprofile patch should be made against the oprofile cvs rather than 
> >the 0.9.2 tarball. There are some files that the patch touches that are 
> >created by the autogen.sh.
> >
> >The oprofile patch doesn't build if things are configured without the 
> >"--enable-perfmon2".
> >
> >gcc -W -Wall -fno-common -Wdeclaration-after-statement 
> >-fno-omit-frame-pointer -g -O2   -o oprofiled  init.o oprofiled.o 
> >opd_stats.o opd_sfile.o opd_kernel.o opd_trans.o opd_cookie.o 
> >opd_events.o opd_mangling.o opd_perfmon.o opd_perfmon_22.o 
> >opd_perfmon_compat.o opd_anon.o liblegacy/liblegacy.a ../libabi/libabi.a 
> >../libdb/libodb.a ../libop/libop.a ../libutil/libutil.a -lpopt -liberty 
> >-ldl
> >opd_perfmon.o: In function `perfmon_init':
> >/home/wcohen/research/profiling/oprofile/oprofile-0.9.2-perfmon2/daemon/opd_perfmon.c:384: 
> >undefined reference to `do_perfmon_init'
> >collect2: ld returned 1 exit status
> >
> >-Will
> 
> Hi Stephane,
> 
> I tweaked the oprofile patch a bit so that it applies to the oprofile cvs 
> repository and builds with and without being configured with 
> --enable-perfmon2. The patch is attached.
> 
> Things that will need to be done to the patch:
> 
> -handle case where perfmon pmd/pmc registers are unavailable
> 	Is the method being used going to work for systemwide perfmon?
> 		create a thread local context then collect unavail regs.

As of now, there is enforced mutual exclusions between per-thread and system-wide.
The unavailable support is used to make the application aware that the whole PMU may
not be available, for whatever reason. For instance, today this is used when the NMI
watchdog is active. The unavailable mask will report that one counter is not available.

This will be generalized once we add a finer grain PMU register allocator underneath
perfmon (to be used by perfmon and NMI for instance). The way I envision this is that
you create the context, query what is available, assign event -> counters, load
context onto thread or CPU. That call could fail if some of the registers used became
unavailable in which case, you need to go through the procedure again.

> 	What happens if another thread using a register that is marked
> 		available in the current thread?
> -handle naming differences between oprofile events and perfmon2

This is handled in the code already today. Because I did not want to change
the event description table nor the higher level event -> counter logic of OProfile,
the mapping from Oprofile counter -> Perfmon PMC/PMD is done AFTER. With such setup,
it is hard to deal with unavailable registers detection once in perfmon code. I think
querying the unavailable register needs to happen BEFORE event-> counter assignment.
But that means that we need to provide a converter from Perfmon PMD -> OProfile
counters which is something i have not yet done.

Thanks for the patch.

-- 
-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/