Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1489957 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [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

Page 2 of 2 — ← Prev page 1 [2]

#1490342

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.

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.

-Andi

[toc] | [prev] | [next] | [standalone]

#1490440

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?
Expand on the down-sides of that.

> 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 ?


This really isn't rocket science, patches should come with
justification, try and sell this stuff. Don't try and skimp on that.

[toc] | [prev] | [next] | [standalone]

#1490493

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web