Message-Id: <200804252305.m3PN5SFL008798@crisp.demon.co.uk>
Date:	Sat, 26 Apr 2008 00:05:28 +0100
From:	paul <fox@...sp.demon.co.uk>
To:	t-nishiie@...css.fujitsu.com, bart.vanassche@...il.com
Cc:	linux-kernel@...r.kernel.org
Subject: RE: dtrace for linux


> >> On Sun, Apr 20, 2008 at 1:17 AM,  <fox@...sp.demon.co.uk> wrote:
> >>>
> >>>  I would like to announce that I am working on dtrace for Linux.
> >>>  I have the userland dtrace binary compiled, along with the first
> >>>  pre-pre-alpha dtracedrv.ko module loaded into my kernel.
> >> 
> >> This is great news. How will this dtrace implementation differ from
> >> SystemTap (http://sourceware.org/systemtap/) ?
> >> 
> >> Bart.
> >> 
> >> 
> >
> >Hello Bart,
> >
> >
> >I dont know systemtap all that well, other than what i have
> >read on the net and browsed in the source. systemtap is similar,
> >but dtrace provides a high level functional language (D) and
> >a set of methodologies and scripts which mean learning/training
> >will make it easier to use.
> 
> Hello,
> 
>   SystemTAP is the tool developed in order to do the same thing 
> as Dtrace. When development of SystemTAP started, Dtrace was not
>  able to be used with restriction by the license at linux. The 
> difference in both SystemTAP and Dtrace is produced by avoiding 
> being based on mounting peculiar to linux, and a license.
> 
>   By the way, aren't any ideas found in order to mitigate the 
> load when acquiring trace? If load when having taken trace as 
> for LTTng as for SystemTAP is too heavy, I feel. For example, 
> it is desirable that trace with lighter load can be taken by the
>  limiting conditions of obtaining the trace result only for 
> several seconds until panic occurs. 
> 
> Regards

I'm not really taking part in the licensing discussion - its complex,
and partially personal, and I am not in a good position to advise
either way. I am not seeking to close the source or make $$$ out of it,
so from a 'free' point of view, its something the receiver will need
to decide for themselves. At best, I am adding something to the free-pool,
and not claiming any innovation or righs over the code.

The subtle difference between systemtap and dtrace - as i see it -
is that dtrace has a well thought out language. Systemtap doesnt.
The mechanisms of both are similar at a base level, but in practise
dtrace is designed to be more 'modular'. Sun spent a lot of effort
to put the hooks in to let dtrace be effective. Some of the hooks are
available in linux - some not. So its a matter of quality of implementation.

As for performance - they are possibly similar but based on different
principals. Dtrace (like systemtap) costs nothing if you dont use it.
If you do, the performance impact depends on the quality of your
scripts (but cannot cause a kernel panic or infinite loop - in theory).
Systemtap doesnt make such guarantees. The whole raison for d'etre
for dtrace/systemtap is that when you need it, you need it *bad*. And
the minor perf hit is likely acceptable for your specific use-case.

I am not an expert in dtrace or systemtap - i have knowledge of
some aspects of both, and anything i may write on the matter may
be suspect/wrong/incorrect. I hope to correct my incorrect understandings
by virtue of this project.

BTW: progress this week has been near-zero due to a fight between
me + Ubuntu to get a custom Linus kernel to boot. Hopefully the weekend
will fare better.

-pdf

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists