lkml.org 
[lkml]   [2006]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

    * Karim Yaghmour <karim@opersys.com> wrote:

    > > So you dispute that markups for dynamic tracing will be more
    > > flexible and you dispute that they will be less intrusive than
    > > markups for static tracing?
    >
    > No, I'm saying that the flexibility of the markup is not tied to the
    > instrumentation "grab" mechanism (direct call or binary editing.)
    > That's the "arbitrary" I'm talking about.

    ok, then i'd like to dispute your point. Contrary to your statement
    there is a very fundamental difference between "static tracing" (static
    call, which relies on compile-time insertion of trace points) and
    "dynamic tracing" (which can insert trace points almost anywhere) -
    _even if both use in-source markers_.

    The fundamental difference is this: dynamic tracing has full access to
    the full environment of the code that it taps into _at the time of
    tracepoint activation_, while static tracing has to get all its context
    during compilation.

    To make my point easier to understand, consider the following example:
    we want to tap into the middle of a global_function():

    int global_function(int arg1, int arg2, int arg3)
    {
    ... [lots of code] ...

    x = func2();

    ... [lots of code] ...
    }

    We want to trace the function right after 'x' has been assigned, and we
    want to trace an event_A, with parameters: arg1, arg2, arg3 and x. This
    is a pretty common scenario. Ok so far?

    here is how the markup looks like under static tracing:

    int global_function(int arg1, int arg2, int arg3)
    {
    ... [lots of code] ...

    x = func2();
    D(event_A, arg1, arg2, arg3, x);

    ... [lots of code] ...
    }

    that's what you'd expect, right? This is pretty common too, up to this
    point.

    now how could the markup look like for a dynamic tracepoint:

    int global_function(int arg1, int arg2, int arg3)
    {
    ... [lots of code] ...

    x = func2();
    D(event_A, x);

    ... [lots of code] ...
    }

    Note: there's no (arg1, arg2, arg3) passed to the markup! Why? Because
    SystemTap has full access to the function's arguments and in this
    particular case it's simply not necessary to reference them explicitly.
    So the markup has less of an overhead because it does not 'touch' arg1,
    arg2, arg3 if the tracepoint is not active [which is the common case we
    optimize for].

    Furthermore, the markup is also visually less intrusive.

    But better than that, the markup could look like this as well:

    int global_function(int arg1, int arg2, int arg3)
    {
    ... [lots of code] ...

    x = func2();

    ... [lots of code] ...
    }

    right, no markup at all, but in a script somewhere we'd have:

    insert.trace(global_function: "x = func2();", after);

    or maybe even in a script, annotated in patch format, so that the
    context of the tapped code is captured too.

    so, as a result: the dynamic markup() does the same, but has less impact
    on the compiled code (less parameters touched), and is more flexible in
    terms of attachment to the source code.

    Can we do any of this with the static tracepoint? We cannot,
    fundamentally! So if we allowed static tracers to access that tracepoint
    anytime, we could never make things more intelligent there in the
    future!

    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: 2006-09-16 02:03    [W:3.602 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site