Re: [PATCH V7 13/17] perf, x86: enable LBR callstack when recording callchain

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Nov 05, 2014 at 11:57:10AM +0100, Stephane Eranian wrote:
> Yes, but I wonder how would the tool sort this out if you have FP and LBR
> for each sample.

That's the tools 'problem'. It currently can already have FP and Dwarf
bits. And it does not need to request all of them.

> My understanding of the patch is that it does not change the user interface,
> it changes the way callchains are gathered by the kernel on HSW.

I was under the impression it did change, but that shows how well the
Changelog explained things I suppose :/

> Is there explicit mention in the API that CALLCHAIN is relying on FP?

Don't think so. Although I would much prefer if it uses a single method
per arch across both kernel and user space. For x86 that is FP (since
that's the only method available to the kernel).

> I think in general it would be better for tools to know which
> low-level mechanism is used to better interpret the results and
> especially be aware of the limitations of each mechanism.

Agreed.

> I think the patch is trying some auto-promotion of CALLCHAIN to FP
> based on the belief it is better in most cases.

We're all more familiar with FP, and it doesn't have the obvious problem
if only 16 entries. I've worked on quite a bit of software that had much
deeper callchains -- yay for recursive algorithms and/or C++.

With a bit of care FP can be 'perfect', although Andi likes to point out
that glibc isn't and often wrecks FP :-(

> It reminds me of the discussion about precise mode. Why not default to
> precise for all events that support it?

I've no idea where that discussion stranded.

> I would be okay if the patch was introducing the 3rd mode for callchains.

Right, I would prefer that (as should be clear by now), this would allow
running with two (or even all three) and compare results.