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

Reply via email to