linux-kernel - Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format

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]

Date:	Wed, 04 Jul 2012 11:13:25 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Michael Ellerman <michael@...erman.id.au>
Cc:	Feng Tang <feng.tang@...el.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	x86@...nel.org, Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Robert Richter <robert.richter@....com>
Subject: Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw
 format

On Wed, 2012-07-04 at 18:07 +1000, Michael Ellerman wrote:
> Basically we have three registers which provide various information about
> the instruction which caused an event to overflow.
> 
> The first reports the address of the instruction, the second the data
> address associated with the instruction, and the third reports "other
> stuff".
> 
> We use the first for SAMPLE_IP, and the second for SAMPLE_ADDR, but
> currently we have no way of spitting out the third register.
> 
> There's a whole bunch of info in there. I think the most interesting are
> stuff like whether and where in the pipeline the instruction stalled, or
> where a load was serviced from. I'm not sure to be honest, so I've asked
> the HW guys what they're most interested in.
> 
> So I can imagine us coming up with a generic sample type for "sample
> other info at event overflow", but I'm struggling to see how we'd make
> the content of the sample non architecture specific, or even processor
> version specific. 

Right so we're working on a data-source like thing, the last attempt at
adding something like that is in this thread:

 http://marc.info/?l=linux-kernel&m=130987553915170&w=2
 http://marc.info/?l=linux-kernel&m=131000375226044

I think Stephane is currently trying to revive that, although he hasn't
posted yet. Please have a look if that captures the possible PPC states
as well. Stephane could you share your current stuff so Michael can have
a look?


Not quite sure what to do for your pipeline stage thing, I'm not sure
I've seen that elsewhere.


Anyway, yes PERF_SAMPLE_RAW is the 'other info at overflow' which is
specific to the current cpu and phase of moon type field, and it does
get (ab)used in various places, but I still cringe every time I see it
used.

The problem with that thing is that it gives people the data they need
for their special tools and thus removes them from the incentive pool to
help create more generic,useful tools.

For AMD IBS we've given in since that thing is completely weird, IIRC
Robert was going to grow perf-ibs to record and report the data it
captures so we've at least got a useful open-source tool for it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/