That gave me exactly what I needed, thanks for the tip.


Both the list code and the code that adds events to event sets in papi seems to be working now with the PFM_OS_PERF_EVENT_EXT mode set.


I still have a couple of things that need to be fixed but so far things are looking pretty good.  And at this point there are no changes to libpfm4. 


My todo list has one other thing that may affect libpfm4.  I would like be able to create an event list which includes the counter register constraints for the events and/or umasks (when there are constraints).  I see the information already exists in the libpfm4 event tables, but I see no way to get the information back from libpfm4.  Perhaps these values could be added as a new field in the information structures returned from the pfm_get_event_info and pfm_get_attr_info function calls.


It would be nice if the user could see the counter constraints without having to go find the intel/amd/??? manuals.  I understand that the counter constraints are actually enforced by the kernel and not libpfm4 but being able to provide this information to the user would help them determine which events can be used together.  With the newer kinds of hardware, counter constraints are becoming more common so I think additional help for the user in this area is a good idea.


Thoughts ??





From: Stephane Eranian []
Sent: Wednesday, May 07, 2014 1:40 PM
To: Gary Mohr
Cc: Philip Mucci; Vince Weaver; Heike McCraw; <>; perfmon2-devel
Subject: Re: RE: [Perfapi-devel] [perfmon2] FW: Proposed enhancement to libpfm4.




On Wed, May 7, 2014 at 9:10 PM, Gary Mohr <> 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'; '<>'; '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.