This looks great, Stephane.
stephane eranian <eran...@googlemail.com> wrote on 06/09/2009 02:54:16 PM:
> Hello,
>
> Here is an update on the current status of libpfm redesign, i.e.,
libpfm4.
> I have been playing around with some changes both visible and internal
> to take into account what we have discussed so far. In particular:
>
> - no more pfmlib_event_t, i.e., visible event decomposition
>
> - event specification with unified syntax, i.e., event:umask:
> attr1=1:umask2:attr2=10
>
> - no visible distinction between attributes and unit masks,
> everything is called attributes
>
> - internally there is a layering of PMU support: hardware and OS.
> Either one of those could
> be empty. For perfmon, you'll have hardware only. For PCL
> you'll have both hardware and
> OS. In that case, OS implements the PCL generic SW and HW events.
>
> - the listing and event info API is still returning integer, but
> they are opaque identifiers. It is
> not possible to do for(i=0; i< num_events;i++). Instead, you
> can use a helper macros with
> accessor functions: for_each_event(). The same kind of opaque
> identifiers is used to list and
> query attributes.
This is a great idea. It makes it so the OS-specific layer doesn't have
to create a unified/monotonic event numbering... it just has to be able to
enumerate all of the events and give them unique ids which it is free to
concoct.
You might also want to provide these functions:
int pfm_first_event(void); /* returns first opaque event identifier
and implicity starts the sequence over again */
int pfm_next_event(int opaque_event_id); /* returns -1 when you've
gone past the end of the event list */
so that callers are not forced into the "for each" paradigm. This is a
little harder to implement, because it requires knowing the next id given
the current id, whereas with for each, the layer can just iterate over its
separate lists.
One other minor thing is that you can make it so when the for_each_event
calls the user's function, if that called function returns a -1 (say), the
loop will terminate. This way, you provide a way for the caller to get
out of the "for each" loop when it has found what it wants.
> - attributes are always defined per event. Parsing and
> decomposition happens internally in the generic
> libpfm layer. Not all events have the same set of attributes.
> It is up to the developer of each PMU
> support to try and unify attributes with the same meaning, e.g.
> "u" on AMD64 mean priv user 1,2,3
> same thing on Intel.
>
> - to make things simpler, I have modified all calls which return
> a string, e.g, description of an event or
> attribute, to allocate the string internally. Thus, no need to
> worry about the buffer size but you need
> to free the string whenever you are done.
I have mixed feelings about this because of the possibility of long-term
memory fragmentation. However, I think the vast majority of apps will not
be calling the interface very often, so the problem should be fairly
minimal.
>
> - pfm_get_event_encoding() to return raw event encoding (not PCL)
So no change here, except the rename from pfm_get_event_code to
pfm_get_event_encoding?
>
> - PCL to be handled via specific call:
> pfm_get_pcl_event_encoding() and it takes struct perf_counter_attr.
> PCL definitions are in a dedicated header file.
I assume you'd supply both the event and attributes (including privilege
level, edge/level etc.) to this function?
>
> - I have renamed pfm_dispatch_events() to pfm_assign_events(),
> the input is now an argv-style array.
> The call still takes some extra parameters which are needed on
> input (list of unavailable pmcs) and on
> output (list of registers to program). I am still not too
> satisfied about the output structure, it is big. The
> alternative would be to dynamically allocate just the number of
> registers needed for the measurement.
I think as long as you are returning the other strings using allocated
memory, it probably wouldn't hurt to do it here on these objects too.
>
> Find attached the current state of pfmlib.h.
Just a nit, but the pfm_assign_events function's structure definitions
still read "pfmlib_dispatch_{in,out}_t".
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
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
