[lkml]   [2005]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.11-rc1-mm1
    Hi Tim,

    On Fri, 2005-01-14 at 15:22 -0800, Tim Bird wrote:
    > [ Lots of excellent criticisms omitted.]

    Thanks for the compliment :)

    > I don't want to be argumentative, but possibly (to answer your last
    > question first), there are twofold reasons to put this in -mm:
    > - there's no tracing infrastructure in the kernel now (except for
    > kprobes - which provides hooks for creating tracepoints dynamically,
    > but not 1) supporting infrastructure for timestamping, managing event
    > data, etc., and 2) a static list of generally useful tracepoints.
    > - to generate this discussion.

    I have no objection at all to put instrumentation into the kernel. Quite
    the contrary, I would appreciate it.

    Putting tracepoints into the kernel is great.
    Providing a trace/log/instrumentation framework is great.
    Adding the given overhead is not.

    > I've used it for various tasks, and I know others who have. I wouldn't
    > recommend it in its present form for deep scheduling tweaks or debugging
    > kernel race conditions (which it is more likely to mask than
    > it is to find), but inapplicability there hardly makes it worthless for
    > other things.

    Putting a 200k patch into the kernel for limited usage and maybe
    restricting a generic simple non intrusive and more generic
    implementation by its mere presence is making it inapplicable enough.

    Merge the instrumentation points from ltt and other projects like DSKI
    and the places where in kernel instrumentation for specific purposes is
    already available and use a simple and effective framework which moves
    the burden into postprocessing and provides a simple postmortem dump
    interface, is the goal IMHO.

    When this is available, trace tool developers can concentrate on
    postprocessing improvement rather than moving postprocessing
    incapabilities into the kernel.

    > By the way, don't think that your comments are not appreciated.
    > I'm not particularly glued to any specific part of the implementation.
    > I'm excited to see tracing discussed here, if only to avoid
    > duplicate efforts and point out danger areas, for multiple tracing
    > projects that I am aware of.

    So I'm I.


    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: 2005-03-22 14:09    [W:0.021 / U:7.100 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site