Re: [perfmon2] [Perfapi-devel] FW: Proposed enhancement to libpfm4.

[Stephane E. <er...@go...>]

On Thu, May 8, 2014 at 1:20 AM, Gary Mohr <Gar...@bu...> wrote:

>  Stephane,
>
>
>
> 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.
>
>
>
Ok, I knew somehow there was enough in the existing API to fulfill your
needs.


>  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.
>
> Good.


>
>
> 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.
>
>
>
There is currently no way to extract that constraint mask. If it were
implemented it would be via the existing pfm_get_event_info() call. I'd
like to avoid
adding yet another call just for that.
The reason it is not yet exposed is because nowadays on Linux it is
irrelevant because ultimately controlled by the kernel.
Even though the user could know, it would have only a small influence on
the actual scheduling, except on a single user
machine.

Exposing this also assumes that the constraints can always be expressed as
a simple bitmask. Some events have more dynamic constraints
which depend on what is measured on the other sibling CPUs for instance
(offcore_response_* events).

I agree though that the info could help with grouping of events, should you
need this for some measurements.




>  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 ??
>
>
>
Make a patch proposal to add this.
Needs to be portable and backward compatible with what is already there.

Thanks.


>  Gary
>
>
>
>
>
> *From:* Stephane Eranian [mailto:er...@go...]
> *Sent:* Wednesday, May 07, 2014 1:40 PM
> *To:* Gary Mohr
>
> *Cc:* Philip Mucci; Vince Weaver; Heike McCraw; <
> per...@ee...>; perfmon2-devel
> *Subject:* Re: RE: [Perfapi-devel] [perfmon2] FW: Proposed enhancement to
> libpfm4.
>
>
>
>
>
>
>
> On Wed, May 7, 2014 at 9:10 PM, Gary Mohr <Gar...@bu...> 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.
>
>
>
> Thanks
>
> Gary
>
>
>
>
>
> *From:* Gary Mohr
> *Sent:* Monday, May 05, 2014 3:41 PM
> *To:* 'Stephane Eranian'
>
>
> *Cc:* 'Philip Mucci'; Vince Weaver; 'Heike McCraw'; '<
> per...@ee...>'; '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.
>
>
>
> Thanks
>
> Gary
>
>
>
>
>