lkml.org 
[lkml]   [2008]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] tracing/function-graph-tracer: adjustments of the trace informations

    * Frédéric Weisbecker <fweisbec@gmail.com> wrote:

    > 2008/11/28 Ingo Molnar <mingo@elte.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?

    Yeah, that needs updating. I supposed you'd be working on the task+pid
    column anyway, and do a helper function that prints the task-pid couple.
    Then that helper can be used in the context-switch case too to print out
    a uniform ID.

    Another thing that would be nice is to separate out the "cpu)" printing
    bits into a helper function. Right now what exists cannot be used in a
    seq-manner, so i couldnt reuse it.

    Anyway, i wont change it (just wanted to get a final-ish output to look
    at) so feel free to clean it all up thoroughly :)

    Today i played with the graph-tracer on a testbox _way_ too much.
    Combined with the wildcard filter it's _really_ addictive. Kernel
    developers, beware!

    One thing that came up: it would be nice to have an 'inverted' wildcard
    to punch out certain functions from the filter list. For example i did in
    the shell:

    $ echo 'sys_*' >> set_ftrace_filter
    $ echo '*socket*' >> set_ftrace_filter
    $ echo '*timer*' >> set_ftrace_filter
    $ echo '*skb*' >> set_ftrace_filter

    and looked at the trace and found that certain functions are too verbose
    and not really interesting - so i wanted to exclude them.

    We've got set_ftrace_notrace but it's not really an inverse wildcard but
    a complementary set of filter functions - which is not the same and not
    as easy to think about as a single set of filter functions.

    what i think would be more natural to do is via the filter file itself,
    via an extension like:

    $ echo '!timer_*' >> set_ftrace_filter

    which would eliminate the functions matching that negative pattern. Such
    negative wildcards would act on the current set of functions, while
    set_ftrace_notrace is permanent and cannot be used to shape an arbitrary
    set of functions iteratively.

    > > 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...

    yeah.

    The other small detail in the scheme i suggested is that the loss of
    nanosec precision and its gradual weakening to usec precision is
    immaterial in practice as well: we still have at least 9 significant
    digits, so the relative precision is around 1:1000000000 - more than
    enough.

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

    \
     
     \ /
      Last update: 2008-11-28 15:21    [W:4.083 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site