Re: [perfmon2] Performance Counters for Linux, v6

[<Gar...@bu...>]

HI Stephane, Phil

stephane eranian <er...@go...> 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...> 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