From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752848AbbBRE6K (ORCPT ); Tue, 17 Feb 2015 23:58:10 -0500 Received: from one.firstfloor.org ([193.170.194.197]:44740 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752668AbbBRE6I (ORCPT ); Tue, 17 Feb 2015 23:58:08 -0500 Date: Wed, 18 Feb 2015 05:58:05 +0100 From: Andi Kleen To: Peter Zijlstra Cc: Andi Kleen , linux-kernel@vger.kernel.org, kan.liang@intel.com, Andi Kleen Subject: Re: [PATCH 1/3] perf, x86: Add new cache events table for Haswell Message-ID: <20150218045805.GD13991@two.firstfloor.org> References: <1423615224-6912-1-git-send-email-andi@firstfloor.org> <20150212212806.GX5029@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150212212806.GX5029@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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