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
next prev parent 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