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

Mathieu Desnoyers wrote:
Please Ingo, stop repeating false argument without taking in account people's
corrections :

* Ingo Molnar (mingo@xxxxxxx) wrote:
sorry, but i disagree. There _is_ a solution that is superior in every aspect: kprobes + SystemTap. (or any other equivalent dynamic tracer)

I am sorry to have to repeat myself, but this is not true for heavy loads.

Alan pointed out earlier in the thread that the actual kprobe is noise
in this context, and I have seen similar issues on real workloads. Yes
kprobes are probably a little higher overhead in real life, but you have
to way that up against the rest of the system load.

If you want to prove people wrong, I suggest you do some real life
implementation and measure some real workloads with a predefined set of
tracepoints implemented using kprobes and LTT and show us that the
benchmark of the user application suffers in a way that can actually be
measured. Argueing that a syscall takes an extra 50 instructions
because it's traced using kprobes rather than LTT doesn't mean it
actually has any real impact.

"The 'kprobes' are too high overhead that makes them unusable" is one of
these classic myths that the static tracepoint advocates so far have
only been backing up with rhetoric. Give us some hard evidence or stop
repeating this argument please. Just because something is repeated
constantly doesn't transform it into truth.

Jes
-
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: [RFC] Instrumentation (was Re: 2.6.11-rc1-mm1)
    ... LTT that were based on third-hand account and no direct contact ... kprobes would seem largely sufficient. ... was already interfacing with DProbes for dynamic insertion of trace ... > aggregate information in buffers. ...
    (Linux-Kernel)
  • Re: 2.6.11-rc1-mm1
    ... > I think it would be better to have a standard set of kprobes instead ... > of all the ugly LTT hooks. ... There it fills a niche that printk doesn't fill ...
    (Linux-Kernel)
  • Re: [RFC] Instrumentation (was Re: 2.6.11-rc1-mm1)
    ... From all I've heard and seen of LTT (and I have to admit that most ... of it comes from reading this thread, not from reading the code), ... kprobes would seem largely sufficient. ... doesn't have a trap instruction ...
    (Linux-Kernel)
  • Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
    ... only to the extent of automating the placement of kprobes: ... Unfortunately systemtap doesn't have a proper layered ... tracing framework in for lockdep and fault injection and be available ...
    (Linux-Kernel)
  • Re: [RFC] fix kallsyms to allow discrimination of local symbols
    ... topic that is irrelevant to the patch series you're actually proposing. ... worrying on the wrong area of code (anything in/near kprobes). ... Systemtap is using the DWARF information from the vmlinux file and/or ... James is offended by the fact that Systemtap is not utilizing this ...
    (Linux-Kernel)