public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org, kan.liang@intel.com,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 1/3] perf, x86: Add new cache events table for Haswell
Date: Wed, 18 Feb 2015 05:58:05 +0100	[thread overview]
Message-ID: <20150218045805.GD13991@two.firstfloor.org> (raw)
In-Reply-To: <20150212212806.GX5029@twins.programming.kicks-ass.net>

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?

Yes.

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

> #define HSW_LLC_ACCESS	(HSW_ANY_RESPONSE)
> #define HSW_LLC_MISS	(HSW_L3_MISS|HSW_ANY_SNOOP)
> 
> Would be the suitable helpers to use here. No need to set Supplier and
> Snoop bits for ANY_RESPONSE.

Ok.

> 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) ] = {
> > +		[ C(RESULT_ACCESS) ] = HSW_DEMAND_READ|
> > +				       HSW_L3_MISS_LOCAL_DRAM|HSW_SUPPLIER_NONE|
> > +				       HSW_ANY_SNOOP,
> 
> 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.
> 
> #define HSW_DRAM_ANY		(HSW_LLC_MISS & ~HSW_SNOOP_NON_DRAM)
> #define HSW_DRAM_REMOTE		(HSW_MISS_LOCAL_DRAM|HSW_ANY_SNOOP & ~HSW_SNOOP_NON_DRAM)

This should be more like
HSW_L3_MISS_REMOTE_HOP0|HSW_L3_MISS_REMOTE_HOP1|HSW_L3_MISS_REMOTE_HOP2P|HSW_ANY_SNOOP & ~HSW_SNOOP_NON_DRAM)

> 
> 6) Should we maybe use
> 
> 	(SNOOP_ANY & ~(SNOOP_HIT_NO_FWD|NON_DRAM))
> 
> instead for DRAM_REMOTE? SNOOP_HIT_NO_FWD seem as inappropriate as
> NON_DRAM for REMOTE.

SNOOP_HIT_NO_FWD indicates DRAM.

-Andi

  reply	other threads:[~2015-02-18  4:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-11  0:40 [PATCH 1/3] perf, x86: Add new cache events table for Haswell Andi Kleen
2015-02-11  0:40 ` [PATCH 2/3] perf, x86: Add Broadwell core support Andi Kleen
2015-02-11  0:40 ` [PATCH 3/3] perf, x86: Add INST_RETIRED.ALL workarounds Andi Kleen
2015-02-12 21:28 ` [PATCH 1/3] perf, x86: Add new cache events table for Haswell Peter Zijlstra
2015-02-18  4:58   ` Andi Kleen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-02-18  2:18 Andi Kleen
2015-03-23  9:45 ` Ingo Molnar
2015-03-23 13:53   ` Peter Zijlstra
2015-03-23 13:55     ` Ingo Molnar
2015-02-09 19:17 Andi Kleen
2015-02-10 10:34 ` Peter Zijlstra
2015-02-10 17:11   ` Andi Kleen
2015-02-10 17:16     ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150218045805.GD13991@two.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=ak@linux.intel.com \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox