From: Arun Sharma <asharma@fb.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Rodrigo Campos <rodrigo@sdfg.com.ar>, <namhyung.kim@lge.com>,
<linux-kernel@vger.kernel.org>, <acme@ghostprotocols.net>,
<fweisbec@gmail.com>, Stephane Eranian <eranian@google.com>
Subject: Re: State of "perf: Add a new sort order: SORT_INCLUSIVE"
Date: Mon, 28 Oct 2013 21:10:38 -0700 [thread overview]
Message-ID: <526F353E.8040607@fb.com> (raw)
In-Reply-To: <87mwls7ouf.fsf@sejong.aot.lge.com>
On 10/28/13 8:11 PM, Namhyung Kim wrote:
Hey Namhyung:
>>
>> Also, what's the reasoning for --cumulate not being an option under
>> perf record -g ..,<order>?
>
> Sorry, I cannot understand you. The 'perf record' just saves sample
> data (and callchains) from the ring-buffer. All the processing happens
> in 'perf report'. I can't see what you expect from the 'perf record
> --cumulate'. Am I missing something?
Yes - I meant to say perf report -g :)
> -g [type,min[,limit],order]
Specifically, along with callee, caller, we could have a third option.
Or we could have a new type (graph, fractal, cumulative).
>> Given that there are clear use cases in production involving complex
>> callgraphs, I'm for getting this support in first and then reconciling
>> the differences with perf record -b later.
>
> I think what Frederic said is that the code de-duplication of 'perf
> report' side. The branch stack and --cumulate are different - branch
> stack concentrates on the branch itself but --cumulate uses callchains
> to find parents and give some credit to them as side information.
Me too. I brought it up with Stephane at some point in the last year or
so and there wasn't an obvious way to de-duplicate because of these
differences.
-Arun
next prev parent reply other threads:[~2013-10-29 4:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 15:07 State of "perf: Add a new sort order: SORT_INCLUSIVE" Rodrigo Campos
2013-10-28 5:09 ` Namhyung Kim
2013-10-28 8:42 ` Rodrigo Campos
2013-10-28 9:09 ` Namhyung Kim
2013-10-28 9:29 ` Rodrigo Campos
2013-10-28 16:43 ` Arun Sharma
2013-10-29 3:11 ` Namhyung Kim
2013-10-29 4:10 ` Arun Sharma [this message]
2013-10-29 5:25 ` Namhyung Kim
2013-10-29 8:36 ` Frederic Weisbecker
2013-10-28 8:49 ` Frederic Weisbecker
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=526F353E.8040607@fb.com \
--to=asharma@fb.com \
--cc=acme@ghostprotocols.net \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung.kim@lge.com \
--cc=namhyung@kernel.org \
--cc=rodrigo@sdfg.com.ar \
/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.