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

    * Roman Zippel <> wrote:

    > Hi,
    > On Thu, 14 Sep 2006, Ingo Molnar wrote:
    > > > On Thu, 14 Sep 2006, Ingo Molnar wrote:
    > > >
    > > > > i have one very fundamental question: why should we do this
    > > > > source-intrusive method of adding tracepoints instead of the dynamic,
    > > > > unintrusive (and thus zero-overhead) KProbes+SystemTap method?
    > > >
    > > > Could you define "zero-overhead"?
    > >
    > > zero overhead when not used: not a single instruction added to the
    > > kernel codepath that is to be traced, anywhere. (which will be the case
    > > on 99% of the systems)
    > Using alternatives this could be near zero as well and it will likely
    > have less overhead when it's actually used.

    if there are lots of tracepoints (and the union of _all_ useful
    tracepoints that i ever encountered in my life goes into the thousands)
    then the overhead is not zero at all.

    also, the other disadvantages i listed very much count too. Static
    tracepoints are fundamentally limited because:

    - they can only be added at the source code level

    - modifying them requires a reboot which is not practical in a
    production environment

    - there can only be a limited set of them, while many problems need
    finegrained tracepoints tailored to the problem at hand

    - conditional tracepoints are typically either nonexistent or very

    for me these are all _independent_ grounds for rejection, as a generic
    kernel infrastructure.

    > > the key point is that we want _zero_ "static tracepoints". Firstly,
    > > static tracepoints are fundamentally limited:
    > BTW I don't mind KProbes as an option, but I have huge problem with
    > making it the only option.

    i'm not arguing for SystemTap to be the only option (KProbes is just the
    infrastructure SystemTap is using - there are other uses for KProbes
    too), but i'm arguing against the inclusion of static tracepoints as an
    infrastructure, precisely because a much better option (SystemTap) is
    already available and is usable on the stock kernel. You are of course
    free to invent other, equally advantageous (or better) options.

    > > But besides the usability problems, the most important problem is
    > > that static tracepoints add a _constant maintainance overhead_ to
    > > the kernel. I'm talking from first hand experience: i wrote
    > > 'iotrace' (a static tracer) in 1996 and have maintained it for many
    > > years, and even today i'm maintaining a handful of tracepoints in
    > > the -rt kernel. I _dont_ want static tracepoints in the mainline
    > > kernel.
    > Even dynamic tracepoints have a maintainance overhead and I doubt
    > there is much difference. The big problem is having to maintain them
    > outside the mainline kernel, that's why it's so important to get them
    > into the mainline kernel.

    i dispute that: for example kernel/sched.c has zero maintainance
    overhead under SystemTap, while it's nonzero with static tracepoints. Of
    course SystemTap _itself_ has maintainance overhead, but it does not
    slow down any other subsystem's speed of progress.

    > You didn't address my main issue at all - kprobes is only available
    > for a few archs...

    the kprobes infrastructure, despite being fairly young, is widely
    available: powerpc, i386, x86_64, ia64 and sparc64. The other
    architectures are free to implement them too, there's nothing
    hardware-specific about kprobes and the "porting overhead" is in essence
    a one-time cost - while for static tracepoints the maintainance overhead
    goes on forever and scales linearly with the number of tracepoints

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-09-14 19:25    [W:0.028 / U:7.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site