lkml.org 
[lkml]   [2014]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 6/7] perf, x86: large PEBS interrupt threshold
On Wed, May 28, 2014 at 07:58:31AM -0700, Andi Kleen wrote:
> > In particular, the 0x90 offset (IA32_PERF_GLOBAL_STATUS). Intel once
> > confirmed to me that that is a direct copy of the similarly named MSR at
> > the time of the PEBS assist.
>
> That is correct.
>
> >
> > This is a problem, since if multiple counters overflow multiple bits
> > will be set and its (afaict) ambiguous which event is for which counter.
>
> When a PEBS counter overflows it clears its respective GLOBAL_STATUS bit
> automatically.

That's an ambiguous statement; did you mean to say a PEBS enabled
counter will not raise its bit in GLOBAL_STATUS on counter overflow?

Because if it does raise it, but then clears it again, its raised for a
short while and might be observed.

Anyway, you've still not entirely explained the full life cycle of those
bits in excruciating detail, please do so now.

Also, try and get it included in the SDM.

> > So until you can give an official Intel answer on how all this demuxing
> > is supposed to work and be correct this patch set isn't moving anywhere.
>
> FWIW a patch signed off by intel.com is an official Intel statement.

Is that the reason they have such vague and non-committal Changelogs? Be
detailed and explicit.

On that same note; can someone shoot whoever writes the new SDM bits?
They're nearly impossible to comprehend, its like a patent lawyer was
involved with the end result of having a text explicitly engineered to
not be understood :-(

> > > To supply a TID it
> > > requires flushing on context switch. It can however supply the IP
> >
> > On SNB+, previous to SNB it would need to have precise==1. I've seen no
> > such logic in. Instead you seem to artificially limit it to SNB+, for no
> > apparent reason to me.
>
> Only tested on Sandy Bridge+

That's just ... /me lacking words.. the worst reason possible for
arbitrary limits, esp. since you guys actually have the hardware to test
older chips.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2014-05-28 18:21    [W:0.231 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site