| |||||||||||||
|
| |||||||||||||
You *can't* require an unchanging interface to changeable internals.You *can't* require an unchanging interface to changeable internals.Posted Sep 22, 2006 0:57 UTC (Fri) by dlang (✭ supporter ✭, #313)In reply to: You *can't* require an unchanging interface to changeable internals. by AJWM Parent article: Tracing infrastructures
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)
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.
(Log in to post comments)
You *can't* require an unchanging interface to changeable internals. Posted Sep 28, 2006 21:57 UTC (Thu) by efexis (guest, #26355) [Link] 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-).
|
|
||||||||||||