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.
Perhaps, we could add a new api call
pfm_get_event_attr_dfl(int idx, int attr_idx, uint64_t *attr_val);
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?
- Corey
> On Mon, Nov 23, 2009 at 4:15 PM, stephane eranian
> <eran...@googlemail.com> wrote:
>> Phil,
>>
>> On Sun, Nov 22, 2009 at 5:23 PM, Philip Mucci <mu...@eecs.utk.edu> wrote:
>>> On Nov 19, 2009, at 7:45 PM, Corey Ashford wrote:
>>>
>>>> stephane eranian wrote:
>>>>> On Fri, Nov 20, 2009 at 12:06 AM, Corey Ashford
>>>>> <cjash...@linux.vnet.ibm.com> wrote:
>>>>>> Hi Stephane,
>>>>>>
>>>>>> I am testing an implementation of libpfm4, and ran into some curious
>>>>>> behavior with the plm field in the perf_event_attr structure. The code
>>>>>> makes it appear to be intentional, but I thought I'd run this by you to
>>>>>> see
>>>>>> if it's what you had intended.
>>>>>>
>>>>>> If I specify an event, such as PM_RUN_CYC:i, and I don't specify any
>>>>>> u,k, or
>>>>>> h modifiers, none of the exclude_* bits in the perf_events attribute
>>>>>> record
>>>>>> get set. This seems ok; users may want to have events counted in all
>>>>>> privilege levels by default.
>>>>>>
>>>>>> However, if I specify "PM_RUN_CYC:i:k=0", saying I don't want kernel
>>>>>> samples, I actually get all samples, because of this code:
>>>>>>
>>>>>> if (perf_attrs.plm) {
>>>>>> hw->exclude_user = !(perf_attrs.plm & PFM_PLM3);
>>>>>> hw->exclude_kernel = !(perf_attrs.plm & PFM_PLM0);
>>>>>> hw->exclude_hv = !(perf_attrs.plm & PFM_PLMH);
>>>>>> }
>>>>>>
>>>>>> perf_attrs.plm is set to zero, if I set k=0. If I were using this
>>>>>> interface, I'd probably want hw->exclude_kernel to be set to 1.
>>>>>>
>>>>> You are right, I think there is a problem there.
>>>>>
>>>>> I think it is okay to have by default: measure everything
>>>>>
>>>>> The problem is that there is something missing in perf_attrs.
>>>>> One way to make it work could be to have
>>>>> perf_attrs.plm = PLM0|PLM3 to match the default settings and
>>>>> then have the model specific code, toggle this if the plm is not set.
>>>>> For instance,
>>>>>
>>>>> if (!reg.sel_os)
>>>>> perf_attrs.plm &= ~PLM0
>>>>>
>>>>> So you would do:
>>>>> perf.attrs = PLM0|PLM3;
>>>>> excl_u = excl_k = 0;
>>>>>
>>>>> get_encoding(, ..., &perf_attrs);
>>>>>
>>>>> if (!(perf_attrs.plm & PLM0))
>>>>> excl_k = 1
>>>>>
>>>>> if (!(perf_attrs.plm & PLM3))
>>>>> excl_u = 1
>>>> I think one of the issues here is that the user doesn't know what the
>>>> default
>>>> is. So he doesn't know when he needs to clear or set the bits. If the
>>>> default
>>>> is user+kernel+hypervisor, then only "u=0" (etc.) can be specified to
>>>> change
>>>> that. "u" or "u=1" would have no effect since all bits are set to true by
>>>> default. Or am I missing something here?
>>>>
>>> I think the default should always be to just count the user mode. This would
>>> be consistent with previous perfmon (and perfctr) implementations...
>>>
>> That's a good point. Note however that the default for the perf_events
>> kernel API
>> is to measure both kernel and user, i.e., exclude_user =
>> exclude_kernel = exclude_hv = 0.
>>
>> But we can make that change in libpfm4.
>>
>>> Phil
>>>
>>>
>>>> Maybe we need an API function to obtain the defaults for each legal
>>>> modifier?
>>>> Tools could then display the defaults and the user can choose to modify
>>>> those
>>>> defaults, if desired.
>>>>
>>>> I think this function would have somewhat wider use too: events may have
>>>> per-event defaults for modifiers. If this function was available, the
>>>> encoding
>>>> function could use it internally as well when encoding an event.
>>>>
>>>> I have a vague feeling that I'm making this too complex, but I don't see
>>>> other
>>>> alternatives at the moment.
>>>>
>>>> Any other thoughts would be appreciated.
>>>>
>>>> Regards,
>>>>
>>>> - Corey
>>>>
>>>> Corey Ashford
>>>> Software Engineer
>>>> IBM Linux Technology Center, Linux Toolchain
>>>> Beaverton, OR
>>>> 503-578-3507
>>>> cjash...@us.ibm.com
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>
--
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjash...@us.ibm.com
------------------------------------------------------------------------------
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
