Corey,
On Wed, Jun 10, 2009 at 8:04 PM, Corey J Ashford <cjash...@us.ibm.com>wrote:
> > Yes, that could indeed be a problem but you are right that it is not
> > anticipated that
> > libpfm would be used in critical paths, but rather during the setup
> > phase of a
> > measurement. The alternatives are:
> >
> > 1- the function return value is the string, e.g., const char
> > *pfm_get_event_desc(int idx)
>
> This would be a good solution if it were possible for all arches and
> chips. That would be possible on all of the Power chips I'm aware of, but
> I don't know about the others.
>
There is a danger though with this if you are not careful. The returned
string
may be read-only. So if the program was tempted to try and modify the
string,
let's say to capitalize first letter or remote trailing '.' then this would
segfault.
I guess we could define the return to be const char *pfm_get_event_desc(int
idx).
Hopefully, the compiler would print a warning if you assign this to char *.
In case of error (invalid identifier), we would return NULL. In case the
event has
no description, we would return "no description available".
> >
> > Going back to fragmentation, it is not clear to me that
> > pushing the allocation in the application
> > (rather than the library) will make this problem go away. You
> > will still have to allocate a buffer
> > based on maximum size, and once you're done you'll have to free
> it.
>
> Except that the user would be free to determine how they were going
> allocate and dispose of the memory. For example, they could use a static
> buffer, or allocate the buffer on the stack.
>
Good point.
> > The current logic in libpfm is that if an event has unit masks, then
> > at least one must be
> > provided. Phil and I discussed the ability to designate a default
> > unit masks. In fact,
> > the logic is implemented in the current libpfm but it is not used,
> > except maybe on MIPS.
>
> We are using that feature of libpfm in an internal project right now,
> actually.
>
> > The problem with this is is you have an event A, which supports unit
> > mask E,F,G, if you
> > simply pass A, and libpfm picks up A:E (as default), then you don't
> > really know what you
> > are measuring with A. Unless we document it somewhere or provide a
> > call to return the
> > default such that tool can provide the info. If I recall OProfile
> > uses default unit masks.
>
> That's a good point. In the case where we are using it, there is one
> obvious choice for the default of each event type, and is effectively,
> "give me what I want for this event". Right now, the user doesn't know
> which specific attributes he's getting, but has already stated, "give me
> what I want, I don't care about the details." You're right, though, it
> would be good to have a some way to expose that info if it was requested.
>
Yes, we could have something such as:
const char *pfm_get_default_attrs(int idx);
If event is INST_RETIRED, and default attribute is ANY_P, then this
function
would return "ANY_P". Doing it this way allows the default attribute to
be more
complex than a single attribute.
What do you think?
> I have one other question. When I first read this proposal, it seemed
> like a massive redesign of libpfm. Are you going to maintain backward
> compatibility and still provide, for example, pfm_dispatch_events?
>
> I doubt we can maintain backward compatibility because a lot of the data
structures will go away (pfmlib_event_t *). But if I take IA-64 all the
model
specific pfmlib_*_input_param_t and such will disappear.
As for the other functions, you've noticed that their prototypes have
changes
drastically.
Of course, a solution would be to simply augment libpfm with the new calls,
but
then my fear is that it will turn into a monster library with tons of entry
points.
I am trying to cut down on the number of entry points and data structures.
But I am open to suggestions, do you have another idea?
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
