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.
pgpPkcqRQBiYT.pgp
Description: PGP signature
