Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

On Fri, 15 Sep 2006 17:00:47 +0200
Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:

On Fri, 2006-09-15 at 10:51 -0400, Karim Yaghmour wrote:
And what I did is "b". I wasn't going to defend anybody else's
choice of tracepoints. Those who were using ltt for its designated
purpose -- allowing normal users and developers to get an accurate
view of the behavior of their system -- were very happy with it.

You want to know who was unhappy with using it: kernel developers.
It just wasn't geared for them. Which goes back to my earlier
arguments ...

What do you want to prove with this rant ? Simply the fact that your
view of tracing is not matching the view of others. Nothing else.

What Karim is sharing with us here (yet again) is the real in-field
experience of real users (ie: not kernel developers).

I mean, on one hand we have people explaining what they think a tracing
facility should and shouldn't do, and on the other hand we have a guy who
has been maintaining and shipping exactly that thing to (paying!) customers
for many years.

Me thinks our time would be best spent trying to benefit from his
experience..


Me, I'm not particularly averse to some 50-100 static tracepoints if
experience tells us that we need such things. And both Karim's and Frank's
experience does indicate that such things are needed, which carries weight.

What I _am_ concerned about with this patchset is all the infrastructural
goop which backs up those tracepoints. I'd have thought that a better
approach would be to make those explicit tracepoints be "helpers" for the
existing kprobe code.

Of course, it they are properly designed, the one set of tracepoints could
be used by different tracing backends - that allows us to separate the
concepts of "tracepoints" and "tracing backends".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    ... a- Maintain their tracepoints for them -- not happening. ... dynamic probes. ... purpose -- allowing normal users and developers to get an accurate ...
    (Linux-Kernel)
  • Re: [PATCH 1/4] tracing: move __DO_TRACE out of line
    ... But it isn't that much larger than the inline version: ... but other tracepoints have multiple users). ... having tracing configured but not enabled. ... Once we get the thread_info headers ...
    (Linux-Kernel)
  • Re: [PATCH 1/4] tracing: move __DO_TRACE out of line
    ... OK, here's a comparison for trace_sched_switch, comparing inline and out of line tracing functions, with CONFIG_PREEMPT enabled: ... But it isn't that much larger than the inline version: 34 instructions, ... This code will also be shared among all instances of the tracepoint (not in this case, because sched_switch is unique, but other tracepoints have multiple users). ... This should reduce the overhead of having tracing configured but not enabled. ...
    (Linux-Kernel)
  • [GIT PULL] Tracing updates for v2.6.31
    ... tracing: add saved_cmdlines file to show cached task comms ... x86: use native register access for native tlb flushing ... avoid warnings from zero-arg tracepoints ... move function profiler data out of function struct ...
    (Linux-Kernel)
  • Re: [ltt-dev] LTTng 0.10-pre58 for linux 2.6.26-rc9 (with userspace tracing for x86)
    ... Mathieu Desnoyers wrote: ... Architecture independent markers converted to tracepoints. ... Re-introduction of userspace tracing, ...
    (Linux-Kernel)