public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, jolsa@redhat.com,
	adrian.hunter@intel.com, mathieu.poirier@linaro.org,
	mark.rutland@arm.com,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>
Subject: [PATCH v2 0/4] perf: Add AUX data sampling
Date: Tue, 22 Oct 2019 12:58:08 +0300	[thread overview]
Message-ID: <20191022095812.67071-1-alexander.shishkin@linux.intel.com> (raw)

Hi Peter,

Here's a new version of the AUX sampling. Since the previous one [3],
it addresses the issues of NMI-safety and sampling hardware events.
The former is addressed by adding a new PMU callback, the latter by
making use of grouping. It also depends on the AUX output stop fix
[4] to work correctly. I decided to post them separately, because [4]
is also a candidate for perf/urgent.

This series introduces AUX data sampling for perf events, which in
case of our instruction/branch tracing PMUs like Intel PT, BTS, CS
ETM means execution flow history leading up to a perf event's
overflow.

In case of Intel PT, this can be used as an alternative to LBR, with
virtually as many as you like branches per sample. It doesn't support
some of the LBR features (branch prediction indication, basic block
level timing, etc [1]) and it can't be exposed as BRANCH_STACK, because
that would require decoding PT stream in kernel space, which is not
practical. Instead, we deliver the PT data to userspace as is, for
offline processing. The PT decoder already supports presenting PT as
virtual LBR.

AUX sampling is different from the snapshot mode in that it doesn't
require instrumentation (for when to take a snapshot) and is better
for generic data collection, when you don't yet know what you are
looking for. It's also useful for automated data collection, for
example, for feedback-driven compiler optimizaitions.

It's also different from the "full trace mode" in that it produces
much less data and, consequently, takes up less I/O bandwidth and
storage space, and takes less time to decode.

The bulk of code is in 1/4, which adds the user interface bits and
the code to measure and copy out AUX data. 3/4 adds PT side support
for sampling. 4/4 is not strictly related, but makes an improvement
to the PT's snapshot mode by implementing a simpler buffer management
that would also benefit the sampling.

The tooling support is ready, although I'm not including it here to
save the bandwidth. Adrian or I will post itseparately. Meanwhile,
it can be found here [2].

[1] https://marc.info/?l=linux-kernel&m=147467007714928&w=2
[2] https://git.kernel.org/cgit/linux/kernel/git/ash/linux.git/log/?h=perf-aux-sampling
[3] https://marc.info/?l=linux-kernel&m=152878999928771
[4] https://marc.info/?l=linux-kernel&m=157172999231707

Alexander Shishkin (4):
  perf: Allow using AUX data in perf samples
  perf/x86/intel/pt: Factor out starting the trace
  perf/x86/intel/pt: Add sampling support
  perf/x86/intel/pt: Opportunistically use single range output mode

 arch/x86/events/intel/pt.c      | 192 ++++++++++++++++++++++++++------
 arch/x86/events/intel/pt.h      |   2 +
 include/linux/perf_event.h      |  20 ++++
 include/uapi/linux/perf_event.h |   7 +-
 kernel/events/core.c            | 159 +++++++++++++++++++++++++-
 kernel/events/internal.h        |   1 +
 kernel/events/ring_buffer.c     |  36 ++++++
 7 files changed, 380 insertions(+), 37 deletions(-)

-- 
2.23.0


             reply	other threads:[~2019-10-22  9:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-22  9:58 Alexander Shishkin [this message]
2019-10-22  9:58 ` [PATCH v2 1/4] perf: Allow using AUX data in perf samples Alexander Shishkin
2019-10-24 13:52   ` Peter Zijlstra
2019-10-24 14:01   ` Peter Zijlstra
2019-10-25 12:52     ` Alexander Shishkin
2019-10-24 14:06   ` Peter Zijlstra
2019-10-25 12:21     ` Alexander Shishkin
2019-10-24 14:09   ` Peter Zijlstra
2019-10-24 14:12   ` Peter Zijlstra
2019-10-22  9:58 ` [PATCH v2 2/4] perf/x86/intel/pt: Factor out starting the trace Alexander Shishkin
2019-10-22  9:58 ` [PATCH v2 3/4] perf/x86/intel/pt: Add sampling support Alexander Shishkin
2019-10-22  9:58 ` [PATCH v2 4/4] perf/x86/intel/pt: Opportunistically use single range output mode Alexander Shishkin
2019-10-23 15:09   ` Alexander Shishkin
2019-10-24 13:56   ` Peter Zijlstra
2019-10-25 12:19     ` Alexander Shishkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191022095812.67071-1-alexander.shishkin@linux.intel.com \
    --to=alexander.shishkin@linux.intel.com \
    --cc=acme@redhat.com \
    --cc=adrian.hunter@intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox