[lkml]   [2005]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.11-rc1-mm1
    Thomas Gleixner wrote:
    > On Fri, 2005-01-14 at 00:23 -0800, Andrew Morton wrote:
    >>- Added the Linux Trace Toolkit (and hence relayfs). Mainly because I
    >> haven't yet taken as close a look at LTT as I should have. Probably neither
    >> have you.
    > I have. Maybe you should have. I really don't see a good argument to
    > include this code.

    [ Lots of excellent criticisms omitted.]

    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 did a short test on a 300MHz PIII box and the maximum time spent in
    > the log path (interrupts disabled during measurement) is about 30us.
    > Extrapolated to a 74MHz ARM SoC it will sum up to ~ 90-120us, what makes
    > it purely useless.

    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.

    > Summary:
    > 1. The code is not doing what it claims to do.
    I'm guessing the sense of this is in the micro-claims which are implied
    (e.g. runs lockless and therefore avoids cache thrashing), rather than
    the high-level claim of providing useful information in some situations.
    It clearly does the latter. At least is has for me.

    > 2. The code adds unnecessary overhead
    I agree it could be improved. The threshold for "unnecessary" varies
    by task.

    > 3. It's not useful for low speed systems.
    I've used it on low speed systems.

    > Question:
    > Why is the code included ?
    See above.

    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.

    Tim Bird
    Architecture Group Chair, CE Linux Forum
    Senior Staff Engineer, Sony Electronics
    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.045 / U:28.924 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site