linux-kernel - Re: [PATCH] tracing/function-graph-tracer: adjustments of the trace informations

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 28 Nov 2008 14:55:44 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Tim Bird" <tim.bird@...sony.com>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing/function-graph-tracer: adjustments of the trace informations

2008/11/28 Ingo Molnar <mingo@...e.hu>:
> Firstly, what do you think about the additional tweaks i did - see the
> patch below?
>
> Before:
>
> 0)           |     sys_read() {
> 0)      0.796 us |   fget_light();
> 0)           |       vfs_read() {
> 0)           |         rw_verify_area() {
> 0)           |           security_file_permission() {
> ------------8<---------- thread sshd-1755 ------------8<----------
>
> After:
>
>  0)               |  sys_read() {
>  0)      0.796 us |    fget_light();
>  0)               |    vfs_read() {
>  0)               |      rw_verify_area() {
>  0)               |        security_file_permission() {
>  ------------------------------------------
>  | 1)  migration/0--1  =>  sshd-1755
>  ------------------------------------------


Thanks! That good, but I remember you wanted a limited number of
characters for thread name/pid couple?


> Secondly:
>
>> +     /* Must not exceed 8 characters: xxxx.yyy us */
>> +     if (duration > 10000000ULL)
>> +             duration = 9999999ULL;
>
> 10 milliseconds isnt much or full system calls, etc.- so i believe the
> rule should be what i outlined in an earlier mail. The relevant
> transition points go like this:
>
>     0.000
>  xxxx.yyy
>  9999.999
>  10000.00
>  xxxxx.yy
>  99999.99
>  100000.0
>  xxxxxx.y
>  999999.9
>   1000000
>   9999999
>  10000000
>  xxxxxxxx
>  99999999 [ 100 seconds ]
>  100000000 ... up to infinity
>
> this way we can get up to 99999999 usecs with the same fixed width -
> or 100 seconds. _That_ is enough in practice.
>
> But even beyond that we should print it all out: we should still not
> clip actual information but instead shift the line to the right. The
> slightly inconsistent line is not a big problem - we want a 100
> seconds delay to stand out anyway ;-)
>
> The moving decimal point above 10 milliseconds is not a big problem
> with the '+' and '!' marker. Maybe add a '!!' marker to these lines?


Yeah, I was sure I misunderstood your idea about it in your last email :-)
Ok. I will do so, I felt a bit uncomfortable with the fixed width above a limit,
so I like it this way. Long sleeping functions will be rare enough in the trace
to let us move a bit the columns to the right in such cases...

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/