linux-kernel - Re: x86 perf's dTLB-load-misses broken on IvyBridge?

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: <20140219084308.GE27965@twins.programming.kicks-ass.net>
Date:	Wed, 19 Feb 2014 09:43:08 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Dave Hansen <dave.hansen@...ux.intel.com>
Cc:	Andi Kleen <ak@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: x86 perf's dTLB-load-misses broken on IvyBridge?

On Tue, Feb 18, 2014 at 03:11:59PM -0800, Dave Hansen wrote:
> I noticed that perf's dTLB-load-misses even t isn't working on my
> Ivybridge system:
> 
> >  Performance counter stats for 'system wide':
> > 
> >                  0      dTLB-load-misses                                             [100.00%]
> >             48,570      dTLB-store-misses                                            [100.00%]
> >            202,573      iTLB-loads                                                   [100.00%]
> >            271,546      iTLB-load-misses          #  134.05% of all iTLB cache hits 
> 
> But it works on a SandyBridge system that I have.
> 
> arch/x86/kernel/cpu/perf_event_intel.c seems to use the same tables for
> SandyBridge and IvyBridge, so they both use the
> 'MEM_UOP_RETIRED.ALL_LOADS' event:
> 
> >  [ C(DTLB) ] = {
> >         [ C(OP_READ) ] = {
> >                 [ C(RESULT_ACCESS) ] = 0x81d0, /* MEM_UOP_RETIRED.ALL_LOADS */
> >                 [ C(RESULT_MISS)   ] = 0x0108, /* DTLB_LOAD_MISSES.CAUSES_A_WALK */
> >         },
> 
> But that event looks to be unsupported on this CPU:
> 
> > /ocperf.py stat -a -e mem_uops_retired.all_loads sleep 1

That kind of snake voo-doo is that?

> > perf stat -a -e cpu/event=0xd0,umask=0x81,name=mem_uops_retired_all_loads/ sleep 1

So this line only produces the mem_uops_retired_all_loads thing, not the
_ps thing.

> > 
> >  Performance counter stats for 'system wide':
> > 
> >    <not supported>      mem_uops_retired_all_loads
> >         50,204,763      mem_uops_retired_all_loads_ps
> 
> But there's a "_ps" version which uses PEBS which does work?

So clearly there is no _ps version, as I'm still utterly confused as to
wtf you mean and where it came from.

> >   mem_uops_retired.all_loads                  [Load uops retired to architected path with filter on bits 0 and 1 applied. (Supports PEBS)]
> >   mem_uops_retired.all_loads_ps               [Load uops retired to architected path with filter on bits 0 and 1 applied.  (Uses PEBS) (Uses PEBS)]

What's that; SDM not haz this.

> Should we swap perf_event_intel.c over to use the PEBS version so that
> it works everywhere?

I'm confused; where does this _ps thing come from? There's nothing like
that in the SDM. That only lists the D0H event, and says it should work.

Of course the SDM is trying to confuse the living daylight out of people
by calling it crap like "3rd gen intel core", which just shows they
can't bloody well count either, since it went:

  core, core2, nhm, wsm, snb, ivb

do its damn well 6th gen.
--
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/