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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160923203527.GR5008@twins.programming.kicks-ass.net>
Date:   Fri, 23 Sep 2016 22:35:27 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Andi Kleen <ak@...ux.intel.com>
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 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.