vince,
On Thu, Apr 24, 2014 at 3:38 PM, Philip Mucci <mu...@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.wea...@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
>
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
