linux-kernel - Re: [PATCH] perf events, x86: Implement Sandybridge last-level cache events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1305037078.2226.18.camel@localhost>
Date:	Tue, 10 May 2011 22:17:58 +0800
From:	Lin Ming <ming.m.lin@...el.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>, Andi Kleen <ak@...ux.intel.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] perf events, x86: Implement Sandybridge last-level
 cache events

On Tue, 2011-05-10 at 18:08 +0800, Peter Zijlstra wrote:
> On Mon, 2011-05-09 at 16:39 +0800, Lin Ming wrote:
> 
> >  
> > +/*
> > + * Sandy Bridge MSR_OFFCORE_RESPONSE bits;
> > + * See IA32 SDM Vol 3B 30.8.5
> > + */
> > +
> > +#define SNB_DMND_DATA_RD	(1ULL << 0)
> > +#define SNB_DMND_RFO		(1ULL << 1)
> > +#define SNB_DMND_IFETCH		(1ULL << 2)
> > +#define SNB_DMND_WB		(1ULL << 3)
> > +#define SNB_PF_DATA_RD		(1ULL << 4)
> > +#define SNB_PF_DATA_RFO		(1ULL << 5)
> > +#define SNB_PF_IFETCH		(1ULL << 6)
> > +#define SNB_PF_LLC_DATA_RD	(1ULL << 7)
> > +#define SNB_PF_LLC_RFO		(1ULL << 8)
> > +#define SNB_PF_LLC_IFETCH	(1ULL << 9)
> > +#define SNB_BUS_LOCKS		(1ULL << 10)
> > +#define SNB_STRM_ST		(1ULL << 11)
> > +				/* hole */
> > +#define SNB_OFFCORE_OTHER	(1ULL << 15)
> > +#define SNB_COMMON		(1ULL << 16)
> > +#define SNB_NO_SUPP		(1ULL << 17)
> > +#define SNB_LLC_HITM		(1ULL << 18)
> > +#define SNB_LLC_HITE		(1ULL << 19)
> > +#define SNB_LLC_HITS		(1ULL << 20)
> > +#define SNB_LLC_HITF		(1ULL << 21)
> > +				/* hole */
> > +#define SNB_SNP_NONE		(1ULL << 31)
> > +#define SNB_SNP_NOT_NEEDED	(1ULL << 32)
> > +#define SNB_SNP_MISS		(1ULL << 33)
> > +#define SNB_SNP_NO_FWD		(1ULL << 34)
> > +#define SNB_SNP_FWD		(1ULL << 35)
> > +#define SNB_HITM		(1ULL << 36)
> > +#define SNB_NON_DRAM		(1ULL << 37)
> > +
> > +#define SNB_DMND_READ		(SNB_DMND_DATA_RD)
> > +#define SNB_DMND_WRITE		(SNB_DMND_RFO | SNB_DMND_WB|SNB_STRM_ST)
> > +#define SNB_DMND_PREFETCH	(SNB_PF_DATA_RD | SNB_PF_DATA_RFO)
> > +
> > +#define SNB_SUPPLIER_INFO	(SNB_NO_SUPP | SNB_LLC_HITM | SNB_LLC_HITE | \
> > +				 SNB_LLC_HITS | SNB_LLC_HITF)
> > +
> > +#define SNB_L3_HIT		(SNB_SUPPLIER_INFO | SNB_SNP_NOT_NEEDED | SNB_SNP_NO_FWD | SNB_HITM)
> > +#define SNB_L3_MISS		(SNB_SUPPLIER_INFO | SNB_SNP_MISS | SNB_SNP_FWD | SNB_NON_DRAM)
> > +#define SNB_L3_ACCESS		(SNB_L3_HIT | SNB_L3_MISS)
> 
> I would very much like to know how these bits work.. Since the SDM
> doesn't explain anything could you please add a big comment explaining
> things?

I'm also not sure if the bits combination do count exactly L3_HIT/_MISS.

The manual has below statements,

"To specify a complete offcore response filter, software must properly
program bits in the request and response type fields. A valid request
type must have at least one bit set in the non-reserved bits of 15:0. 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)]
If “ANY“ bit is set, the supplier and snoop info bits are ignored."

So I defined SNB_L3_HIT and SNB_L3_MISS with ANY bit cleared, and
Supplier Info Bits and Snoop Info Bits set.

But again, I'm not sure if the combination is correct.
May need some micro-benchmarks to verify it.

Thanks,
Lin Ming
> 
> Otherwise the patch looks good, but unverifiable so for me.
> 
> > +static __initconst const u64 snb_hw_cache_extra_regs
> > +				[PERF_COUNT_HW_CACHE_MAX]
> > +				[PERF_COUNT_HW_CACHE_OP_MAX]
> > +				[PERF_COUNT_HW_CACHE_RESULT_MAX] =
> > +{
> > + [ C(LL  ) ] = {
> > +	[ C(OP_READ) ] = {
> > +		[ C(RESULT_ACCESS) ] = SNB_DMND_READ | SNB_L3_ACCESS,
> > +		[ C(RESULT_MISS)   ] = SNB_DMND_READ | SNB_L3_MISS,
> > +	},
> > +	[ C(OP_WRITE) ] = {
> > +		[ C(RESULT_ACCESS) ] = SNB_DMND_WRITE | SNB_L3_ACCESS,
> > +		[ C(RESULT_MISS)   ] = SNB_DMND_WRITE | SNB_L3_MISS,
> > +	},
> > +	[ C(OP_PREFETCH) ] = {
> > +		[ C(RESULT_ACCESS) ] = SNB_DMND_PREFETCH | SNB_L3_ACCESS,
> > +		[ C(RESULT_MISS)   ] = SNB_DMND_PREFETCH | SNB_L3_MISS,
> > +	},
> > + }
> > +};
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/