Hi,
I just got done analyzing a problem where papi was built with an old verion of
the libpfm then it was being tested with a newer version of libpfm that had
support for additional processor architectures. In theory things should just
work because papi was using the libpfm shared library. However, in this case
the papi did not recognize the newer hardware's pmu. The problem was caused by
use of the PFM_PMU_MAX enum in papi's pe_libpfm4_event.c initialization loop:
for(i=0;i<PFM_PMU_MAX;i++) {
memset(&pinfo,0,sizeof(pfm_pmu_info_t));
retval=pfm_get_pmu_info(i, &pinfo);
if (retval!=PFM_SUCCESS) {
continue;
}
...
}
The older libpfm that papi was built with has a smaller value for PFM_PMU_MAX
than the newer libpfm on the system being tested. Thus, the pmu entries added
in the newer libpfm were not scanned by papi.
There should be a better way of doing this in libpfm. As new pmus are added to
libpfm the other code should not need to be recompiled because of a change to
PFM_PMU_MAX. The following in /usr/include/perfmon/libpfm.h will also cause
problems with this problem if it is used in other applications:
#define pfm_for_all_pmus(x) \
for((x)= 0 ; (x) < PFM_PMU_MAX; (x)++)
One possible way is to use the return value from pfm_get_pmu_info() to
determine whether a loop is at the end of the valid pfm_pmu_t range. Any
thoughts or comments on this?
-Will
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
