[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1461771888-10409-1-git-send-email-alexander.shishkin@linux.intel.com>
Date: Wed, 27 Apr 2016 18:44:41 +0300
From: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
linux-kernel@...r.kernel.org, vince@...ter.net, eranian@...gle.com,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Subject: [PATCH v2 0/7] perf: Introduce address range filtering
Hi Peter,
Here's my third round of address range filtering support for perf.
Changes since v1 [1]:
* got rid of the race filter syncing cross-call if favor of a restart
sequence and
* moved all filter synchronization to pmu::start()
* simplified some paths and structures as a result
* added some more comments
* dropped "file"/"kernel" specifier from filter format
* added a pmu attribute for those pmus that support address filtering
* moved all PT MSR bit definitions to pt.h.
Changes since v0 [2], notably
* split the pmu callback in two as we discussed,
* split the filter itself into 'core' and 'hw' parts,
* made only parent events eligible for configuring filters (children
can still have their 'hw' portions),
* and basically re-wrote the whole thing around that.
Newer version of Intel PT supports address-based filtering, and this
patchset adds support for it to perf core and the PT pmu driver. It
works by configuring a number of address ranges in hardware and
telling it to use these ranges to filter its traces. Similar feature
also exists in ARM Coresight ETM/PTM and it is also taken into account
in this patchset.
Firstly, userspace configures filters via an ioctl(), filters are
formatted as an ascii string. Filters may refer to addresses in object
files for userspace code or kernel addresses. The latter might be
extended in the future to support kernel modules.
For userspace filters, we scan the task's vmas to see if any of them
match the defined filters (inode+offset) and if they do, calculate
memory offsets and program them into hardware. Note that since
different tasks will have different mappings for the same object
files, supporting cpu-wide events would require special tricks to
context-switch filters for userspace code.
Also, we monitor new mmap and exec events to update (or clear) filter
configuration.
[1] http://marc.info/?l=linux-kernel&m=146125264018801
[2] http://marc.info/?l=linux-kernel&m=144984116019143
Alexander Shishkin (7):
perf: Move set_filter() from behind EVENT_TRACING
perf/x86/intel/pt: Move MSR bit definitions to a private header
perf/x86/intel/pt: IP filtering register/cpuid bits
perf: Extend perf_event_aux_ctx() to optionally iterate through more
events
perf: Introduce address range filtering
perf/x86/intel/pt: Add support for address range filtering in PT
perf: Let userspace know if pmu supports address filters
arch/x86/events/intel/pt.c | 181 +++++++++-
arch/x86/events/intel/pt.h | 62 ++++
arch/x86/include/asm/msr-index.h | 29 +-
include/linux/perf_event.h | 98 ++++++
kernel/events/core.c | 713 ++++++++++++++++++++++++++++++++++++---
5 files changed, 1005 insertions(+), 78 deletions(-)
--
2.8.0.rc3
Powered by blists - more mailing lists