linux-kernel - Re: [PATCH 6/7] perf, x86: Example code for AMD IBS

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: <4E39065C.6020801@orcon.net.nz>
Date:	Wed, 03 Aug 2011 20:27:08 +1200
From:	Michael Cree <mcree@...on.net.nz>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Robert Richter <robert.richter@....com>,
	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Lin Ming <ming.m.lin@...el.com>
Subject: Re: [PATCH 6/7] perf, x86: Example code for AMD IBS

On 02/08/11 22:37, Peter Zijlstra wrote:
> On Mon, 2011-08-01 at 07:50 +0200, Robert Richter wrote:
>> On 29.07.11 12:58:49, Peter Zijlstra wrote:
>>> On Thu, 2011-07-28 at 15:46 +0200, Robert Richter wrote:
>>>>  tools/perf/Documentation/examples/ibs.c    |  436 ++++++++++++++++++++++++++++
>>>
>>> That really isn't the place for this..
>>>
>>> Also, how similar is the Alpha PMU to AMD IBS?

The Alpha PMU (on the EV67 and later CPUs) has two counter modes:
"Aggregate" which is like counters on other CPUs and implemented in the
kernel, and "ProfileMe", which is not currently used in the perf. event
subsystem.

In the "ProfileMe" mode a counter is initialised with max_count-N and
when the counter overflows (i.e. after execution of ~N instructions) a
window is opened for profiling.  The window closes (roughly) when the
profiled instruction is retired from the pipeline.  The two counters
count events such as instructions, cycles, Bcache misses, etc. during
the window.  When the window is closed an interrupt to the PMU interrupt
handler is made.  The two counters can be read and there are other
registers that can be read that provide information on the profiled
instruction's flight through the pipeline, such as instruction killed
before being mapped (i.e. it was identified as a nop), instruction
stalled between fetch and being mapped (usually due to operands not data
ready), branch direction and branch misprediction (if instruction is a
branch), instruction was in a new Icache fill stream, instruction
trapped and trap type, and so on.

>> Would you prefer
>>
>>  tools/perf/Documentation/examples/x86/ibs.c
>>
>> instead?
> 
> Possibly, but having just looked at the example again I don't really see
> it doing anything perf-record doesn't already do, so why does it deserve
> to live at all?
> 
> Initially I thought it was a record+report like example, some code
> interpreting the 'mess' that comes out of IBS would be most appreciated
> and I think we can even ship that as perf-ibs-report/perf-ibs-annotate
> or so (and if its still remotely similar to its Alpha precursor that
> might make the Alpha folks happy too).

Sure would be nice if the infrastructure to support ProfileMe mode
appeared in the perf. events subsystem.  I am not going to go full out
to implement all the support needed for it because there are too few
users on Alpha to justify the effort.  But if we could score an
implementation of ProfileMe mode with minimal effort on the back of an
AMD implementation that would make us happy.

Cheers
Michael.
--
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/