Messages in this thread | | | Date | Thu, 14 Sep 2006 18:04:21 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [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/
| |