On Mon, Jun 2, 2008 at 4:00 PM, Iruata Souza <[EMAIL PROTECTED]> wrote:
> I don't have any solaris boxes to play now, but I remember when taking > a dtrace course - more or less two years ago - that I managed to see > the performance of a nice machine go down only by setting all it's > tracing points. I know that this could be considered normal if it > wasn't for the fact that, with two xterms opened, the one which > started dtrace, after a series of ^C, had 'transfered' to it the > command-line history of the other xterm. It was a peculiar situation > since the instructor was telling us about the non-intrusiveness of the > tool. > it's worth reading the papers. Dtrace is quite capable. But look at the issues. You are taking a piece of code and splicing in another piece of code. It can get fun. What if someone was running the code you are splicing (think: SMP). What about time to remove it: make sure that (a) nobody is running the spliced in code (how do you do that in the general case) and (b) nobody is trying to run where you are putting the code back. What if the original code had an INT instruction? What if it tickled an IRQ? What if code you spliced in takes a fault? Check out the kprobes device in linux to see how nasty it can get. At the same time, people delivering software to end users make good use of dtrace, so it's kind of hard to fault Sun for putting it in there -- they do have paychecks to hand out. And I expect that lots of customers demand that it stay in there ... ron
