linux-kernel - Re: [patch] perf: ARMv7 wrong "branches" generalized instruction

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, 10 Aug 2011 15:01:20 -0400
From:	Vince Weaver <vweaver1@...s.utk.edu>
To:	Will Deacon <will.deacon@....com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	sam wang <linux.swang@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Stephane Eranian <eranian@...il.com>
Subject: Re: [patch] perf: ARMv7 wrong "branches" generalized instruction

On Wed, 10 Aug 2011, Will Deacon wrote:

> > It turns out the branches event used (ARMV7_PERFCTR_PC_WRITE) only seems
> > to count taken branches.
>
> It also counts exceptions and instructions that write to the PC.

are those more common than not-taken branches?  I'd think branch predictor 
statistics will be a bit off if only taken instructions are measured.

> > ARMV7_PERFCTR_PC_IMM_BRANCH seems to do a better job of counting both 
> > taken and not-taken.  So I've attached a patch to change the definition
> > for Cotex A9.
>
> Well, it also only considers immediate branches so whilst it might 
> satisy your test, I think that overall it's a less meaningful number.

I guess there isn't more info available about which branches exactly are 
counted by all the events?  I've gone through the trouble of writing such 
tests to find out experimentally what various counters count for x86, it 
would be sad to have to do it again for ARM.

> (b) start replacing our generalised events with HW_OP_UNSUPPORTED and force
>     the user to use raw events. I agree this isn't very friendly, but it's
>     better than giving them crazy results [for example, we currently report
>     more cache misses than cache references on A9 iirc].
> 
> Personally, I'm favour of (b) and getting userspace to provide the user with
> a CPU-specific event listing and then translate this to raw events using
> something like libpfm.

I agree 100%, but it's an unpopular opinion on linux-kernel.  (Note that 
I'm the one who contributed ARM Cortex A8/A9 support to both libpfm4 and 
PAPI).

Since the generalized events are there and ABI though, people are going to 
use them.  That's why I've been writing tests that check them to see 
exactly what they are measuring.

It's still an important issue to know what "branches" measures, just it 
probably shouldn't be a kernel issue like it's become.

Vince
vweaver1@...s.utk.edu

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