Re: [RFC PATCH 6/7] perf, x86: large PEBS interrupt threshold

[Peter Zijlstra]

On Wed, May 28, 2014 at 10:12:43AM -0700, Andi Kleen wrote:
> > So, you're telling me this is a sanity check. That p->status can
> > only have one bit set. Somehow that's not how I recall it working.
> 
> It can have multiple bits set. We don't know for sure for which
> it is, but we should only deliver it for one anyways.
> 
> > The point is that a single PEBS record is enough for multiple
> > events when the overflows occur simultaneously because they
> > all get the same machine state which is correct.  A single entry
> > also saves space in the buffer.
> 
> The CPU will generate multiple PEBS records in this case.
> So if we delivered it for all you would overcount by factor 4x
> 
> [Again this is a very unlikely situation. Normally counters
> are not in lock step]

Well, the thing is, the delay between overflow and the assist being
armed can be quite a few cycles, and then waiting for the next event to
trigger can again be quite a few cycles.

So the window is fairly large for another to slip in, esp if you have a
fast (say inst-ret) and a slow (say br-misp) event.

Also, it really blows this never got addressed, even though I've been
complaining about this for years.

Attachment: pgpqM1TF_wvXN.pgp
Description: PGP signature