Corey,

Let me explain the motivation behind this change. The idea is to allow
testing of the library without having to necessarily
run on a host with the specific PMU you want to test. For instance,
I'd like to be on Core 2 and test the AMD64 libpfm code.
To do that you have to bypass the PMU detection code. Unfortunately
that is not as easy as that. Many detection routines
are doing more that detection, they also initialize certain
structures. In the libpfm-3.5, I simply split detection and
initialization.
When you force (using env. variable LIBPFM_FORCE_PMU), then you skip
detection but you still execute initialization.
That works in most cases, however when the initialization needs to
touch HW, e.g, CPUID or cpuinfo, then you have to make
it up. I have fixed all the X86 and Itanium detection routines. If you
are not forcing the PMU, then there should be no changes
because the init callback is optional. So it is not clear to me why
you are having a problem.


To force a specific PMU, you need to set LIBPFM_FORCE_PMU=n where n is
the libpfm PMU model value which you get
out of include/perfmon/pfmlib.h, e.g., 34 is for Intel CoreDuo.

Hope this helps.


On Wed, Aug 6, 2008 at 4:07 PM, Corey Ashford <[EMAIL PROTECTED]> wrote:
> Hello Stephane,
>
> Fairly recently, the following lines were added to pfm_initialize() in
> pfm_common.c in libpfm:
>
> ...
> while(*p) {
> +       /*
> +        * check for forced_pmu
> +        * pmu_type can never be zero
> +        */
> +       if ((*p)->pmu_type == forced_pmu) {
> +               __pfm_vbprintf("PMU forced to %s\n", (*p)->pmu_name);
> +               goto found;
> +       }
>
>        if (!forced_pmu && (*p)->pmu_detect() == PFMLIB_SUCCESS)
>                goto found;
>                p++;
>        }
> }
> ...
>
>
> (note: above is not a real patch, it's just for illustration)
>
> These new lines are causing libpfm on POWER to fail because at the point
> where (*p)->pmu_type is checked, it is zero.  It is set only by
> (*p)->pmu_detect().  Because the first if-statement's condition is true,
> pmu_detect() is never called.
>
> I'm not sure what the right solution here, because I don't know what the
> intention of forced_pmu is, exactly.  Maybe the order of these two
> if-statements should be reversed?
>
> To work around this for now, I'm going to comment out the first
> if-statement.
>
> Thanks for your consideration.
> - Corey
>
> --
> Corey Ashford
> Software Engineer
> IBM Linux Technology Center, Linux Toolchain
> Beaverton, OR
> 503-578-3507
> [EMAIL PROTECTED]
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to