lkml.org 
[lkml]   [2006]   [Sep]   [14]   [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
    > i.e. we should have macros to prepare local information, with macro 
    > arities of 2, 3, 4 and 5:
    >
    > _(name, data1);
    > __(name, data1, data2);
    > ___(name, data1, data2, data3);
    > ____(name, data1, data2, data3, data4);

    Personally I think that's way more visually offensive that something
    that looks like a function call, but still ;-) We do it as a caps macro

    KTRACE(foo, bar)

    internally, which I suppose makes it not look like a function call.
    But at the end of the day, it's all just a matter of visual taste,
    what's actually in there is way more important.

    > that and nothing more. But no guarantees that these trace points will
    > always be there and usable for static tracers: for example about 50% of
    > all tracepoints can be eliminated via a function attribute. (which
    > function attribute tells GCC to generate a 5-byte NOP as the first
    > instruction of the function prologue.) That will be invariant to things
    > like function renames, etc.

    Yup, sometimes you just want to know when a function is called, and
    there's no real need to add that. The hook for system calls should be
    pretty generic too. But things like instrumenting the reclaim code need
    more work - I ended up incrementing some counters for each type of page
    recovery failure in shrink_list() and then just logging one compound
    event on the stats structure at the end. That's pretty specific, but
    does give you a lot of useful data when the box is dying from mem
    pressure.

    >> So perhaps it'll all work. Still need a little bit of data maintained
    >> in tree though.
    >
    > ok. And i think SystemTap itself should be in tree too, with a couple of
    > examples and helper scripts all around tracing and probing - and of
    > course an LTT-compatible trace output so that all the nice LTT userspace
    > code and visualization can live on.

    I have to figure out how to graft the internal Google stuff onto the
    same mechanism ... I definitely want to be able to combine the static
    points with dynamic ones. And then add schedstats and blktrace into
    the same thing so it interleaves properly ... seeing the blktrace type
    data interact with memory reclaim debugging was very useful to me, for
    instance. All these little fragmented tools are way more difficult to
    deal with.

    M.

    -
    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 03:09    [W:2.227 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site