From: Peter Zijlstra <peterz@infradead.org>
To: "Liang, Kan" <kan.liang@intel.com>
Cc: "eranian@google.com" <eranian@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"paulus@samba.org" <paulus@samba.org>,
"acme@kernel.org" <acme@kernel.org>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"Yan, Zheng" <zheng.z.yan@intel.com>
Subject: Re: [PATCH V5 11/16] perf, core: Pass perf_sample_data to perf_callchain()
Date: Tue, 7 Oct 2014 17:24:12 +0200 [thread overview]
Message-ID: <20141007152412.GC5850@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F0770160F98C@SHSMSX103.ccr.corp.intel.com>
I think you're going to have to stop using outlook or whatnot, this is
horrible.
On Tue, Oct 07, 2014 at 03:00:00AM +0000, Liang, Kan wrote:
> > -----Original Message-----
> > From: Peter Zijlstra [mailto:peterz@infradead.org]
> > So I don't like this. Why not use the regular PERF_SAMPLE_BRANCH_STACK
> > output to generate the stuff from? We already have two different means,
> > with different transport, for callchains anyhow, so a third really won't matter.
>
> I'm not sure what you mean by using the regular
> PERF_SAMPLE_BRANCH_STACK output to generate the stuff from. But we
> don't need to modify various architectures' perf_callchain_user, if
> that's your concern. An alternative way is to generate the callchain
> output in a higher level, like perf_callchain. If there is no frame
> pointer, the entry->nr will be set to MAX+1. So the perf_callchain
> knows that we need to try LBR callstack if possible. In
> perf_callchain, it resets entry->nr to old value, and call
> perf_callchain_lbr_callstack to check and fill the callchain struct if
> possible. The patch is as below.
Please instruct your MUA to wrap at 78 chars.
What I meant was: why can't we use the regular PERF_SAMPLE_BRANCH_STACK
output to generate user traces from?
PERF_SAMPLE_BRANCH_STACK is the 'normal' LBR output format. Clobbering
the callstack output is bad.
> What do you think?
I think it still sucks.. you're still clobbering potentially more useful
data.
next prev parent reply other threads:[~2014-10-07 15:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 14:08 [PATCH V5 00/16] perf, x86: Haswell LBR call stack support kan.liang
2014-09-10 14:08 ` [PATCH V5 01/16] perf, x86: Reduce lbr_sel_map size kan.liang
2014-09-24 10:50 ` Peter Zijlstra
2014-09-10 14:08 ` [PATCH V5 02/16] perf, core: introduce pmu context switch callback kan.liang
2014-09-24 11:23 ` Peter Zijlstra
2014-09-24 13:13 ` Peter Zijlstra
2014-09-10 14:09 ` [PATCH V5 03/16] perf, x86: use context switch callback to flush LBR stack kan.liang
2014-09-10 14:09 ` [PATCH V5 04/16] perf, x86: Basic Haswell LBR call stack support kan.liang
2014-09-10 14:09 ` [PATCH V5 05/16] perf, core: pmu specific data for perf task context kan.liang
2014-09-10 14:09 ` [PATCH V5 06/16] perf, core: always switch pmu specific data during context switch kan.liang
2014-09-10 14:09 ` [PATCH V5 07/16] perf, x86: allocate space for storing LBR stack kan.liang
2014-09-10 14:09 ` [PATCH V5 08/16] perf, x86: track number of events that use LBR callstack kan.liang
2014-09-24 12:53 ` Peter Zijlstra
2014-10-07 2:59 ` Liang, Kan
2014-10-07 15:19 ` Peter Zijlstra
2014-09-10 14:09 ` [PATCH V5 09/16] perf, x86: Save/resotre LBR stack during context switch kan.liang
2014-09-24 13:33 ` Peter Zijlstra
2014-09-10 14:09 ` [PATCH V5 10/16] perf, core: simplify need branch stack check kan.liang
2014-09-24 13:55 ` Peter Zijlstra
2014-09-10 14:09 ` [PATCH V5 11/16] perf, core: Pass perf_sample_data to perf_callchain() kan.liang
2014-09-24 14:15 ` Peter Zijlstra
2014-10-07 3:00 ` Liang, Kan
2014-10-07 15:24 ` Peter Zijlstra [this message]
2014-10-07 15:50 ` Liang, Kan
2014-10-07 16:29 ` Peter Zijlstra
2014-09-10 14:09 ` [PATCH V5 12/16] perf, x86: use LBR call stack to get user callchain kan.liang
2014-09-10 14:09 ` [PATCH V5 13/16] perf, x86: re-organize code that implicitly enables LBR/PEBS kan.liang
2014-09-10 14:09 ` [PATCH V5 14/16] perf, x86: enable LBR callstack when recording callchain kan.liang
2014-09-24 14:21 ` Peter Zijlstra
2014-10-07 3:00 ` Liang, Kan
2014-10-07 15:25 ` Peter Zijlstra
2014-10-07 16:04 ` Liang, Kan
2014-09-10 14:09 ` [PATCH V5 15/16] perf, x86: disable FREEZE_LBRS_ON_PMI when LBR operates in callstack mode kan.liang
2014-09-10 14:09 ` [PATCH V5 16/16] perf, x86: Discard zero length call entries in LBR call stack kan.liang
-- strict thread matches above, loose matches on Subject: below --
2014-07-07 6:28 [PATCH v5 00/16] perf, x86: Haswell LBR call stack support Yan, Zheng
2014-07-07 6:28 ` [PATCH v5 11/16] perf, core: Pass perf_sample_data to perf_callchain() Yan, Zheng
2001-01-08 2:31 [PATCH V5 10/16] perf, core: simplify need branch stack check kan.liang
2001-01-08 2:31 ` [PATCH V5 11/16] perf, core: Pass perf_sample_data to perf_callchain() kan.liang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141007152412.GC5850@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=zheng.z.yan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.