[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190528150320.25953-1-raphael.gault@arm.com>
Date: Tue, 28 May 2019 16:03:13 +0100
From: Raphael Gault <raphael.gault@....com>
To: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc: mingo@...hat.com, peterz@...radead.org, catalin.marinas@....com,
will.deacon@....com, acme@...nel.org, mark.rutland@....com,
Raphael Gault <raphael.gault@....com>
Subject: [RFC V2 0/7] arm64: Enable access to pmu registers by user-space
The perf user-space tool relies on the PMU to monitor events. It offers an
abstraction layer over the hardware counters since the underlying
implementation is cpu-dependent. We want to allow userspace tools to have
access to the registers storing the hardware counters' values directly.
This targets specifically self-monitoring tasks in order to reduce the
overhead by directly accessing the registers without having to go
through the kernel.
In order to do this we need to setup the pmu so that it exposes its registers
to userspace access.
The first patch enables the tests for arm64 architecture in the perf
tool to be compiled systematically.
The second patch add a test to the perf tool so that we can test that the
access to the registers works correctly from userspace.
The third patch adds another test similar to the first one but this time
using rseq as mechanism to make sure of the data correctness.
The fourth patch focuses on the armv8 pmuv3 PMU support and makes sure that
the access to the pmu registers is enable and that the userspace have
access to the relevent information in order to use them.
The fifth patch adds a hook to handle faulting access to the pmu
registers. This is necessary in order to have a coherent behaviour
on big.LITTLE environment.
The sixth patch put in place callbacks to enable access to the hardware
counters from userspace when a compatible event is opened using the perf
API.
RFC: In my opinion there is no need to save pmselr_el0 when context
switching like we do for pmuserenr_el0 since whether it's the seqlock
mechanism or the restartable sequences, the user should notice right
away that the value held in pmxevcntr_el0 is incorrect when the task has
been rescheduled. However, I still wanted to discuss this point on the
list to see if that's indeed not necessary to save it.
Changes since V1: Add a test using rseq
Raphael Gault (7):
perf: arm64: Compile tests unconditionally
perf: arm64: Add test to check userspace access to hardware counters.
perf: arm64: Use rseq to test userspace access to pmu counters
arm64: pmu: Add function implementation to update event index in
userpage.
arm64: pmu: Add hook to handle pmu-related undefined instructions
arm64: perf: Enable pmu counter direct access for perf event on armv8
Documentation: arm64: Document PMU counters access from userspace
.../arm64/pmu_counter_user_access.txt | 42 +++
arch/arm64/include/asm/mmu.h | 6 +
arch/arm64/include/asm/mmu_context.h | 2 +
arch/arm64/include/asm/perf_event.h | 14 +
arch/arm64/kernel/cpufeature.c | 4 +-
arch/arm64/kernel/perf_event.c | 62 +++++
drivers/perf/arm_pmu.c | 38 +++
include/linux/perf/arm_pmu.h | 2 +
tools/perf/arch/arm64/Build | 2 +-
tools/perf/arch/arm64/include/arch-tests.h | 9 +
tools/perf/arch/arm64/include/rseq-arm64.h | 220 +++++++++++++++
tools/perf/arch/arm64/tests/Build | 4 +-
tools/perf/arch/arm64/tests/arch-tests.c | 10 +
tools/perf/arch/arm64/tests/rseq-pmu-events.c | 219 +++++++++++++++
tools/perf/arch/arm64/tests/user-events.c | 255 ++++++++++++++++++
15 files changed, 885 insertions(+), 4 deletions(-)
create mode 100644 Documentation/arm64/pmu_counter_user_access.txt
create mode 100644 tools/perf/arch/arm64/include/rseq-arm64.h
create mode 100644 tools/perf/arch/arm64/tests/rseq-pmu-events.c
create mode 100644 tools/perf/arch/arm64/tests/user-events.c
--
2.17.1
Powered by blists - more mailing lists