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.
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.
> 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.
>> 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.
Note that what I am describing here about the priv level mask can
be implemented independently of what you are proposing for all
attributes. 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.
------------------------------------------------------------------------------
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
