[tip:perfcounters/core] perf tools: Unify swapper tasks naming

[tip-bot for Frederic Weisbecker]

Commit-ID:  9b8055a52c8986167e0a7357460d528a00db67e6
Gitweb:     http://git.kernel.org/tip/9b8055a52c8986167e0a7357460d528a00db67e6
Author:     Frederic Weisbecker <fweisbec@xxxxxxxxx>
AuthorDate: Mon, 31 Aug 2009 06:45:20 +0200
Committer:  Ingo Molnar <mingo@xxxxxxx>
CommitDate: Mon, 31 Aug 2009 10:04:49 +0200

perf tools: Unify swapper tasks naming

In perf tools, we hardcode the pid 0 cmdline resolving to
"idle" because the init task is not included in the COMM
events.

But the idle tasks secondary cpus are resolved into their
"init" name through the COMM events.

We have then such strange result in perf report (ditto with
trace):

    19.66%       init    [kernel]          [k] acpi_idle_enter_c1
    17.32%       [idle]  [kernel]          [k] acpi_idle_enter_c1

It's then better to unify the swapper tasks into a single init
name.

Signed-off-by: Frederic Weisbecker <fweisbec@xxxxxxxxx>
Cc: Frederic Weisbecker <fweisbec@xxxxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
LKML-Reference: <1251693921-6579-3-git-send-email-fweisbec@xxxxxxxxx>
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>


---
 tools/perf/util/thread.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 3acd37f..7635928 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -85,7 +85,7 @@ register_idle_thread(struct rb_root *threads, struct thread **last_match)
 {
 	struct thread *thread = threads__findnew(0, threads, last_match);
 
-	if (!thread || thread__set_comm(thread, "[idle]")) {
+	if (!thread || thread__set_comm(thread, "[init]")) {
 		fprintf(stderr, "problem inserting idle task.\n");
 		exit(-1);
 	}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/