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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140528171957.GW30445@twins.programming.kicks-ass.net>
Date:	Wed, 28 May 2014 19:19:57 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Stephane Eranian <eranian@...gle.com>,
	"Yan, Zheng" <zheng.z.yan@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [RFC PATCH 6/7] perf, x86: large PEBS interrupt threshold

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.

Content of type "application/pgp-signature" skipped