Re: [PATCH 1/3] perf, x86: Add new cache events table for Haswell

From: Andi Kleen
Date: Tue Feb 17 2015 - 23:58:13 EST

On Thu, Feb 12, 2015 at 10:28:06PM +0100, Peter Zijlstra wrote:
> 1) SDM (2014-09) says in 18.9.5 (snb offcore):
> "software must set at least one request type bit and a valid response
> type pattern"
> and
> "A valid response type must be a non-zero value of the following
> expression:
> ANY | [('OR' of Supplier Info Bits) & ('OR' of Snoop Info Bits)]"
> Is this still valid for the HSW part?


However they need to be set on Sandy Bridge to work around an issue.
On HSW they don't hurt at least.

> Would be the suitable helpers to use here. No need to set Supplier and
> Snoop bits for ANY_RESPONSE.


> 2) I know I included it on SNB, but would SNOOP_HITM really be a miss?
> From what I can tell it could be a local MtoS w/ WB or so. Do we count
> it as a miss because the WB part goes to DRAM so we still get to wait
> for it (just in the 'wrong' direction)?

SNOOP_HITM is a miss because M is only present in one cache.
So it's a miss for the requester.

> 3) While we're there, will we get SNOOP_FWD only for Clean forwards or
> also for the HITM forwards; the SDM is vague -- it would be nice if
> SNOOP_FWD was a selector for all remote socket snoops.

It's only for clean forwards.

> > + [ C(NODE) ] = {
> > + [ C(OP_READ) ] = {
> 4) SUPPLIER_NONE; I'll interpret it as specific event that lacks other
> supplier info (as opposed to _any_ supplier). What kind of events would
> this be?

Your interpretation is right.
Ok, we can drop it. It should rarely happen.

> I didn't include SUPPLIER_NONE in any events on SNB, its implied by
> L3_ACCESS due to ANY, but other than that I'm not sure what to do with
> it. It seems out of place for DRAM_ANY.
> 5) NODE-ACCESS is _any_ DRAM;
> NODE-MISS is remote DRAM.
> for SNB I didn't include NON_DRAM in ANY_SNOOP for this reason.

This should be more like

> 6) Should we maybe use
> instead for DRAM_REMOTE? SNOOP_HIT_NO_FWD seem as inappropriate as


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at