stephane eranian <eran...@googlemail.com> wrote on 06/11/2009 09:17:45 AM:
> 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. Yay for memory protection! If you dynamically read in the event table, you'd have to lock down the memory to be read-only somehow. I'm sure there's a way to do that, but I don't recall how. Well, I think this is not so bad, as long as it's documented. Something like: "The string pointer returned from this function points to read-only memory. If you want to modify the string, you will first need to copy it to a buffer you have allocated. Failing to do so will cause a segmentation fault." > > 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". Yes, or an empty string would fine too, I think. > > > 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? This would work be easy to implement if the default attributes were stored in the event table (or auxilliary table) as a string. Otherwise, we'd have have to construct the string from data dynamically, and return a malloc'd buffer, or use a buffer + size that is passed in. > > > 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 newcalls, 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? No :) I just wanted to understand where you heading with this. I agree that augmenting the library would cause it to become ungainly, and would be harder for users to figure out which functions they should be using. So this is essentially a branch. The current libpfm will need to be maintained for some time to come, I think. Regards, - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain cjash...@us.ibm.com ------------------------------------------------------------------------------ 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
