Hi Gary, Thanks for the note. It's pretty cool that Bull has gone the extra mile to implement some of their own tools. It would be interesting to know, from a PAPI perspective, what additional functionality would need to be there to support some of the tool needs.
We've had about a dozen requests for system-wide and CPU-wide counting in PAPI over the last few years, and your message hits home. I can honestly say, that with exception of the work to get the substrate working, perfmon provides the support for everything you'd want to do and more; and it does so today. I think when PCL gets to that point, the decision will be a tougher one. Regards, Phil On Feb 19, 2009, at 3:37 PM, gary.m...@bull.com wrote: > HI Stephane, Phil > > stephane eranian <eran...@googlemail.com> wrote on 02/19/2009 > 05:00:25 AM: > >>> The latest mail I saw on this topic suggested you were considering > creating >>> a user library (like libpfm) that would convert the existing calls >>> into >>> Ingo's new syscall interface. >>> >> >> No, I said I would extend the existing libpfm so it could serve LPC- >> based tools. >> Keep in mind does libpfm has never invoked perfmon syscalls for >> you. All > it >> does is help convert events -> counters+values. For LPC, all it > supposedly >> needs to do is convert events -> values. > > Thank you for reminding me. I have spent enough time in this code > that I > should have known that. > > > Philip Mucci <mu...@cs.utk.edu> wrote on 02/18/2009 12:07:31 PM: > >> >> As someone who's delivered entire tool suites on systems, why don't >> you separate your tool stack vs. your kernel support? Linking the two >> of them will hinder your ability to deliver a tool stack to your >> users >> in the short term. Like with perfmon (and perfctr before), it ain't >> over 'till it's in-the-kernel. >> > > In the statement: > "separate your tool stack vs. your kernel support" > > If you are referring to a "papi" like approach where it can build on > top of multiple different sets of kernel services, I completely agree > this is the right approach. > > Historically Bull has focused on the IA64 environment but that is now > changing. Future work will be done mostly on X86_64 platforms. Bull > currently delivers HPCToolkit and Papi to its customers on both > platforms. > The big difference for us is that on IA64 we are using perfmon2.0 in > the > kernel while on X86_64 we still use perfctr (long story which is no > longer > relevant). > > Our future X86_64 distributions will use a 2.6.29 (or newer) kernel, > possibly > from a fedora release or maybe RHEL6. They will still include > HPCToolkit > and Papi. > In addition there is a couple of Bull developed tools that currently > only > run on > IA64 (no they did not use Papi, in fact one of them even built its own > kernel module). > We expect to reimplement these to run on X86_64 and where possible I > will > encourage > building them on top of Papi. Some of them need to collect system > wide > metrics which > is not really Papi's strength, but even then they could use perfmon > kernel > services > instead of providing their own kernel module. > > My purpose for posting these questions was to gather information so > I could > choose which of the kernel interfaces to the PMU we should try to > use. The > responses from both of you have convinced me that our best > alternative is > perfmon2.2. > > So unless the kernel Bull chooses has been modified by Redhat so > much that > the > perfmon2.2 patches do not fit (like happened to me with the RHEL5 > kernel), > that is > what we will use. > > Thank you both for your input. > Gary > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source > code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > perfmon2-devel mailing list > perfmon2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
