On Thu, Aug 24, 2006 at 02:33:09PM +0000, Philip Mucci wrote: > The event 'eeeee:xxx:yyy:zzz[:...]' is still one event with many > qualifying masks, which means one descriptor (to me). If I pass that to > pfm_find_event(), it should give it to me if it's legal and return an > error if it's not. >
An event descriptor is an opaque value to the application, *but* to the library it is the index of the *event* in the table. Thus it cannot be overloaded with unit mask information. With a hierarchical representation of event, the event descriptor is only *part* of the information you need to setup a counter. You also need to unit masks descriptors. > If I have something that can tell me what those xxx:yyy:zzz:... etc are > for a given eeee (and how many there are), then I'm happy. Perhaps this > is what you are talking about, but I find the call name and the > arguments non-intuitive. But that's me and why I haven't cc'd this to > the list. > > > On Thu, 2006-08-24 at 07:10 -0700, Stephane Eranian wrote: > > On Thu, Aug 24, 2006 at 01:59:25PM +0000, Philip Mucci wrote: > > > Ok, I guess I was thinking that there should be only one descriptor for > > > any given name+mask. I better go back and review the discussions as I'm > > > guessing I don't understand why there should be more than one. > > > > > Because of unit mask combinations which are legal. > > For instance on Opteron64: > > SEGMENT_REGISTER_LOADS:ES:DS > > > > Means count event SEGMENT_REGISTER_LOADS whenever there is either a load > > of DS or ES. > > > > In many cases, if you have multiple unit masks, they can be combined. > > this is the whole reason we went from a flat representation of events+mask > > to a more hierarchical representation where combinations are possible. > > > > The issue is that this is a rather pervasive change. > > > > > > > > On Thu, 2006-08-24 at 06:08 -0700, Stephane Eranian wrote: > > > > On Thu, Aug 24, 2006 at 12:45:59PM +0200, Philip Mucci wrote: > > > > > Hi Stephane, > > > > > > > > > > Why couldn't find event transparently decode event masks? > > > > > > > > > We could change the prototype of pfm_find_event() so it > > > > return the event and unit mask(s) descriptors. That avoid > > > > minize the number of entry points in libpfm but it would > > > > break backward compatibility wfor existing applications. > > > > I don't care about pfmon, I can fix it quickly. But you > > > > have PAPI and probably many others. OTOH, libpfm is > > > > still in-flux at the moment, so it is okay to make > > > > incompatible changes. > > > > > > > > > > > > > > > > > phil > > > > > > > > > > On Tue, 2006-08-22 at 03:28 -0700, Stephane Eranian wrote: > > > > > > hello, > > > > > > > > > > > > As we expose unit masks directly to pplications using the libpfm, > > > > > > some interfaces must be extended and/or added to make it easier > > > > > > to managed unit masks. > > > > > > > > > > > > For instance, in the latest release we have issues on Pentium 4 > > > > > > for the following function: > > > > > > - pfm_get_cycle_event(): the default cycle event on P4 has a > > > > > > unit > > > > > > mask defined, yet the function does not return it. > > > > > > > > > > > > It is not too difficult to see that the other functions might have a > > > > > > problems too, such as : > > > > > > - pfm_get_retired_event() > > > > > > > > > > > > Similarly, it would be nice to have function that knows directly > > > > > > how to > > > > > > deal with event+unit mask all at once: > > > > > > - pfm_find_event() > > > > > > - pfm_get_event_name() > > > > > > > > > > > > Let's take the example of pfm_find_event() which takes a string and > > > > > > returns in a parameter, the event descriptor. It would be nice to > > > > > > have > > > > > > another function (to maintain some backward compatiblity) that can > > > > > > take > > > > > > an event string of the form "event_name:unit_mask1:unit_mask2" and > > > > > > return > > > > > > both the event descriptor and the list of unit mask descriptors. The > > > > > > function prototype could look as follows: > > > > > > int pfm_find_event_and_masks(char *str, pfmlib_event_t *e); > > > > > > > > > > > > We could do the same thing for pfm_get_event_name(): > > > > > > int pfm_get_event_and_masks_name(pfmlib_event_t *e, char *str, > > > > > > size_t maxlen); > > > > > > > > > > > > As for get_cycle_event and get_inst_retired_event, they could be > > > > > > modified > > > > > > similarly: > > > > > > - int pfm_get_cycle_event(pfmlib_event_t *e); > > > > > > - int pfm_get_inst_retired_event(pfmlib_event_t *e); > > > > > > > > > > > > Any opinion? > > > > > > Anybody interested? > > > > > > > > > > > > PS: some of the libpfm examples would need to be updated > > > > > > accordingly. > > > > > > > > > > > > > > > > _______________________________________________ > > > > > perfmon mailing list > > > > > [email protected] > > > > > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ > > > > > > -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
