Re: [perfmon2] [ptools-perfapi] Avoid hardcoding the number of entries in the libpfm library with PFM_PMU_MAX

[Steve K. <sb...@cr...>]

In cases like this I like to have an ending entry that is a null pointer, then you simply loop until you see it to know you've exhausted the list:


     for (i=0; pfmlib_pmus_map[i] != NULL; i++) {

                   ....

     }


Just make sure to add/update the NULL entry after populating/adding to/deleting from the table.


Then just redefine the PFM_PMU_MAX entry something like:


#define PFM_PMU_MAX do while(0) { int _i; for(_i=0; pfmlib_pmus_map[_i]!=NULL; _i++) { } }, _i


or perhaps a small function to do this would be cleaner:


#define PFM_PMU_MAX __pfm_count_max()


Steve

________________________________
From: William Cohen <wc...@re...>
Sent: Tuesday, May 30, 2017 1:28:03 PM
To: per...@li...; pto...@ic...
Cc: Michael Petlan
Subject: [ptools-perfapi] Avoid hardcoding the number of entries in the libpfm library with PFM_PMU_MAX

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

--
You received this message because you are subscribed to the Google Groups "ptools-perfapi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pto...@ic....
To post to this group, send email to pto...@ic....
Visit this group at https://groups.google.com/a/icl.utk.edu/group/ptools-perfapi/.