linux-kernel - Re: HW perf. events arch implementation

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] [day] [month] [year] [list]

Date:	Wed, 24 Mar 2010 09:16:59 +1300
From:	Michael Cree <mcree@...on.net.nz>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, linux-alpha@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: HW perf. events arch implementation

On 6/03/2010, at 11:20 AM, Peter Zijlstra wrote:
> On Wed, 2010-02-24 at 14:35 +1300, Michael Cree wrote:
>> I am trying to implement arch specific code on the Alpha for hardware
>> performance events
> Right, so the architecture interface is 2 fold, a struct pmu, and a
> bunch of weak hw_perf_*() functions.

Thanks for the description of the hw perf arch interface.

I have now identified why my code on the Alpha didn't work.  I had  
borrowed the code for reading the hw counters and calculating deltas  
from the sparc/x86 code, but I now realise that code is based on the  
assumption that the hw counters are read frequently enough that the  
counter cannot count more than half of its maximum period between  
updates.  That assumption is violated on the Alpha (which has 20 bit  
counters) and I was occasionally getting negative deltas.

Your comment following is relevant:

> As to your counter width, if you have a special overflow bit in a
> separate register then you can possibly use that, but otherwise you  
> need
> it to keep your count straight.

On the Alpha which counter caused the overflow is passed to the  
interrupt routine so I have used that to keep the count straight.

It is also appears that the interrupt routine, when it calls  
perf_event_overflow() can incur quite a bit of execution so I disable  
the hw counters for the duration of the interrupt routine.

I therefore will complete the coding for measuring cycles,  
instructions, cache misses and mbox replays (the last one I presume  
will have to be coded as a RAW event) on the EV67 CPUs and later.  At  
this stage I will probably keep it simple and implement counting one  
hw event at a time only.  Might be able to submit something for review  
within the week; but it could be three or four weeks in coming since I  
go on holiday for 12 days about Easter.

I have no plans to implement hw perf events on Alpha CPUs older than  
the EV67 unless someone jumps up and down and says they really need it!

>> Also, the Alpha CPUs have an interesting mode whereby one programmes
>> up one counter with a specified (or random) value that specifies a
>> future instruction to profile.  The CPU runs for that number of
>> instructions/cycles, then a short monitoring window (of a few cycles)
>> is opened about the profiled instruction and when completed an
>> interrupt is generated.  One can then read back a whole lot of
>> information about the pipeline at the time of the profiled
>> instruction.  This can be used for statistical sampling.  Does the
>> performance events subsystem support monitoring with such a mode?
>
> That sounds like AMD IBS, which I've been told is based on the Alpha
> PMU. We currently do no have AMD IBS supported.

I will therefore leave implementing that mode for the future.

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/