vince,


On Thu, Apr 24, 2014 at 3:38 PM, Philip Mucci <mucci@icl.utk.edu> wrote:
Hi Vince,

I'm just a guilty as i did a lot of the pfm work in the past. 8-)

As for the Linux portion, perf is already Linux only, plus configure or the compiler sets the LINUX preprocessing define.

So that should be fine, the issue now would be to fix the pfm enumeration. Vince do u have any specifics on the issues? I never saw this back in the day when I did the first pass at enumeration way back in the day.

Just like Phil, I am not sure I understand the enumeration problem you're alluding to.
Look at showevtinfo.c in libpfm4. It lists the events and does not end up in an infinite
loop when there are aliases.
 
Thanks

Apologies for brevity and errors as this was sent from my mobile device.

> On Apr 23, 2014, at 22:55, Vince Weaver <vincent.weaver@maine.edu> wrote:
>
>> On Wed, 23 Apr 2014, Gary Mohr wrote:
>>
>> I have the perf_events component restructured to eliminate the call to
>> pfm_find_event (plus several other libpfm4 calls) and it looks like it
>> is working when adding events to an event set.  I figured out how to get
>> the fully qualified event string back from the encode function and now
>> use that to fill in the information needed by the papi event table.
>> There is a lot less code executed now when doing an add event and it is
>> much easier to follow what is happening.  This new code supports the
>> cpu=x mask (I get the value back from the encode function but still have
>> not made papi changes to use it).
>
> Believe it or not the initial PAPI libpfm4 implementation was like this,
> but I had to abandon it because it just would not work with enumeration.
>
> The problem is libpfm4 has aliased events.  So if you convert to the
> canonical name for an event, it might map to another event name.  So when
> you try to enumerate "next" it takes you to next for the alias not the
> event you were on.  Best case you just get like 9 events like you're
> seeing, worst case you get stuck in infinite loops.
>
> As for why PAPI was using the raw CPU OS type rather than extended,
> that's because PAPI is in theory cross platform.  The "extended
> perf_event" umasks are nice if you're running on Linux, but they're
> not available on other platforms.  I guess we could declare that PAPI6 is
> Linux/perf_event only, but until then we have to support the traditional
> ways of specifying user/kernel and CPU number even in libpfm4 isn't
> involved.
>
> Vince