Hi Stephane,
stephane eranian wrote:
> Corey,
>
> I had a second thought on all of this while you are enjoying your long
> week-end ;->
>
>
> I think we could use your proposed structure and call as a substitute
> for most of the attribute entry points such as:
> pfm_get_event_attr_name()
> pfm_get_event_attr_desc()
> pfm_get_event_attr_code()
> pfm_get_event_attr_type()
>
> struct pfm_attr_info_t {
> char *name;
> char *desc;
> pfm_attr_t type;
> struct {
> int is_default:1; /* boolean */
> int mandatory:1; /* 1 = mandatory, 0 = optional */
> int reserved:30;
> }
> int idx; <<<
> uint64_t code; <<<
> int size; <<< /* for future extension */
> union {
> uint64_t dfl_64; <<<
> const char *dfl_str;
> int dfl_bool;
> int dfl_int;
> };
> };
>
> Instead of:
> pfm_get_event_attr_info(int idx, int attr_idx, pfm_attr_info_t
> *attr_infos, int *n_attrs);
> Do:
> pfm_get_event_attr_info(int idx, pfm_attr_info_t *attr_infos);
Did you leave out the attribute index as a parameter?
pfm_get_event_attr_info(int idx, int attr_idx, pfm_attr_info_t *attr_infos);
One thing that might throw a wrench into this works, is if the defaults of some
umasks or modifiers were dependent upon the value of the explicitly specified
attributes. To make it concrete, let's say there are two boolean modifiers, a
and b. If the user specifies a=1, then b's default is 0. If the user
specifies
a=0, b's default is 1. I don't think we'll want this capability in our
processor, but I can see where someone down the road might want it.
>
> I think we could also do something similar with the event entry points.
>
> struct pfm_event_info_t {
> char *name;
> char *desc;
> int idx;
> int n_attrs; /* number of attributes */
> uint64_t code; /* event code */
> int pmu; /* which pmu */
> };
I see, so this is how you were able to drop the n_attrs param from
pfm_get_event_attr_info.
> pfm_get_event_info(int idx, struct pfm_event_info_t *info);
>
> To replace:
> pfm_get_event_name();
> pfm_get_event_desc();
> pfm_get_event_nattrs();
> pfm_get_event_code();
> pfm_get_event_pmu();
>
> We would still have pfm_get_event_encoding() and all the iterators.
>
>
> To figure out the default for an event, you would do:
>
> idx = pfm_find_event("UOPS_ISSUED");
> for_each_event_attr(i, idx) {
> pfm_get_event_attr_info(idx, i, &attr_info);
> if (attr_info->is_default) {
> printf("default: %s\n", attr_info->name);
> }
> }
This works for umasks, but you'd also want to print out the values for
modifiers, right?
>
> There are still some issues, I think with certain defaults. Take
> my cache MESI example. The M, E, S, I, attributes can be set
> individually, any combination is valid. But there needs to be at
> least one of them set. Given your proposed attr_info structure,
> it is not clear how this could be expressed. None of the individual
> MESI bit are mandatory. What is mandatory is that one of them
> must be set. And they are considered unit masks, not modifiers,
> though we could make them that way but it is not clear that would
> help.
Ah, this is a case where there is a dependency. Let's say that the library
would choose ":M" by default. However, if someone specifies ":E", you want M,
S, and I to default to false.
I don't see any straight-forward solution for this at the moment. One way that
could work for this particular example, is that you could combine MESI into a
bitmask: ":mesi=0x8" (for example). This way the user is forced to enter
exactly what he wants for all of the bits, if he doesn't want the default.
This
is not too bad for this particular case, since they are closely related bits
anyway.
For less tightly coupled attributes, though, it could get ugly. For example,
if
you have a 32-bit field dependent upon an 8-bit field... now you have to type a
40-bit field into the modifier? not good!
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjash...@us.ibm.com
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
