From: Jiri Olsa <jolsa@redhat.com>
To: Namhyung Kim <namhyung@kernel.org>
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: Thu, 14 Aug 2014 16:10:57 +0200 [thread overview]
Message-ID: <20140814141056.GA7630@krava.brq.redhat.com> (raw)
In-Reply-To: <1407996100-6359-4-git-send-email-namhyung@kernel.org>
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
jirka
next prev parent reply other threads:[~2014-08-14 14:11 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 [this message]
2014-08-15 1:57 ` Namhyung Kim
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=20140814141056.GA7630@krava.brq.redhat.com \
--to=jolsa@redhat.com \
--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=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung.kim@lge.com \
--cc=namhyung@kernel.org \
--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.