[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

    Ingo Molnar wrote:
    > 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

    Non-issue. See below. This is actually a feature, as can be seen
    by browsing the source code of various subsystems/filesystems/etc.
    who's authors saw fit to include their own static tracepoints.
    Darn, they must've been all misguided, so too were those who
    reviewed the code and let it in.

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

    Non-issue. See below.

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

    Non-issue. See below.

    > - conditional tracepoints are typically either nonexistent or very
    > limited.

    I don't get this one. What's a "conditional tracepoint" for you?

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

    I've addressed other issues in another posting, but I want to
    reiterate something here that Roman said that keeps getting

    There is no competition between static and dynamic trace points.
    They are both useful and complementary. If some set of existing
    static trace points are insufficient at runtime for you to
    resolve an issue, nothing precludes you from using the dynamic
    mechanisms for adding more localized instrumentation.

    Side point: you may be a kernel god, but there are mere mortals
    out there who use Linux. The point I've been making for years
    now is that there are legitimate reasons why normal non-kernel-
    developer users who would benefit greatly from being able to
    have access to tools that generate digested information
    regarding key kernel events. You can argue all you want about
    maintainability, and I continue to think you're wrong, but
    you should know that the development and usefulness of any such
    tools is gated by the continued inability to have a standard
    set of known-to-be-good source of key kernel events. And I
    repeat, the use of dynamic tracing does *not* solve this

    At OLS2005 I had suggested a development of a markers infrastructure
    who's users could use just to mark-up their code, the decision
    for tying such markers to a given type of instrumentation not
    actually being tied to the markers themselves. At OLS this
    year a very good talk was given on this topic by Frank from the
    systemtap team and it was very well received by the jam-packed
    audience. IOW, while there used to be a time when people pitted
    static instrumentation against dynamic instrumentation, there's
    been an ever growing consensus that no such choice need be made.


    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 20:05    [W:0.024 / U:1.400 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site