On Wed May 31 2006 9:58 am, Stephane Eranian wrote:
> On Mon, May 08, 2006 at 10:11:29AM -0500, Kevin Corry wrote:
> > Right now libpfm has the pfm_find_event_* and pfm_get_event_* APIs. My
> > initial impression is that we could add APIs along the lines of
> > pfm_find_event_mask_* and pfm_get_event_mask_*, which would search within
> > one specified "parent" event for the specified mask information. And
> > pfm_dispatch_events() and its input parameters would have to be updated
> > to account for these event-masks. And obviously if a PMU doesn't have the
> > notion of event-masks (like POWER4/5), then it simply doesn't need to
> > provide any information for these new APIs. Any thoughts?
>
> I have been thinking about that new API too. We need to ensure that the
> unit mask combinations are supported. Take Opteron, for instance. the
> SEGMENT_REGISTER_LOADS event has one unit mask bit per segment register
> (ES, CS, SS, DS, ....). You can choose from any unit mask or combination
> thereof. You can say "DS OR SS", "DS OR SS OR ES", and so on.
Definitely. Pentium4 has some events with potentially thousands of
combinations of unit masks.
> With libpfm, the actual unit mask value is never exposed to user. I am
> wondering how we can express the "OR" condition in the interface of libpfm.
>
> At the pfmon level, I can see a syntax as follows:
> pfmon -eSEGMENT_REGISTER_LOADS:ES:DS,CPU_CLK_UNHALTED ......
This seems reasonable.
> At the libpfm level, we could pass a list of unit mask names and let the
> library figure out the bit value.
Also seems like a reasonable idea.
> Keep in mind that the application does
> not know and does not want to know the bit layout of the PMC register to
> know where to stick the unit mask bits. As such, you cannot have an
> interface where you'd query the unit mask value for ES, and DS and then let
> the tool merge the two and store the value in the unit mask bit position.
One thing we could do which might resemble the way that events are identified
is to give each mask a numerical identifier within it's event.
More specifically, we identify an event with a number (an "opaque descriptor"
as you call it below), which is usually an index into an arch-specific
internal array of events (although I suppose it doesn't strictly *have* to be
an index). An array of these event numbers is passed to the dispatch_events
routine, rather than the names of the events. For the unit-masks, we could do
basically the same thing, and have an array or list of mask numbers for each
event. Then we'd need APIs to get the mask number for a desired event number
and mask name. Perhaps something like:
int pfm_find_event_mask(const char *mask_str,
unsigned int event_idx,
unsigned int *mask_idx);
int pfm_find_event_mask_byname(const char *mask_name,
unsigned int event_idx,
unsigned int *mask_idx);
int pfm_get_num_event_masks(unsigned int event_idx,
unsigned int *count);
int pfm_get_event_mask_name(unsigned int event_idx,
unsigned int mask_idx,
char *mask_name,
size_t maxlen);
int pfm_get_event_mask_description(unsigned int event_idx,
unsigned int mask_idx,
char **str);
and other variants of the "event" APIs in perfmon/pfmlib.h.
> There are issues with this as not all unit masks can be combined. This job
> has to be done by the library.
Yes. This varification could be done using either mask names or mask numbers.
> The other issue is that the interface is based on this idea that when you
> find the event, you get an opaque descriptor for it. That descriptor is
> then passed to the core dispatch() routine. If you do the find_event(),
> separately from find_umask() then what descriptor do you pass to
> dispatch(). It seems that the unmask portion would have to be passed only
> at the level of dispatch().
I would foresee pfmlib_input_param_t staying as-is, with the array of
pfmlib_event_t's. But the pfmlib_event_t structure would get an additional
array of unit-mask identifiers and a count of identifiers, since each event
can have a different set of unit-masks.
How does that idea sound?
--
Kevin Corry
[EMAIL PROTECTED]
http://www.ibm.com/linux/
http://evms.sourceforge.net/
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
