Gary, On Wed, Feb 18, 2009 at 6:23 PM, <gary.m...@bull.com> wrote: > > I have been following the discussions on this mailing list regarding the > unsolicited proposal made by Ingo Molnar to provide an interface to the > PMU. > > With this new proposal it now appear to me like the following 4 > alternatives are available to access the PMU (on an X86_64 system): > > perfctr > perfmon2 > perfmon3 > Ingo's proposal (does it have a name ?) > It's called LPC (or PCL), I think.
> I work for Bull Information Systems and we are currently planning to build > a linux distribution that likely will be based on a 2.6.29 kernel (possibly > from RHEL6) and we are trying to decide what we should include in this > distribution for PMU access. Our previous X86_64 distributions have > included perfctr because they were based on RHEL5 and we were unable to get > perfmon2 to work in the 2.6.18 (heavily patched) kernel delivered by > Redhat. > > My understanding of your reason for creating perfmon3 was to restructure > the syscall interface to appease the kernel.org people (in hopes of getting > it included in the kernel.org downloads). Now that Ingo has submitted his > counter proposal, it would seem like perfmon3 is no longer needed. Would > you agree with this ?? > You are right on the motivation for perfmon3 and the minimal perfmon3 quilt patch series which I posted numerous times on LKML. At this point, it is hard to determine what is going to happen for the next kernel revisions, though I suspect LPC has higher chances of being integrated eventually. I will keep perfmon3 around as an experimental branch. > There is some value to Bull to adopt the interface that will eventually be > included in kernel.org downloads. However it is important to us that tools > like pfmon and HPCToolkit using papi work correctly through the interface > we choose. I think that our needs are pretty much limited to the X86_64 > architecture. > I understand that. > 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. > Does this mean that you have accepted that Ingo's proposal will probably be > the one delivered with kernel.org downloads ?? I have not accepted that fact yet because they have not proven they can get to the same level of functionality as perfmon on all existing hardware architectures. ------------------------------------------------------------------------------ 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
