Re: [perfmon] Re: Patches to get oprofile to work with perfmon2 on amd64

[Stephane E. <er...@hp...>]

Phil,

On Tue, Apr 04, 2006 at 10:27:58AM +0545, Philip Mucci wrote:
> 
> I have a question about the below statement. If libpfm is designed to be
> separate from perfmon2, what is exactly it's purpose? Is it's goal to
> replace PAPI or some other API? I'd like to understand where it fits and
> whether Stefane is going to disrupt my stream of consulting income
> funding my travels with it. ha haa ;-)
> 

No, libpfm serves a different purpose. The goal is not to present a uniform
interface and set of events of tools. It does present a uniform interface
across platforms but it exposes the real events. Just like it is today
on Ia-64, PAPI could live on top of libpfm. 

The reason I keep libpfm separate from theperfmon kernel interface is because
I want to minimize the dependencies whenever possible. You say it yourself
below. Libpfm is a helper library for performance tools. It solves the
difficult event assignement problem. You say "I want to measure event X, Y, Z and
use features A, B (e.g., opcode filters)" and the library returns a valid
assignement that you then copy over to the perfmon2 interface specific 
parameters or any other interface for that matter.

I do not want libpfm making perfmon kernel calls. The reason is simple, if
you do this you will run into problems with tools as they don't all the
things the same way. I'd rather see another library side by side with libpfm.
The latest libpfm shows this with the system-wide helper library libpfms.

Furthermore, I do not want libpfm becoming a required component to use
perfmon2. Take HP Caliper, for instance, it does not use the library, yet
it inbokes the interface easily. It is not the role of libpfm to hide
some of the aspects of the kernel interface, like what is done
by perfctr for instance. Tools should be exposed to the real kernel
interface. If they need help, then people can design a new library. The point
being that this library will serve a different goal from libpfm.

To summarize, libpfm does not have the same goal as PAPI. PAPI can
be layered on top of libpfm. PAPI brings another set of value-adds
to tools, such as generic event names across architectures.

> Personally, I use libpfm as a nice 'helper' library only for event
> description tables it provides as part of the IA64 support. In fact,
> PAPI implements all those separately on other platforms, but we didn't
> want to reinvent the wheel since Stefane did all the hard work. However,
> for other things, like register allocation, the algorithms in libpfm are
> fixed and not portable...they must be re-written for each platform,
> whereas the scheme in PAPI is in portable code.
> 
> Anyways, I think you guys understand what I'm getting at...I would like
> to understand what the group sees as the division of functionality
> between PAPI and libpfm.
> 
> Regards, and Namaste from Nepal,
> 
> Phil
> 
> > I am open to suggestions on this, make a proposal. The good thing about libpfm, is that you 
> > are not required to use it to invoke the perfmon2 interface.
> > 

-- 

-Stephane