You *can't* require an unchanging interface to changeable internals.
You *can't* require an unchanging interface to changeable internals.
Posted Sep 21, 2006 7:34 UTC (Thu) by xoddam (subscriber, #2322)Parent article: Tracing infrastructures
> Tracepoints clutter the code itself, and they must continue to
> work into the indefinite future. In a sense, each one can be
> thought of as a little system call which, once placed, cannot
> be changed.
That argument looks absurd to me. A tracing interface is intimately
tied to kernel internals. There is no way it should be considered
part of the "Don't break userspace" contract.
The 'marker' idea looks very sound to me. A config option at
compile time could choose static tracepoints, dynamic tracepoints
or no tracepoints at all. Maintaining a set of tracepoints 'out
of tree', when the tracepoints are plainly inside the kernel,
makes far *less* sense than eg. an out-of-tree device driver.
Posted Sep 21, 2006 19:56 UTC (Thu)
by AJWM (guest, #15888)
[Link] (2 responses)
Yes, my thoughts exactly on reading this article. It seems to be something that is crying out for a config option or two.
There's still the argument that it's that much more code to maintain, but any arguments about runtime effects would be decided by whoever does the compile.
Posted Sep 22, 2006 0:57 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
this needs to be something that redhat (and others) can leave on all the time so that when there are problems the tools can be used.
if you have to recompile the kernel and reboot your production system into a lower-performing kernel for days to weeks until you can duplicate the problem you just are not going to do so.
however if you can run for days or weeks with normal performance, and then when teh problem kicks in load up the tracer to capture what's going on for a bit before you reboot to get things back up again, you have a tool that can be used.
Posted Sep 28, 2006 21:57 UTC (Thu)
by efexis (guest, #26355)
[Link]
Posted Sep 28, 2006 21:38 UTC (Thu)
by jd (guest, #26381)
[Link]
For that matter, we've a bazillion wrappered calls to BUG() and
Torvalds-knows-what else. I see a far stronger cause for objecting to
multiple independently-maintained wrappers to trivial, highly specific
operations. It would seem to make much more sense to have a single
meta-macro that allowed ANY of the assorted tools (lsm, static probes,
kernel debugging info, jelly babies, etc) to use ANY of the points to make
decisions, based on their specific requirements and the configuration at
the time.
This would put all of the complexity into a single meta-macro (so
eliminating almost all maintenance issues) and would provide a far wider
range of sampleable points for future updates.
In general, added complexity is a Bad Thing. However, if by adding
something, you provide a general, unified solution to N existing problems
that previously needed N independent solutions, you have actually reduced
complexity, which is a Good Thing.
I would not want LTT to be a mainstream kernel component if it actually
added to the complexity of the system, but since I see no reason for
complexity to be added and ways in which complexity can be removed, I
believe LTT in the mainstream kernel is not only achievable but has the
potential to cut a lot of crud out. To me, that would be wonderful.
> A config option atYou *can't* require an unchanging interface to changeable internals.
> compile time could choose static tracepoints, dynamic tracepoints
> or no tracepoints at all.
the problem is that if it has a significant runtime effect it won't be turned on when you need it (production systems running distro kernels)You *can't* require an unchanging interface to changeable internals.
Can't we learn anything from SMP Alternatives? Ie, stick a couple of NOP's in the code big enough to replace it with a CALL instruction when you want to add a tracepoint there. On 64bit systems I guess the CALL instruction is going to be longer (including the 64bit address), so maybe a JMP $+9 and a few NOP's would be quicker than just the NOP's (I haven't looked into processor instruction timings for a -long time-).You *can't* require an unchanging interface to changeable internals.
We already have vast numbers of wrappered calls to the LSM, so clearly
people don't object THAT strenuously to wrappered calls in the code. (In
fact, if the static tracing were implemented as a LSM module, you could
even use the SAME wrappered calls and not need to add a damn thing that
isn't already being maintained anyway.)
I don't see the issue.