linux-kernel - Re: [PATCH] tracing/function-return-tracer: set a more human readable output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c62985530811260311k4237012asd27ebd8599328cea@mail.gmail.com>
Date:	Wed, 26 Nov 2008 12:11:15 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing/function-return-tracer: set a more human readable output

2008/11/26 Ingo Molnar <mingo@...e.hu>:
> 1) Compression of non-nested calls into a single line.
>
>   Implementing this probably necessiates some trickery with the
>   ring-buffer: we'd have to look at the next entry as well and see
>   whether it closes the function call.


I wanted to do so. That's not so easy, I guess I will not only have to read
the next entry. I'll have to modify it to avoid the next entry to
print a closing brace.
But I don't think that would be a problem.
Note with this method that if there is a context switch or an
interrupt between the entry and
the return of a leaf function, it will not anymore be considered as a non-nested
function on its output.
But the case would be rare enough, so I will apply this.

> 2) Adding a closing ';' semicolon to single-line calls. It's the C
>   syntax and i'm missing it :-)


Yeah :-)


> 3) The first column: single-character visual shortcuts for "overhead".
>   This is a concept we used in the -rt tracer and it still lives in
>   the latency tracer bits of ftrace and is quite useful:
>
>    '+' means "overhead spike": overhead is above 10 usecs.
>    '!' means "large overhead": overhead is above 100 usecs.
>
>   These give at-a-glance hotspot analysis - hotspots are easier to
>   miss as pure numbers.
>
> 4) Printing out in units of microseconds, with a decimal point and by
>   explicitly mentioning the 'us' unit.
>
>   All of these are important properties: microseconds is still the
>   most common 'overhead' unit in kernel circles. It also gives rather
>   human single-digit or two-digit results. Nanoseconds is three or-
>   four-digit - which is too much. Repeating 'us' so many times is not
>   a problem - these lines will be grepped, quoted, etc - constant
>   reminder about the unit is just fine.
>
> 5) Nesting the overhead numbers aligned to the right end of the graph.
>
>   This cleans up the view of the source code printout, but not
>   cluttering it with numbers. It also structures the numbers some
>   more. Visual cues are given via '-' and '+' signs, to follow
>   nesting. This nesting aligns up with the function nesting levels on
>   the left side - so it's easy to pair up number and function name.
>   It also separates the numbers from the symbol length effects in the
>   single-line case. (which is the most common trace line)


Totally agree!


> What do you think? It's lots of work (sorry! :-), but it would produce
> even more stunning graph-tracer output IMO.

Yes, I knew this was only a first try when I submitted it :-)
I will apply these suggestions.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/