On March 23, Jan Kara proposed a patch that would
enable tracepoints selectively for different subsystems at build time. His
that debugging one particular area using tracepoints would end up
"polluting" other kernel paths with tracepoint checks.
Allowing tracing for a particular subsystem, without the potential
performance degradation from tracepoint tests in other subsystems, is the
goal. But various
other kernel hackers saw things differently.
Quite a bit of work has gone into making disabled-but-present tracepoints
have a very minimal impact on performance. Frederic Weisbecker described it this way: "each tracepoint is a lightweight
thing and induce a tiny overhead, probably hard to notice, and
this is going to be even more the case after the jmp label
optimization patches." There are lots of benefits to having
tracepoints be an "all or none" proposition as well. As part of developing
tracepoints, Mathieu Desnoyers thought
about and rejected the idea:
When I considered if it was worth it to create
such a per-tracepoint group compile-time disabling in the first place, I decided
not to do it precisely due to the added-value that comes with the availability
of system-wide tracepoints. And I think with the static jump patching, we are
now at a point where the overhead is stunningly low.
Ted Ts'o sees that "a lot of the
value of tracepoints goes away if people are compiling kernels without them
and we need to get a special 'tracing kernel' installed before we can debug
a problem". Both Ingo Molnar and Steven Rostedt also agreed, making
the prospects for this change rather dim. While piecemeal tracepoints seem attractive at
first glance, the value of tracepoints comes, at least partially, from
having them all available at once. The belief and hope is that they are
built into nearly every kernel, so that when problems arise, they are there,
ready to be used.
to post comments)