[PATCH v2] drivers/perf: Enable PID_IN_CONTEXTIDR with SPE

Mark Rutland mark.rutland at arm.com
Wed Jan 6 05:24:10 EST 2021


On Mon, Dec 14, 2020 at 10:45:02AM +0200, James Clark wrote:
> Enable PID_IN_CONTEXTIDR by default when Arm SPE is enabled.
> This flag is required to get PID data in the SPE trace. Without
> it the perf tool will report 0 for PID which isn't very useful,
> especially when doing system wide profiling or profiling
> applications that fork.
> 
> There is a small performance overhead when enabling
> PID_IN_CONTEXTIDR, but SPE itself is optional and not enabled by
> default so the impact is minimised.
> 
> Cc: Will Deacon <will at kernel.org>
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Al Grant <al.grant at arm.com>
> Cc: Leo Yan <leo.yan at linaro.org>
> Cc: John Garry <john.garry at huawei.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: James Clark <james.clark at arm.com>
> ---
>  arch/arm64/Kconfig.debug | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index 265c4461031f..b030bb21a0bb 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -2,6 +2,7 @@
>  
>  config PID_IN_CONTEXTIDR
>  	bool "Write the current PID to the CONTEXTIDR register"
> +	default y if ARM_SPE_PMU
>  	help
>  	  Enabling this option causes the kernel to write the current PID to
>  	  the CONTEXTIDR register, at the expense of some additional

Given that PID_IN_CONTEXTIDR doesn't take PID namespacing into account,
IIUC it's kinda broken today (and arguably removing that support would
be better).

Can we not track the (namespaced) PID in thte main ringbuffer regardless
of PID_IN_CONTEXTIDR, and leave PID_IN_CONTEXTIDR as an external debug
aid only?

Making this default y is ARM_SPE_PMU implies it'll be on in all distro
kernels, and I think we need to think harder before doing that.

Thanks,
Mark.



More information about the linux-arm-kernel mailing list