Re: [RFC PATCH 0/6] perf: Add AUX data sampling

From	Andi Kleen <ak@linux.intel.com>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH 0/6] perf: Add AUX data sampling
Date	2016-09-24 00:40 +0200
Message-ID	<skHiq-1h5-9@gated-at.bofh.it> (permalink)
References	<skwQ1-2Yn-11@gated-at.bofh.it> <skx9o-35a-9@gated-at.bofh.it> <skCiJ-6I7-15@gated-at.bofh.it> <skFqi-6t-9@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Fri, Sep 23, 2016 at 10:35:27PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 23, 2016 at 10:19:43AM -0700, Andi Kleen wrote:
> > On Fri, Sep 23, 2016 at 01:49:17PM +0200, Peter Zijlstra wrote:
> > > On Fri, Sep 23, 2016 at 02:27:20PM +0300, Alexander Shishkin wrote:
> > > > Hi Peter,
> > > > 
> > > > This is an RFC, I'm not sending the tooling bits in this series,
> > > > although they can be found here [1].
> > > > 
> > > > 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.
> > > 
> > > This fails to explain _WHY_ this is a good thing to have. What kind of
> > > analysis does this enable, and is that fully implemented in [1] (I
> > > didn't look).
> > 
> > Think of it as a super LBR. (Near) all things LBR can do, PT can do
> > with much more branches for each sample.
> 
> Clarify the 'near'? Should we then not expose it as a BRANCH_STACK?

- Exposing it as branch stack would need a PT decoder in kernel space.
A PT decoder is quite complicated and needs a lot of infrastructure.
- Putting a PT decoder in kernel space is bad because the decoder is
much slower than the execution and much better runs offline than online.
It would cause a lot more data loss.
- LBR has some features which are not in PT (but also other way round),
like mispredict indication, call stack mode or individual basic block level
timing. It also has practically no runtime overhead.
- Also BTW the pt decoder in user space already supporting exposing
PT as a virtual LBR. It is just done all without kernel help
after decoding.

> > Also long term execution recording of PT normally doesn't work well because the
> > sustained bandwidth is too high for perf and the disk to keep up
> > 
> > Currently the main solution we have for that is the snapshot mode, but it
> > requires explicit instrumentation for someone to trigger snapshots.
> > 
> > Sampling PT is an alternative that works for many use cases, and does
> > not rely on instrumentation.
> 
> List a few use-cases on either side of that divide ?

- Snapshot mode is good for targeted performance debugging. You're looking
for something specific and can instrument for it.
- Sample mode is good for generic data collection. You don't know yet 
what you're looking for, but want to see hot paths in your application.
- Sample mode also works for automated data collection, like using
it for compiler profile feedback.

-Andi

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[RFC PATCH 0/6] perf: Add AUX data sampling Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-23 13:30 +0200
  [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-23 13:30 +0200
    Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer  allocation Peter Zijlstra <peterz@infradead.org> - 2016-09-23 14:20 +0200
      Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-23 16:40 +0200
        Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer  allocation Peter Zijlstra <peterz@infradead.org> - 2016-09-23 17:30 +0200
          Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-23 18:00 +0200
      Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer  allocation Andi Kleen <ak@linux.intel.com> - 2016-09-23 19:30 +0200
        Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer  allocation Peter Zijlstra <peterz@infradead.org> - 2016-09-23 22:30 +0200
          Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-26 10:30 +0200
            Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer  allocation Peter Zijlstra <peterz@infradead.org> - 2016-09-26 11:10 +0200
              Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-26 14:50 +0200
              Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-26 18:20 +0200
  [RFC PATCH 2/6] perf: Add api to (de-)allocate AUX buffers for kernel counters Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-23 13:40 +0200
  [RFC PATCH 3/6] perf: Add a helper for looking up pmus by type Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-23 13:40 +0200
  [RFC PATCH 4/6] perf: Add infrastructure for using AUX data in perf samples Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-23 13:40 +0200
  [RFC PATCH 5/6] perf: Disable PMU around address filter adjustment Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-23 13:40 +0200
  [RFC PATCH 6/6] perf: Disable IRQs in address filter sync path Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-23 13:40 +0200
    Re: [RFC PATCH 6/6] perf: Disable IRQs in address filter sync path Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-26 18:30 +0200
      Re: [RFC PATCH 6/6] perf: Disable IRQs in address filter sync path Mathieu Poirier <mathieu.poirier@linaro.org> - 2016-10-04 18:50 +0200
  Re: [RFC PATCH 0/6] perf: Add AUX data sampling Peter Zijlstra <peterz@infradead.org> - 2016-09-23 13:50 +0200
    Re: [RFC PATCH 0/6] perf: Add AUX data sampling Andi Kleen <ak@linux.intel.com> - 2016-09-23 19:20 +0200
      Re: [RFC PATCH 0/6] perf: Add AUX data sampling Peter Zijlstra <peterz@infradead.org> - 2016-09-23 22:40 +0200
        Re: [RFC PATCH 0/6] perf: Add AUX data sampling Andi Kleen <ak@linux.intel.com> - 2016-09-24 00:40 +0200

csiph-web