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
