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);
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
>>
>>
>
------------------------------------------------------------------------------
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
