[lkml]   [2008]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 00/11] mcount tracing utility
    Hi Steven,

    Great work!

    (added Tim Bird, author of KFT/KFI to the CC list)

    * Steven Rostedt ( wrote:
    > Future:
    > -------
    > The way the mcount hook is done here, other utilities can easily add their
    > own functions. Just care needs to be made not to call anything that is not
    > marked with notrace, or you will crash the box with recursion. But
    > even the simple tracer adds a "disabled" feature so in case it happens
    > to call something that is not marked with notrace, it is a safety net
    > not to kill the box.
    > I was originally going to use the relay system to record the data, but
    > that had a chance of calling functions not marked with notrace. But, if
    > for example LTTng wanted to use this, it could disable tracing on a CPU
    > when doing the calls, and this will protect from recusion.

    Yes, I'd love to add this information source to LTTng. It simply boils
    down to adding a "notrace" flag to LTTng tracing functions. Since I
    don't use relay code _at all_ in the tracing path, there is no problem
    with this (I only disable preemption and do "local" atomic operations on
    per-cpu variables). Then I would have to do the glue code that registers
    the LTTng handler to your mcount mechanism.

    One interesting aspect of LTTng is that is would be very lightweight.
    You seem to use interrupt disabling with your simple tracer and do a
    _lot_ of cacheline bouncing (trace_idx[NR_CPUS] is a very good exemple).

    LTTng would write the information to a per-cpu memory buffer in binary
    format. I see that it would be especially useful in flight recorder
    mode, where we overwrite the buffers without writing them to disk : when
    a problematic condition is reached, (a kernel oops would be a good one),
    then we just stop tracing and dump the last buffers to disk. In this
    case, we would have the last function calls that led to an OOPS.


    Mathieu Desnoyers
    Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68

     \ /
      Last update: 2008-01-03 18:25    [W:0.022 / U:3.452 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site