* Jose R. Santos <[email protected]> wrote:
> [...] While it is true that static probes will provide less overhead
> compared to dynamic probes, [...]
that is not true at all. Yes, an INT3 based kprobe might be expensive if
+0.5 usecs per tracepoint (on a 1GHz CPU) is an issue to you - but that
is "only" an implementation detail, not a conceptual property.
Especially considering that help (djprobes) is on the way. And in the
future, as more and more code gets generated (and regenerated) on the
fly, dynamic probes will be _faster_ than static probes - plainly
because they adapt better to the environment they plug into.
so there's basically nothing to balance. My point is that dynamic probes
have won or will win on every front, and we shouldnt tie us down with
static tracers. 5 years ago with no kprobes, had someone submitted a
clean static tracer patchset, we could probably not have resisted it (i
though probably would have resisted it on the grounds of maintainance
overhead) and would have added it because tracing makes sense in
general. But today there's just no reason to add static tracers anymore.
NOTE: i still accept the temporary (or non-temporary) introduction of
static markers, to help dynamic tracing. But my expectation is that
these markers will be less intrusive than static tracepoints, and a lot
more flexible.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
