Fastboot: fix initcalls disposition in bootgraph.pl

PATCH Applied Frederic Weisbecker 3 participants 7 messages Oct 4, 2008 – Oct 6, 2008 2 messages not in the archive

Share & tools

Frederic Weisbecker

author

2008-10-04 19:36 UTC #0 lore raw

PATCH 1/1 Fastboot: fix initcalls disposition in bootgraph.pl

When bootgraph.pl parses a file, it gives one row
for each initcall's pid. But only few of them will
be displayed => the longest.
This patch corrects it by giving only a rows for pids which have initcalls that will be displayed.
You can see the result in attachment, before and after the patch.

Ingo, could you please revert the commit b4bc656397071b18c99e85d9181f076e44de8a99 which was a false solution to solve this problem. Thanks.

(I'm sorry if the patch doesn't look smart. I've
never touch a line in perl until now).

Signed-off-by Frederic Weisbecker <[email protected]>

---
 scripts/bootgraph.pl |   24 +++++++++++++-----------
 1 files changed, 13 insertions(+), 11 deletions(-)

scripts/bootgraph.pl +13 ~~-11~~

index 2243353..5e7316e 100644
@@ -37,13 +37,13 @@
 # 	dmesg | perl scripts/bootgraph.pl > output.svg
 #
 
-my @rows;
-my %start, %end, %row;
+my %start, %end;
 my $done = 0;
-my $rowcount = 0;
 my $maxtime = 0;
 my $firsttime = 100;
 my $count = 0;
+my %pids;
+
 while (<>) {
 	my $line = $_;
 	if ($line =~ /([0-9\.]+)\] calling  ([a-zA-Z0-9\_]+)\+/) {

@@ -54,14 +54,8 @@ while (<>) {
 				$firsttime = $1;
 			}
 		}
-		$row{$func} = 1;
 		if ($line =~ /\@ ([0-9]+)/) {
-			my $pid = $1;
-			if (!defined($rows[$pid])) {
-				$rowcount = $rowcount + 1;
-				$rows[$pid] = $rowcount;
-			}
-			$row{$func} = $rows[$pid];
+			$pids{$func} = $1;
 		}
 		$count = $count + 1;
 	}

@@ -109,17 +103,25 @@ $styles[11] = "fill:rgb(128,255,255);fill-opacity:0.5;stroke-width:1;stroke:rgb(
 my $mult = 950.0 / ($maxtime - $firsttime);
 my $threshold = ($maxtime - $firsttime) / 60.0;
 my $stylecounter = 0;
+my %rows;
+my $rowscount = 1;
 while (($key,$value) = each %start) {
 	my $duration = $end{$key} - $start{$key};
 
 	if ($duration >= $threshold) {
 		my $s, $s2, $e, $y;
+		$pid = $pids{$key};
+
+		if (!defined($rows{$pid})) {
+			$rows{$pid} = $rowscount;
+			$rowscount = $rowscount + 1;
+		}
 		$s = ($value - $firsttime) * $mult;
 		$s2 = $s + 6;
 		$e = ($end{$key} - $firsttime) * $mult;
 		$w = $e - $s;
 
-		$y = $row{$key} * 150;
+		$y = $rows{$pid} * 150;
 		$y2 = $y + 4;
 
 		$style = $styles[$stylecounter];

Arjan van de Ven

2008-10-04 20:19 UTC #1 lore raw

Quoted 10 lines · On Sat, 04 Oct 2008 21:35:48 +0200 Frederic Weisbecker <[email protected]>…

When bootgraph.pl parses a file, it gives one row
for each initcall's pid. But only few of them will
be displayed => the longest.
This patch corrects it by giving only a rows for pids which have initcalls that will be displayed.
You can see the result in attachment, before and after the patch.
Ingo, could you please revert the commit b4bc656397071b18c99e85d9181f076e44de8a99 which was a false solution to solve this problem. Thanks.

I wonder about this.. there's only supposed to be 2.... your graph is quite different.

Frédéric Weisbecker

author

2008-10-04 20:29 UTC #2 lore raw

2008/10/4 Arjan van de Ven <[email protected]>:

Quoted 10 lines

Quoted 7 lines · On Sat, 04 Oct 2008 21:35:48 +0200 Frederic Weisbecker <[email protected]>…
When bootgraph.pl parses a file, it gives one row
for each initcall's pid. But only few of them will
be displayed => the longest.
This patch corrects it by giving only a rows for pids which have initcalls that will be displayed.
You can see the result in attachment, before and after the patch.

Quoted 8 lines

Quoted 3 lines
Ingo, could you please revert the commit b4bc656397071b18c99e85d9181f076e44de8a99 which was a false solution to solve this problem. Thanks.
I wonder about this.. there's only supposed to be 2.... your graph is quite different.

I'm tracing all of the initcalls in my machine (even the modules). If you look at both svg sources, you will see all of the 5 initcalls displayed. But for the "before the patch" one, it depends on the software you are using to visualize it.
With firefox you only see two of them. With the default gnome visualization software (don't remember its name)
you can see all of them but in a very extensive image because a lot of rows are unused.

With the "after the patch one", there is no issues....

Arjan van de Ven

Acked-by

2008-10-04 20:40 UTC #3 lore raw

Quoted 10 lines · On Sat, 4 Oct 2008 22:28:49 +0200 "Frédéric Weisbecker" <[email protected]>…

I'm tracing all of the initcalls in my machine (even the modules). If you look at both svg sources, you will see all of the 5 initcalls displayed. But for the "before the patch" one, it depends on the software you are using to visualize it.
With firefox you only see two of them. With the default gnome visualization software (don't remember its name)
you can see all of them but in a very extensive image because a lot of rows are unused.
With the "after the patch one", there is no issues....

fair enough

Acked-by Arjan van de Ven <[email protected]>

Signature · 3 lines

Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Ingo Molnar

Applied

2008-10-05 09:56 UTC #4 lore raw

Quoted 12 lines · Arjan van de Ven

Quoted 9 lines · On Sat, 4 Oct 2008 22:28:49 +0200 "Frédéric Weisbecker" <[email protected]>…
I'm tracing all of the initcalls in my machine (even the modules). If you look at both svg sources, you will see all of the 5 initcalls displayed. But for the "before the patch" one, it depends on the software you are using to visualize it.
With firefox you only see two of them. With the default gnome visualization software (don't remember its name)
you can see all of them but in a very extensive image because a lot of rows are unused.

Quoted 5 lines

Quoted 1 line
With the "after the patch one", there is no issues....
fair enough
Acked-by Arjan van de Ven <[email protected]>

applied to tip/tracing/core, thanks!

Frédéric, is the revert still needed, or is latest tip/master OK ?

Ingo

Frédéric Weisbecker

author

2008-10-05 11:22 UTC #5 lore raw

2008/10/5 Ingo Molnar <[email protected]>:

Quoted 1 line

Frédéric, is the revert still needed, or is latest tip/master OK ?

Yes it should be reverted. Tracing is still stopped at the end of kernel_init().

Thanks!

A message that is not in the archive (sent off-list or not yet received): [email protected]

Frederic Weisbecker

author

2008-10-06 12:21 UTC #8 lore raw

Quoted 19 lines · Frédéric Weisbecker

2008/10/6 Ingo Molnar <[email protected]>:
Quoted 10 lines · Frédéric Weisbecker
Quoted 5 lines
2008/10/5 Ingo Molnar <[email protected]>:
Quoted 1 line
Frédéric, is the revert still needed, or is latest tip/master OK ?
Yes it should be reverted. Tracing is still stopped at the end of kernel_init().
lost track - exactly which commit ID should be reverted?
Ingo
Hmm actually, the "stop_boot_trace" feature may be needed in the future. If I trace the shed events too,
I should be able to limit the tracing to avoid too much entries. I will see later.
Perhaps just a patch to remove the trace stopping after builtin initcalls. I will submit it soon.

Quoted 4 lines

Sorry, just forget this revert request.
Thanks.

From: Frederic Weisbecker <[email protected]>
Subject: [PATCH -tip] Tracing/fastboot: Revert the stopping of the boot tracer

Since the patch that stopped the tracing after builtin-initcalls wasn't a real solution of a bootgraph.pl's bug, we may continue to trace boot after builtin initcalls. But we want to keep the stop_boot_trace function for further uses.

Signed-off-by Frederic Weisbecker <[email protected]>

---

init/main.c +0 -1

index 6371981..f039e7a 100644
@@ -975,7 +975,6 @@ static int __init kernel_init(void * unused)
 	 * we're essentially up and running. Get rid of the
 	 * initmem segments and start the user-mode stuff..
 	 */
-	stop_boot_trace();
 	init_post();
 	return 0;
 }