* Stephane Eranian wrote:
> On Sun, Oct 21, 2012 at 8:03 PM, Ingo Molnar wrote:
> >
> > * Stephane Eranian wrote:
> >
> >> On Sun, Oct 21, 2012 at 6:55 PM, Ingo Molnar wrote:
> >> >
> >> > * Andi Kleen wrote:
> >> >
> >> >> > > > This isn't limited to admin, right? So the above turns into a
On Sun, Oct 21, 2012 at 8:03 PM, Ingo Molnar wrote:
>
> * Stephane Eranian wrote:
>
>> On Sun, Oct 21, 2012 at 6:55 PM, Ingo Molnar wrote:
>> >
>> > * Andi Kleen wrote:
>> >
>> >> > > > This isn't limited to admin, right? So the above turns into a DoS
>> >> > > > on the
>> >> > > > console.
>>
* Stephane Eranian wrote:
> On Sun, Oct 21, 2012 at 6:55 PM, Ingo Molnar wrote:
> >
> > * Andi Kleen wrote:
> >
> >> > > > This isn't limited to admin, right? So the above turns into a DoS on
> >> > > > the
> >> > > > console.
> >> > > >
> >> > > Ok, so how about a WARN_ON_ONCE() instead?
> >
On Sun, Oct 21, 2012 at 6:55 PM, Ingo Molnar wrote:
>
> * Andi Kleen wrote:
>
>> > > > This isn't limited to admin, right? So the above turns into a DoS on
>> > > > the
>> > > > console.
>> > > >
>> > > Ok, so how about a WARN_ON_ONCE() instead?
>> >
>> > That should be fine I guess ;-)
>>
>> im
* Andi Kleen wrote:
> > > > This isn't limited to admin, right? So the above turns into a DoS on the
> > > > console.
> > > >
> > > Ok, so how about a WARN_ON_ONCE() instead?
> >
> > That should be fine I guess ;-)
>
> imho there is need for a generic mechanism to return an error
> string to
> > > This isn't limited to admin, right? So the above turns into a DoS on the
> > > console.
> > >
> > Ok, so how about a WARN_ON_ONCE() instead?
>
> That should be fine I guess ;-)
imho there is need for a generic mechanism to return an error string
to the user program without such hacks.
-And
On Fri, 2012-10-19 at 18:31 +0200, Stephane Eranian wrote:
> On Fri, Oct 19, 2012 at 6:27 PM, Peter Zijlstra wrote:
> > On Fri, 2012-10-19 at 16:52 +0200, Stephane Eranian wrote:
> >> +static int intel_pebs_aliases_snb(struct perf_event *event)
> >> +{
> >> + u64 cfg = event->hw.config;
> >>
On Fri, Oct 19, 2012 at 6:27 PM, Peter Zijlstra wrote:
> On Fri, 2012-10-19 at 16:52 +0200, Stephane Eranian wrote:
>> +static int intel_pebs_aliases_snb(struct perf_event *event)
>> +{
>> + u64 cfg = event->hw.config;
>> + /*
>> +* for INST_RETIRED.PREC_DIST to work correctly
On Fri, 2012-10-19 at 16:52 +0200, Stephane Eranian wrote:
> +static int intel_pebs_aliases_snb(struct perf_event *event)
> +{
> + u64 cfg = event->hw.config;
> + /*
> +* for INST_RETIRED.PREC_DIST to work correctly with PEBS, it must
> +* be measured alone on SNB (exclu
On Fri, Oct 19, 2012 at 5:49 PM, Andi Kleen wrote:
>> + /*
>> + * for INST_RETIRED.PREC_DIST to work correctly with PEBS, it must
>> + * be measured alone on SNB (exclusive PMU access) as per Intel SDM.
>> + */
>> + if ((cfg & INTEL_ARCH_EVENT_MASK) == 0x01c0 && !event->attr
> + /*
> + * for INST_RETIRED.PREC_DIST to work correctly with PEBS, it must
> + * be measured alone on SNB (exclusive PMU access) as per Intel SDM.
> + */
> + if ((cfg & INTEL_ARCH_EVENT_MASK) == 0x01c0 && !event->attr.exclusive) {
> + pr_info("perf: INST_RETIRED
On all Intel SandyBridge processors, the INST_RETIRED:PREC_DIST
when used with PEBS must be measured alone. That means no other
event can be active on the PMU at the same time as per Intel SDM
Vol3b. This is what the exclusive mode of perf_events provides.
However, it was not enforced for that even
12 matches
Mail list logo
