stephane eranian wrote:
> Corey,
>
> On Wed, Nov 25, 2009 at 1:49 AM, Corey Ashford
> <cjash...@linux.vnet.ibm.com> wrote:
>> I wasn't thinking in terms of umasks before, because our A2 processor won't
>> need umasks (as I understand them), just event modifiers. I was thinking of
>> getting the default values one at a time, but getting an entire array of
>> them is ok too.
>>
>> So let's take your prototype, tweak it a little and I'll tell you what I'd
>> want out of it.
>>
>> pfm_get_event_attr_dfl(int idx, int attr_idx, int *attr_idxs, int
>> *attr_dfls, int *n_attrs);
>>
>> For a given event, idx, and umask, attr_idx, return an array of attribute
>> indices for those attributes which have defaults in attr_idxs, an array of
>> attribute defaults in attr_dfls, and the number of attributes in n_attrs.
>>
> Ok, I see. The issue here is that you are assuming that attribute values
> are all integers. The way it is setup right now, an attribute can have any
> type, incl. a string.
In my original email, I had a parenthetical question/comment about attributes
which have string values. In the libpfm code, though, the attribute type
appears only to have the choices of umask, boolean, or integer:
typedef enum {
PFM_ATTR_NONE=0, /* no attribute */
PFM_ATTR_UMASK, /* unit mask */
PFM_ATTR_MOD_BOOL, /* register modifier */
PFM_ATTR_MOD_INTEGER, /* register modifier */
PFM_ATTR_MAX /* end-marker */
} pfm_attr_t;
So I am sure I am missing something somewhere.
That said, we could also support strings by returning, in the array, a pointer
to the string instead of a boolean/integer value. In this case, it would be
convenient to return an array of pfm_attr_t values as well, so that it would be
easier for the tool to display the values.
>
> If I look at the X86 event tables, some events or unit masks do have
> certain modifiers hardcoded. For instance,
>
> UOPS_ISSUED:STALLED_CYCLES has i=1, cmask=1
>
> This unit mask does not exist in the official documentation, but it is
> added for *convenience* because this is a common usage of the event.
>
> With existing libpfm4, if you try to pass
>
> UOPS_ISSUED:STALLED_CYCLES:cmask=2
>
> It will fail. It is not clear to me what knowing that cmask=1 would do
> in your tool. I understand if you are listing events. The tool could
> obviously check that the user is not passing an already hardcoded
> attributes, but then the library does that work already.
In this case you are right, it wouldn't provide anything useful, and these
defaults might be excluded from the return values, since they are not
modifiable.
>
>> This way, I know the indexes of the attributes which have defaults, and the
>> default values for those same attributes.
>>
> And then what do you do with that in your tool?
> It seems that it you pull this knowledge out of the library you will end up
> duplicating some of the work of the library in your tool.
Of course the user can choose to ignore what the specific defaults are, in
which
case nothing changes in the usage model.
The issue I'm facing is that we have events for which you can choose one
attribute value or another, and it's not always clear which value the user
would
want to use. And this can occur on more than one attribute for an event. I
want the user to be able to determine what value the library has chosen for the
default, rather than just shield him from the choices it will make.
I think this may be important when the user looks at his results and scratches
his head... "Why am I getting this count that is obviously not what I wanted
to
count? Is the tool counting cycles asserted instead of edges?" etc. Then he
has to go find the attributes, and try forcing them to what he thinks they
should be to see if it makes a difference.
One other issue is the notion of mandatory attributes. For some events, we are
going to need the user to specify a couple of attributes which supply a bit
mask. These masks would have no default value. It would be nice for the tool
to have some way of sensing required attributes.
So maybe the interface could be generalized a bit more so that instead of
returning separate arrays, we return a data structure with all of the
interesting details about the attribute:
struct pfm_attr_info_t {
char *name;
char *desc;
pfm_attr_t type;
int has_default; /* boolean */
union {
const char *dfl_str;
int dfl_bool;
int dfl_int;
};
int mandatory; /* 1 = mandatory, 0 = optional */
}
It would be nice to supply information about the allowed values of the
attribute, but I don't want to get too carried away here.
So this would be the proposed api call:
pfm_get_event_attr_info(int idx, int attr_idx, pfm_attr_info_t *attr_infos, int
*n_attrs);
>
>>> With your proposal, how would you solve the issue of a default priv level?
>> A user level tool could call this function, figure out which attributes it
>> was interested in (via their names), and then append to the event:umask
>> string any modifications to the defaults that it needs. For example, it
>> detects that k=1 when it needs it set to zero, so it specifies
>> event:umask:k=0
>>
> For priv level, the issue is mostly about how to deal with the case where
> the user did not specify anything in the event string. If you see:
>
> UOPS_ISSUED:STALLED_CYCLES
>
> Does that mean u+k, u, k? The high level tool has to make a choice.
> That is how this is done with libpfm3. I think the decision has to be
> in the tool and not the library. The tool has no idea which attribute
> control the priv level. It would have to know about each PMU model
> to do this. So instead, you have to abstract this, perf_events does
> that with the exclude_* fields. We can do this as well by using the
> PFM_PLM* bitmask.
I agree, that's certainly one easy-to-use solution to the plm problem. I was
just thinking if we had a more general-purpose mechanism, that could be used
for
all attributes instead of just plm, that we could kill two birds with one stone.
>
> Note that what I am describing here about the priv level mask can
> be implemented independently of what you are proposing for all
> attributes.
True. We don't need to chose one over the other.
> I could see certain events having hardcoded priv levels
> such as for uncore PMU, i.e., must have u+k all the time because
> hardware does not know any better.
>
> Note that I am not at all against your idea. I am just trying to understand
> how useful it could be for tools. Once we understand that better, I don't
> have a problem adding this.
Thanks for the discussion,
- Corey
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
