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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.