Vince, Phil, I kind of agree with what Vince is saying in this discussion. One of the principles that papi was built to support is the idea that the same approach can be used for all platforms supported by papi. And this idea has value.
The existing setopt interface will continue to exist for all supported platforms. The setopt interface specifies the cpu to be used at the event set level (all events in an event set). I added the support for cpu attach to setopt a couple of years ago and at the time it was supported only by what is now the perf_events component. I do not know if it was ever extended to also work with BlueGene and I am pretty sure it was not used to specify the package used in the rapl component (rapl replicated event names for each package). So it seems to me like papi is already in a position where the setopt version of cpu attach only works with some components (probably only perf_events and perf_events_uncore). To get the consistency mentioned above some work would have to be done in the components that currently do not use the cpu number specified with setopt. The work I am doing now to add a "cpu=x" mask is creating an additional way to specify the cpu number. But it is also allowing users to specify the cpu number to use at the event level rather than the event set level. So this new approach provides a capability that does not currently exist in the setopt interface for cpu attach. The new approach is very useful in the uncore component but as pointed out would also be nice to have in other components. Just like the setopt interface, to get consistency across all supported platforms, it will require work in all of the components where it makes sense to support it. So I think Vince makes a good point but I think we already have the situation he is concerned about. The new cpu mask will also have this limitation once it is working on the perf_events and perf_events_uncore components. But the solution for this situation is not to stop building things that are useful on the linux platform. The solution should be to add support to the other components to support the same capabilities. I know this is easier said than done but please do not limit what is provided for one component because other components will not support it. Instead I view these changes (both the setopt and cpu mask features) as a blue print of what would be nice to have and an example of how to do it. To get it done on the other components, someone will have to step make the changes in the other components to make it happen. For my part right now, I am willing to do the work to support cpu masks in both the perf_event and perf_event_uncore components. I could envision that possibly in the future we may be willing to convert the rapl component to use this model. But I have no use for BlueGene so someone else will need to implement the changes being added for the linux platform if it is to become consistent. It may require contributions from the papi community users who have access to BlueGene and care about being able to use these capabilities. Well that is my two cents. Gary > -----Original Message----- > From: Vince Weaver [mailto:vincent.wea...@maine.edu] > Sent: Friday, April 25, 2014 8:03 AM > To: Philip Mucci > Cc: Vince Weaver; Gary Mohr; Stephane Eranian; Heike McCraw; <perfapi- > de...@eecs.utk.edu>; perfmon2-devel > Subject: Re: [perfmon2] [Perfapi-devel] FW: Proposed enhancement to > libpfm4. > > On Thu, 24 Apr 2014, Philip Mucci wrote: > > > But Vince, are you implying that we should kinda 'discourage' using > > these events? I think we want people (experts like Gary) to be able to > > measure an uncore event with all information. As is stands, > > understanding events at that level falls on the user. Stephane shot down > > the idea of libpfm changing - unfortunately, that leaves us to find a > > workaround in PAPI. I don't think we can throw out a valuable solution > > just because it covers 99% (rather than 100) of the installed user base. > > I want to understand your proposal for the solution, what are your > > thoughts? > > I'm just saying maintanence wise it's going to be a pain if we have two > different ways of doing the same thing. Just looking at the bigger > picture. > > Ideally we should be able to use the CPU= flag on any event, not just > uncore. But to do that properly PAPI should be handling the flag, not > libpfm4. > > Otherwise you end up with the problem where Linux/libpfm4 users can just > do something like > UNHALTED_CORE_CYCLES:cpu=0 > > but the interface is completely different if you're saying running on > BlueGene, etc, and you have to go through the whole setopt interface. > > It means the whole cross-platform idea of PAPI falls apart because you > might as well be using two different libraries, PAPI, and PAPI-libpfm4 > which have different ways of doing things and will require different > #ifdefs in your code depending on what OS you're running your code on. > > So yes, we can throw together some sort of short-term hack that gets > uncore working a little easier right now (it's perfectly possible to get > uncore results even without the cpu=0 patches, you just need to use CPU > attach like the example code shoes). It's just going to add a long-term > maintanence pain to the rest of the library. > > 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
