On Wed, May 7, 2014 at 9:10 PM, Gary Mohr <Gary.Mohr@bull.com> wrote:

Hi Stephane,


I am still looking at this code with the idea of trying to eliminate the libpfm4 changes while at the same time not duplicating libpfm4 code in PAPI.


I found the libpfm4 function pfm_get_event_next which I now use to step through the events on a pmu when PAPI lists events.  This has eliminated the need for PAPI to use the function pfmlib_idx2pidx.


The other libpfm4 funtion which papi is still using is idx2pmu.  This function is used by PAPI after listing the last event on a pmu.  It gives PAPI the pmu number from the last event processed.  This is needed so we can find the next pmu of a particular type then we get the first event from the next pmu to continue listing events.


There is a way to get a pmu identification from an event opaque identifier.
Simply use pfm_get_event_info() and use pfm_event_info_t field called pmu.
Is that not good enough?

Does libpfm4 provide another way for PAPI to get the next pmu of a particular type ??


Maybe a libpfm4 function like pfm_get_pmu_next (int idx) would be the best way to solve this problem.


If you like this approach, I can build one and get it working with PAPI.

If you have a different suggestion, please share it.






From: Gary Mohr
Sent: Monday, May 05, 2014 3:41 PM
To: 'Stephane Eranian'

Cc: 'Philip Mucci'; Vince Weaver; 'Heike McCraw'; '<perfapi-devel@eecs.utk.edu>'; 'perfmon2-devel'
Subject: RE: [Perfapi-devel] [perfmon2] FW: Proposed enhancement to libpfm4.


Hi Stephane,


Following your suggestions, I have modified PAPI to no longer use pfm_find_event().  This has eliminated the problems I was seeing when trying to use PFM_OS_PERF_EVENT_EXT through the PAPI API.  I have also restructured PAPI to separate the code paths used when listing events and when counting events.  This has simplified both of these code paths quite a bit.  Currently I only have this new code working in the perf_events component but I plan to also put the same modifications into the perf_events_uncore component.


While doing this work I found that PAPI needed two functions which exist in libpfm4 but were declared as static so they were not available to PAPI.  The functions are idx2pmu and pfmlib_idx2pidx.


The attached patch file modifies libpfm4 to make these two functions externally visible so that PAPI can use them.


Would be willing to commit this change to libpfm4 or should I replicate the source for these two functions in PAPI ?


If you would prefer to provide functions by different names which do the same thing, that would be fine with me (the existing names are not really the kind of name I would expect to find in a libraries API).


Let me know how you would like to handle this.