Re: [PATCH 1/3] perf, x86: Add new cache events table for Haswell

From: Peter Zijlstra
Date: Tue Feb 10 2015 - 05:35:10 EST


On Mon, Feb 09, 2015 at 11:17:44AM -0800, Andi Kleen wrote:
> +++ b/arch/x86/kernel/cpu/perf_event_intel.c
> @@ -415,6 +415,199 @@ static __initconst const u64 snb_hw_cache_event_ids
>
> };
>
> +/*
> + * Notes on the events:
> + * - data reads do not include code reads (comparable to earlier tables)
> + * - data counts include speculative execution (except L1 write, dtlb, bpu)
> + * - remote node access includes both remote memory, remote cache, remote mmio.
> + * - prefetches are not included in the counts.
> + * The events with additional caveats have references to the specification update.
> + */

It would be good to have the prefetch note from the changelog in a
comment here or at the extra_regs table; i.e. prefetches are not
included because they're 'broken'.

> +
> +#define HSW_DEMAND_DATA_RD BIT(0)
> +#define HSW_DEMAND_RFO BIT(1)
> +#define HSW_PF_L2_RFO BIT(5)
> +#define HSW_PF_L3_RFO BIT(8)
> +#define HSW_ALL_RFO (HSW_DEMAND_RFO| \
> + HSW_PF_L2_RFO|HSW_PF_L3_RFO)
> +#define HSW_ANY_RESPONSE BIT(16)
> +#define HSW_SUPPLIER_NONE BIT(17)
> +#define HSW_L3_MISS_LOCAL BIT(22)
> +#define HSW_L3_MISS_REMOTE_HOP0 BIT(27)
> +#define HSW_L3_MISS_REMOTE_HOP1 BIT(28)
> +#define HSW_L3_MISS_REMOTE_HOP2P BIT(29)
> +#define HSW_L3_MISS (HSW_L3_MISS_LOCAL| \
> + HSW_L3_MISS_REMOTE_HOP0|HSW_L3_MISS_REMOTE_HOP1| \
> + HSW_L3_MISS_REMOTE_HOP2P)
> +#define HSW_SNOOP_NONE BIT(31)
> +#define HSW_SNOOP_NOT_NEEDED BIT(32)
> +#define HSW_SNOOP_MISS BIT(33)
> +#define HSW_SNOOP_HIT_NO_FWD BIT(34)
> +#define HSW_SNOOP_HIT_WITH_FWD BIT(35)
> +#define HSW_SNOOP_HITM BIT(36)
> +#define HSW_SNOOP_NON_DRAM BIT(37)
> +#define HSW_ANY_SNOOP (HSW_SNOOP_NONE| \
> + HSW_SNOOP_NOT_NEEDED|HSW_SNOOP_MISS| \
> + HSW_SNOOP_HIT_NO_FWD|HSW_SNOOP_HIT_WITH_FWD| \
> + HSW_SNOOP_HITM|HSW_SNOOP_NON_DRAM)

Just in case someone is crazy enough to run a 32bit kernel on HSW, this
needs to be BIT_ULL() -- also for compile testing, gcc tends to complain
about things like (1UL << 32) for ILP32 targets.

> +static __initconst const u64 hsw_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) ] = HSW_DEMAND_DATA_RD|
> + HSW_ANY_RESPONSE|HSW_ANY_SNOOP|
> + HSW_SUPPLIER_NONE,
> + [ C(RESULT_MISS) ] = HSW_DEMAND_DATA_RD|
> + HSW_L3_MISS|HSW_ANY_SNOOP|
> + HSW_SUPPLIER_NONE,
> + },
> + [ C(OP_WRITE) ] = {
> + [ C(RESULT_ACCESS) ] = HSW_DEMAND_RFO|
> + HSW_ANY_RESPONSE|HSW_ANY_SNOOP|
> + HSW_SUPPLIER_NONE,
> + [ C(RESULT_MISS) ] = HSW_DEMAND_RFO|HSW_L3_MISS|
> + HSW_ANY_SNOOP|HSW_SUPPLIER_NONE,
> + },
> + [ C(OP_PREFETCH) ] = {
> + [ C(RESULT_ACCESS) ] = 0x0,
> + [ C(RESULT_MISS) ] = 0x0,
> + },
> + },
> + [ C(NODE) ] = {
> + [ C(OP_READ) ] = {
> + [ C(RESULT_ACCESS) ] = HSW_DEMAND_DATA_RD|
> + HSW_L3_MISS_LOCAL|HSW_SUPPLIER_NONE|
> + HSW_ANY_SNOOP,
> + [ C(RESULT_MISS) ] = HSW_DEMAND_DATA_RD|
> + HSW_L3_MISS_REMOTE_HOP0|HSW_L3_MISS_REMOTE_HOP1|
> + HSW_L3_MISS_REMOTE_HOP2P|HSW_SUPPLIER_NONE|
> + HSW_ANY_SNOOP,
> + },
> + [ C(OP_WRITE) ] = {
> + [ C(RESULT_ACCESS) ] = HSW_DEMAND_RFO|
> + HSW_L3_MISS_LOCAL|HSW_SUPPLIER_NONE|
> + HSW_ANY_SNOOP,
> + [ C(RESULT_MISS) ] = HSW_DEMAND_RFO|
> + HSW_L3_MISS_REMOTE_HOP0|HSW_L3_MISS_REMOTE_HOP1|
> + HSW_L3_MISS_REMOTE_HOP2P|HSW_SUPPLIER_NONE|
> + HSW_ANY_SNOOP,
> + },
> + [ C(OP_PREFETCH) ] = {
> + [ C(RESULT_ACCESS) ] = 0x0,
> + [ C(RESULT_MISS) ] = 0x0,
> + },
> + },
> +};

Now the other tables create little helpers like:

#define HSW_DMND_READ (HSW_DMND_DATA_RD)
#define HSW_DMND_WRITE (HSW_DMND_RFO)

#define HSW_L3_ACCESS (HSW_ANY_RESPONSE)
#define HSW_L3_MISS (HSW_L3_MISS)

And compose the tables values using those:

HSW_DMND_READ|HSW_L3_ACCESS

Please do so here too.

Now; when comparing these value to the SNB for example I note that you
include ANY_SNOOP and SUPPLIER_NONE in L3_ACCESS, SNB and other do not,
please explain.


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