All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@kernel.org>, Paul Mackerras <paulus@samba.org>,
	Namhyung Kim <namhyung.kim@lge.com>,
	LKML <linux-kernel@vger.kernel.org>,
	David Ahern <dsahern@gmail.com>, Andi Kleen <andi@firstfloor.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Arun Sharma <asharma@fb.com>,
	Rodrigo Campos <rodrigo@sdfg.com.ar>
Subject: Re: [PATCH 3/3] perf callchain: Prune misleading callchains for self entries
Date: Sat, 16 Aug 2014 11:26:31 +0900	[thread overview]
Message-ID: <1408155991.1672.4.camel@leonhard> (raw)
In-Reply-To: <20140815195139.GA13425@krava.brq.redhat.com>

2014-08-15 (금), 21:51 +0200, Jiri Olsa:
> On Fri, Aug 15, 2014 at 10:57:14AM +0900, Namhyung Kim wrote:
> > Hi Jiri,
> > 
> > 2014-08-14 (목), 16:10 +0200, Jiri Olsa:
> > > On Thu, Aug 14, 2014 at 03:01:40PM +0900, Namhyung Kim wrote:
> > > 
> > > SNIP
> > > 
> > > > However, with --children feature added, it now can show all callees of
> > > > the entry.  For example, "start_kernel" entry now can display it calls
> > > > rest_init and in turn cpu_idle and then cpuidle_idle_call (95.72%).
> > > > 
> > > >      6.14%     0.00%  swapper          [kernel.kallsyms]   [k] start_kernel
> > > >                    |
> > > >                     --- start_kernel
> > > >                         rest_init
> > > >                         cpu_idle
> > > >                        |
> > > >                        |--97.52%-- cpuidle_idle_call
> > > >                        |          cpuidle_enter_tk
> > > >                        |          |
> > > >                        |          |--99.91%-- cpuidle_wrap_enter
> > > >                        |          |          cpuidle_enter
> > > >                        |          |          intel_idle
> > > >                        |           --0.09%-- [...]
> > > >                         --2.48%-- [...]
> > > > 
> > > > Note that start_kernel has no self overhead - meaning that it never
> > > > get sampled by itself but constructs such a nice callgraph.  But,
> > > > sadly, if an entry has self overhead, callchain will get confused with
> > > > generated callchain (like above) and self callchains (which reversed
> > > > order) like the eariler example.
> > > > 
> > > > To be consistent with other entries, I'd like to make it just to show
> > > > a single entry - itself - like below since it doesn't have callees
> > > > (children) at all.  But still use the whole callchain to construct
> > > > children entries (like the start_kernel) as usual.
> > > > 
> > > >     40.53%    40.53%  swapper          [kernel.kallsyms]   [k] intel_idle
> > > >                     |
> > > >                     --- intel_idle
> > > 
> > > I understand the consistency point, but I think we'd loose
> > > usefull info by cutting this off
> > > 
> > > I guess I can run 'report -g callee' to find out who called intel_idle
> > > instead.. but I would not need to if the callchain stays here
> > 
> > Yeah, but current behavior intermixes caller-callchains and
> > callee-callchains together so adds confusion to users.  This is a
> > problem IMHO.
> 
> hum, where is it callee/caller mixed?  with following example:
> 
> ---
> void c(void)
> {
> }
> 
> void b(void)
> {
>         c();
> }
> 
> void a(void)
> {
>         b();
> }
> 
> int main(void)
> {
>         while(1) {
>                 a();
>                 b();
>                 c();
>         }
> }
> ---
> 
> for 'c' the current code will display:
> 
> -   43.74%    43.74%  t        t                 [.] c                                                                                    ▒
>    - __libc_start_main                                                                                                                    ▒
>       - 86.33% main                                                                                                                       ▒
>            67.08% c                                                                                                                       ▒
>          - 32.91% a                                                                                                                       ▒
>               99.44% c                                                                                                                    ▒
>             - 0.56% b                                                                                                                     ▒
>                  c                                                                                                                        ▒
>         13.67% c                                                                                                                          ▒
> 
> and with this patch:
> 
> -   43.74%    43.74%  t        t                 [.] c                                                                                    ▒
>      c                                                                                                                                    ▒
> 
> 
> The 'c' callchain is still in caller order. IMO we should
> keep whole callchain here.

The problem is not in pure self entry (that has self overhead = children
overhead) and pure cumulative entry (self overhead = 0).  It's in mixed
entries, please see last two examples in the description 0/3.

Thanks,
Namhyung



  reply	other threads:[~2014-08-16  2:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-14  6:01 [RFC/PATCHSET 0/3] perf tools: Callchain improvement with --children and -g caller Namhyung Kim
2014-08-14  6:01 ` [PATCH 1/3] perf report: Relax -g option parsing not to limit the option order Namhyung Kim
2014-08-18  8:22   ` [tip:perf/core] " tip-bot for Namhyung Kim
2014-08-14  6:01 ` [PATCH 2/3] perf tools: Put callers above callee when callchain order is caller Namhyung Kim
2014-08-14  6:01 ` [PATCH 3/3] perf callchain: Prune misleading callchains for self entries Namhyung Kim
2014-08-14 14:10   ` Jiri Olsa
2014-08-15  1:57     ` Namhyung Kim
2014-08-15 19:51       ` Jiri Olsa
2014-08-16  2:26         ` Namhyung Kim [this message]
2014-08-18 11:31           ` Jiri Olsa
2014-08-19  5:51             ` Namhyung Kim
2014-08-19  7:10               ` Jiri Olsa
2014-08-19  8:20                 ` Namhyung Kim
2014-08-15 13:52 ` [RFC/PATCHSET 0/3] perf tools: Callchain improvement with --children and -g caller Arnaldo Carvalho de Melo

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=1408155991.1672.4.camel@leonhard \
    --to=namhyung@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=andi@firstfloor.org \
    --cc=asharma@fb.com \
    --cc=dsahern@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung.kim@lge.com \
    --cc=paulus@samba.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.