[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1453909257-26015-7-git-send-email-namhyung@kernel.org>
Date: Thu, 28 Jan 2016 00:40:53 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Jiri Olsa <jolsa@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Andi Kleen <andi@...stfloor.org>,
David Ahern <dsahern@...il.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Wang Nan <wangnan0@...wei.com>
Subject: [PATCH 06/10] perf report: Fix percent display in callchains on --stdio
When there's only a single callchain, perf doesn't print its percentage
in front of the symbols. This is because it assumes that the percentage
is same as parents. But if a percent limit is applied, it's possible
that there are actually a couple of child nodes but only one of them is
shown. In this case it should display the percent to prevent
misunderstanding of its percentage is same as the parent's.
For example, let's see the following callchain.
$ perf report -s comm --percent-limit 0.01 --stdio
...
9.95% swapper
|
|--7.57%--intel_idle
| cpuidle_enter_state
| cpuidle_enter
| call_cpuidle
| cpu_startup_entry
| |
| |--4.89%--start_secondary
| |
| --2.68%--rest_init
| start_kernel
| x86_64_start_reservations
| x86_64_start_kernel
|
|--0.15%--__schedule
| |
| |--0.13%--schedule
| | schedule_preempt_disable
| | cpu_startup_entry
| | |
| | |--0.09%--start_secondary
| | |
| | --0.04%--rest_init
| | start_kernel
| | x86_64_start_reservations
| | x86_64_start_kernel
| |
| --0.01%--schedule_preempt_disabled
| cpu_startup_entry
...
Current code omits the percent if 'intel_idle' becomes the only node
when percent limit is set to 0.5%, its percent is not 9.95% but users
will assume it incorrectly.
Before:
$ perf report --percent-limit 0.5 --stdio
...
9.95% swapper
|
---intel_idle
cpuidle_enter_state
cpuidle_enter
call_cpuidle
cpu_startup_entry
|
|--4.89%--start_secondary
|
--2.68%--rest_init
start_kernel
x86_64_start_reservations
x86_64_start_kernel
After:
$ perf report --percent-limit 0.5 --stdio
...
9.95% swapper
|
--7.57%--intel_idle
cpuidle_enter_state
cpuidle_enter
call_cpuidle
cpu_startup_entry
|
|--4.89%--start_secondary
|
--2.68%--rest_init
start_kernel
x86_64_start_reservations
x86_64_start_kernel
Signed-off-by: Namhyung Kim <namhyung@...nel.org>
---
tools/perf/ui/stdio/hist.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 96188ea12771..76ff46becac8 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -165,6 +165,25 @@ static size_t __callchain__fprintf_graph(FILE *fp, struct rb_root *root,
return ret;
}
+/*
+ * If have one single callchain root, don't bother printing
+ * its percentage (100 % in fractal mode and the same percentage
+ * than the hist in graph mode). This also avoid one level of column.
+ *
+ * However when percent-limit applied, it's possible that single callchain
+ * node have different (non-100% in fractal mode) percentage.
+ */
+static bool need_percent_display(struct rb_node *node, u64 parent_samples)
+{
+ struct callchain_node *cnode;
+
+ if (rb_next(node))
+ return true;
+
+ cnode = rb_entry(node, struct callchain_node, rb_node);
+ return callchain_cumul_hits(cnode) != parent_samples;
+}
+
static size_t callchain__fprintf_graph(FILE *fp, struct rb_root *root,
u64 total_samples, u64 parent_samples,
int left_margin)
@@ -178,13 +197,8 @@ static size_t callchain__fprintf_graph(FILE *fp, struct rb_root *root,
int ret = 0;
char bf[1024];
- /*
- * If have one single callchain root, don't bother printing
- * its percentage (100 % in fractal mode and the same percentage
- * than the hist in graph mode). This also avoid one level of column.
- */
node = rb_first(root);
- if (node && !rb_next(node)) {
+ if (node && !need_percent_display(node, parent_samples)) {
cnode = rb_entry(node, struct callchain_node, rb_node);
list_for_each_entry(chain, &cnode->val, list) {
/*
--
2.6.4
Powered by blists - more mailing lists