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: Windows password security audit tool. GUI, reports in PDF.

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

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

On Wed, May 28, 2014 at 02:18:09PM +0800, Yan, Zheng wrote:
> PEBS always had the capability to log samples to its buffers without
> an interrupt. Traditionally perf has not used this but always set the
> PEBS threshold to one.
> 
> For the common cases we still need to use the PMI because the PEBS
> hardware has various limitations. The biggest one is that it can not
> supply a callgraph. It also requires setting a fixed period, as the
> hardware does not support adaptive period. Another issue is that it
> cannot supply a time stamp and some other options. 

So the reason I've never done this is because Intel has never fully
explained the demuxing of pebs events.

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.

This is a problem, since if multiple counters overflow multiple bits
will be set and its (afaict) ambiguous which event is for which counter.

At one point it was said they'd fix this 0x90 offset to indicate which
counter triggered the event, but I've never heard back if this happened.

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.

> 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.

Content of type "application/pgp-signature" skipped