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
    On Fri, Sep 15, 2006 at 08:38:33AM -0400, Karim Yaghmour wrote:
    > If you'd care to read through the thread you'd notice I've demonstrated
    > time and again that those static trace points we're mostly interested
    > in a never-changing. Lest something fundamentally changes with the
    > kernel, there will always be a scheduling change; etc. This
    > "instrumentation is evil" mantra is only substantiated if you view
    > it from the point of view of someone who's only used it to debug code.
    > Yet, and I repeat this again, instrumentation for in-source debugging
    > is but a corner case of instrumentation in general.
    >
    I didn't get the "instrumentation is evil" mantra from this thread,
    rather "static tracepoints are good, so long as someone else is
    maintaining them". The issue comes down to who ends up maintaining the
    trace points, and given with how intrusive LTT was in the past, I can't
    see anyone wanting to suddenly start littering them around the kernel
    now (at least in the areas that they're responsible for, particularly if
    it's not something that's going to be useful to most people). Admittedly
    LTTng is not as bad at this as LTT was in this regard, though.

    If static tracepoints are something that's useful for you, then you
    can continue maintaining them out of tree.

    > Yes, Mr. Scrub, I mean kprobes is your answer. The only reason you can
    > get away with this argument is if you view it exclusively from the
    > point of view of kernel development. And that's why you're wrong.
    >
    kprobes may not be the answer to all lifes problems, but it is
    non-intrusive once the initial implementation pains are out of the way..

    > Please explain, honestly, why the following instrumentation point is
    > going to be a maintenance drag on the person modifying the scheduler:
    > @@ -1709,6 +1712,7 @@ switch_tasks:
    > ++*switch_count;
    >
    > prepare_arch_switch(rq, next);
    > + TRACE_SCHEDCHANGE(prev, next);
    > prev = context_switch(rq, prev, next);
    > barrier();
    >
    > And please, don't bother complaining about the semantics, they can
    > be changed. I'm just arguing about location/meaning/content.
    >
    For someone complaining about meaningless posturing on the list, posting
    this as a representation for the isolated changes involved is rather
    interesting. If it were down to a small handful of critical static
    tracepoints in-tree and the rest left up to the people that really want
    them in out-of-tree patches, I doubt LTT would have ever had half of the
    resistance towards it.

    It's the intrusiveness that becomes the maintenance burden, and if you
    whittle it down to a point where the intrusiveness is not that big of a
    deal, then I'm not sure I see what static points would buy you over
    dynamic instrumentation.

    It's easy to write off the maintenance overhead when you aren't the one
    maintaining the code..
    -
    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-15 15:23    [W:6.217 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site