Arun,
Ok, I cleaned this up.
Basically dfl_plm may be ignored by PMU models which do not
support priv level filtering. Given you cannot set per-event
priv level mask for uncore PMU, we can safely hardcode that
all exclude_* are zero.
Pull from git again.
On Sat, Feb 26, 2011 at 12:37 AM, stephane eranian
<eran...@googlemail.com> wrote:
> On Sat, Feb 26, 2011 at 12:34 AM, Arun Sharma <asha...@fb.com> wrote:
>>
>> I had to hack around one thing to make perf+libpfm4 work with uncore events:
>>
>> --- a/lib/pfmlib_perf_event.c
>> +++ b/lib/pfmlib_perf_event.c
>> @@ -153,7 +153,7 @@ pfmlib_perf_event_encode(void *this, const char *str,
>> int dfl_plm, void *data)
>>
>> attr->exclude_user = !(plm & PFM_PLM3);
>> attr->exclude_kernel = !(plm & PFM_PLM0);
>> - attr->exclude_hv = !(plm & PFM_PLMH);
>> + //attr->exclude_hv = !(plm & PFM_PLMH);
>>
>> The problem is that the kernel expects exclude_hv == 0, otherwise the
>> perf_event_open syscall errors out. However, if I pass PFM_PLMH
>> pfm_get_perf_event_encoding(), I get a different error.
>>
>> static int
>> pfm_nhm_unc_get_encoding(void *this, pfmlib_event_desc_t *e)
>> {
>> ...
>> if (e->dfl_plm != (PFM_PLM0|PFM_PLM3)) {
>> DPRINT("dfl_plm must be PLM0|PLM3 with Intel uncore PMU\n");
>> return PFM_ERR_INVAL;
>> }
>> }
>>
>> Perhaps there is a better answer?
>>
> Yeah, I need to cleanup this part.
> Need to think of a good way of handling this at the perf_event layer.
>
>> -Arun
>>
>>
>
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
