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

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: <20141105124926.GS3337@twins.programming.kicks-ass.net>
Date:	Wed, 5 Nov 2014 13:49:26 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Kan Liang <kan.liang@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>
Subject: Re: [PATCH V7 13/17] perf, x86: enable LBR callstack when recording
 callchain

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/