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]
Date:	Wed, 4 Nov 2015 11:39:19 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	hw.claudio@...il.com
Cc:	Will Deacon <will.deacon@....com>,
	Claudio Fontana <claudio.fontana@...wei.com>,
	Ammar Saeed <ammar.saeed@...wei.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Marc Zyngier <marc.zyngier@....com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC] arm64: perf: associate LL with L2 cache accesses and
 refills

On Wed, Nov 04, 2015 at 12:24:13PM +0100, hw.claudio@...il.com wrote:
> From: Claudio Fontana <claudio.fontana@...wei.com>
> 
> Signed-off-by: Claudio Fontana <claudio.fontana@...wei.com>
> Cc: Ammar Saeed <ammar.saeed@...wei.com>
> ---
> 
> Hello,

Hi,
 
> as part of some experiments with the Juno ARM64 board, we needed to get
> readings from the PMU regarding L2 Cache hits and misses, but we noticed
> that the L2 Cache Access and Refill performance counters were not hooked
> up in the perf API. We just did that, and that seems to produce correct
> results on the Juno.
> 
> However I guess that these registers are not hooked up by default due to
> differences between different boards...how could this be done taking
> account of the different possible implementations? 

The events we list for PMUv3 are those which are required to be
implemented (see "D5.10.6 Required events" in ARM DDI 0487A.h). All
others (including the L2 events you add) are optional and may or may not
be implemented, so we can't expose them for all PMUv3 implementations.

To account for different events, we will shortly be exposing separate
logical PMUs (see [1]), which will allow us to support each CPU's set
of supported events independently. That's queued in the arm64 tree [2]
currently.

I see that per their respective TRMs, both Cortex-A53 and Cortex-A57
support these L2 events. It looks like when I added specialised support
[3,4] I simply missed them. Fancy sending a patch to correct that?

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374053.html
[2] https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/core
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374052.html
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374056.html

> I send this as an initial RFC to try to kickoff discussion about this.
> 
> Thank you,
> 
> Claudio Fontana
> 
>  arch/arm64/kernel/perf_event.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index f9a74d4..f72f2ff 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -728,6 +728,11 @@ static const unsigned armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
>  	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS,
>  	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL,
>  
> +	[C(LL)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L2_CACHE_ACCESS,
> +	[C(LL)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L2_CACHE_REFILL,
> +	[C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L2_CACHE_ACCESS,
> +	[C(LL)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L2_CACHE_REFILL,
> +
>  	[C(BPU)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED,
>  	[C(BPU)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED,
>  	[C(BPU)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED,
> -- 
> 1.8.5.3
> 
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ