All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Arun Sharma <asharma@fb.com>
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: Tue, 29 Oct 2013 14:25:42 +0900	[thread overview]
Message-ID: <87d2mo7ind.fsf@sejong.aot.lge.com> (raw)
In-Reply-To: <526F353E.8040607@fb.com> (Arun Sharma's message of "Mon, 28 Oct 2013 21:10:38 -0700")

On Mon, 28 Oct 2013 21:10:38 -0700, Arun Sharma wrote:
> 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).

That's also fine by me.  But I added --cumulate since it's quite
different from other callchain behaviors.

If we go with -g option, I'd like add it as a new type.

>
>>> 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.

Yeah, looking at the code, I can hardly find how I can do it. :-/

Thanks,
Namhyung

  reply	other threads:[~2013-10-29  5:25 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
2013-10-29  5:25               ` Namhyung Kim [this message]
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=87d2mo7ind.fsf@sejong.aot.lge.com \
    --to=namhyung@kernel.org \
    --cc=acme@ghostprotocols.net \
    --cc=asharma@fb.com \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung.kim@lge.com \
    --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.