public inbox for linux-kernel@vger.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: Fri, 15 Aug 2014 10:57:14 +0900	[thread overview]
Message-ID: <1408067834.1679.15.camel@leonhard> (raw)
In-Reply-To: <20140814141056.GA7630@krava.brq.redhat.com>

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.

And with --children you can easily see the callers right above the entry
as they likely to have same or higher children overhead.

Thanks,
Namhyung



  reply	other threads:[~2014-08-15  1:57 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 [this message]
2014-08-15 19:51       ` Jiri Olsa
2014-08-16  2:26         ` Namhyung Kim
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=1408067834.1679.15.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox