Message-ID: <20150323135318.GN21418@twins.programming.kicks-ass.net>
Date:	Mon, 23 Mar 2015 14:53:18 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 1/3] perf, x86: Add new cache events table for Haswell

On Mon, Mar 23, 2015 at 10:45:07AM +0100, Ingo Molnar wrote:
> 
> * Andi Kleen <andi@...stfloor.org> wrote:
> 
> > From: Andi Kleen <ak@...ux.intel.com>
> > 
> > Haswell offcore events are quite different from Sandy Bridge.
> > Add a new table to handle Haswell properly.
> > 
> > Note that the offcore bits listed in the SDM are not quite correct
> > (this is currently being fixed). An uptodate list of bits is
> > in the patch.
> > 
> > The basic setup is similar to Sandy Bridge. The prefetch columns
> > have been removed, as prefetch counting is not very reliable
> > on Haswell. One L1 event that is not in the event list anymore
> > has been also removed.
> > 
> > - data reads do not include code reads (comparable to earlier Sandy
> > Bridge tables)
> > - data counts include speculative execution (except L1 write, dtlb, bpu)
> > - remote node access includes both remote memory, remote cache, remote mmio.
> > - prefetches are not included in the counts for consistency
> > (different from Sandy Bridge, which includes prefetches in the remote node)
> > 
> > The events with additional caveats have references to the specification update.
> 
> > +		[ C(RESULT_ACCESS) ] = 0x81d0,	/* MEM_UOPS_RETIRED.ALL_LOADS, HSM30 */
> > +		[ C(RESULT_ACCESS) ] = 0x82d0,	/* MEM_UOPS_RETIRED.ALL_STORES, HSM30 */
> > +		[ C(RESULT_ACCESS) ] = 0x81d0,	/* MEM_UOPS_RETIRED.ALL_LOADS, HSM30 */
> > +		[ C(RESULT_ACCESS) ] = 0x82d0,	/* MEM_UOPS_RETIRED.ALL_STORES, HSM30 */
> 
> So that 'HSM30' is code for the specification update?

Yep; found it in:
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-mobile-specification-update.pdf

> You'll need to properly describe HSM30 at least once instead of using 
> obfuscation.


HSM30.
Problem:
Performance Monitor Counters May Produce Incorrect Results
When operating with SMT enabled, a memory at-retirement performance monitoring
event (from the list below) may be dropped or may increment an enabled event on the
corresponding counter with the same number on the physical core’s other thread rather
than the thread experiencing the event. Processors with SMT disabled in BIOS are not
affected by this erratum.
The list of affected memory at-retirement events is as follows:
MEM_UOP_RETIRED.LOADS
MEM_UOP_RETIRED.STORES
MEM_UOP_RETIRED.LOCK
MEM_UOP_RETIRED.SPLIT
MEM_UOP_RETIRED.STLB_MISS
MEM_LOAD_UOPS_RETIRED.HIT_LFB
MEM_LOAD_UOPS_RETIRED.L1_HIT
MEM_LOAD_UOPS_RETIRED.L2_HIT
MEM_LOAD_UOPS_RETIRED.L3_HIT
MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_HIT
MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_HITM
MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_MISS
MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_NONE
MEM_LOAD_UOPS_RETIRED.L3_MISS
MEM_LOAD_UOPS_L3_MISS_RETIRED.LOCAL_DRAM
MEM_LOAD_UOPS_L3_MISS_RETIRED.REMOTE_DRAM
MEM_LOAD_UOPS_RETIRED.L2_MISS
Implication:
Due to this erratum, certain performance monitoring event will produce unreliable
results during hyper-threaded operation.
Workaround:
None identified.
Status:
For the steppings affected, see the Summary Table of Changes.

Stephane is working on patches to address this. It affects multiple
generations.
--
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/

Powered by blists - more mailing lists