On Tue, Nov 24, 2009 at 9:29 PM, Corey Ashford
<cjash...@linux.vnet.ibm.com> wrote:
>
> Hi Stephane,
>
> stephane eranian wrote:
>>
>> Hi,
>>
>> Ok, so I fixed libpfm4 such that it defaults to user mode, unless the
>> user specify a plm attribute in the event string. This is not in GIT yet.
>>
>> For instance:
>> llc_misses -> user only
>> llc_misses:k -> kernel only
>> llc_misses:k=0 -> neither kernel nor user
>> llc_misses:u=1:k=0 -> user only
>>
>> That got me into thinking that it would probably make more sense to
>> NOT have libpfm4
>> try to force a priv level, but instead have the user pass a default
>> priv level, in case
>> none is specified in the event string. In libpfm3, this is how this
>> works. User must pass
>> a dfl_plm, otherwise pfm_dispatch_events() fails. So we could change
>> the API to be
>>
>> int pfm_get_event_encoding(char *str, int dfl_plm, uint64_t *values,
>> int *count);
>> int pfm_get_perf_event_encoding(char *str, int dfl_plm, struct
>> perf_event_attr *attr);
>>
>>
>
>
> This is fine for plm, but there could be other similar default modifiers
> that are needed. For example, invert might have a default value of true for
> some events and false for others. I think the user should have a way of
> querying the defaults, then formulating an event string based on an
> alteration of the defaults (if desired). And I think libpfm should be the
> repository of such default information.
>
But then, if invert is defined, this is part of a predefined unit mask.
Some events on x86 do that. In that case, libpfm refuses to change
to value of the attribute.
> Perhaps, we could add a new api call
>
> pfm_get_event_attr_dfl(int idx, int attr_idx, uint64_t *attr_val);
>
I suspect you meant:
pfm_get_event_attr_dfl(int idx, int attr_idx, int *attr_vals, int *n_attrs);
For a given event, idx, and unit mask, attr_idx, return the opaque identifier
for any default attribute.
> And it would return the default value in attr_val. (I seem to recall
> there's a string attribute type too, but I must be mistaken because it
> doesn't appear to be one of the possible attribute types)
>
> What do you think of this idea as an alternative to the special purpose
> dfl_plm param?
>
With your proposal, how would you solve the issue of a default priv level?
------------------------------------------------------------------------------
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
