[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160923171943.GT3078@tassilo.jf.intel.com>
Date: Fri, 23 Sep 2016 10:19:43 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
vince@...ter.net, eranian@...gle.com,
Arnaldo Carvalho de Melo <acme@...radead.org>,
tglx@...utronix.de
Subject: Re: [RFC PATCH 0/6] perf: Add AUX data sampling
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
Powered by blists - more mailing lists