But [LWN.net]

But

Posted Oct 7, 2011 10:02 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (3 responses)

Very importantly, it has traction, particularly with Oracle's big audience of administrators and system programmers from a proprietary Unix background. Even if SystemTap does absolutely everything DTrace does, you know DTrace already.

This isn't a _huge_ audience, but it is one that's comfortable paying Oracle money. Making sure these people have a reason to ask specifically for Oracle's Linux, not Red Hat, will pay for itself. Previously DTrace was a reason for Solaris administrators to resist going Linux at all, but Oracle doesn't care about that, so it wants DTrace on Linux.

The license doesn't actually matter so much. If you know you want DTrace, that's a reason to choose Oracle, because the DTrace experts work for Oracle.

But

Posted Oct 7, 2011 20:36 UTC (Fri) by bcantrill (guest, #31087) [Link] (1 responses)

A point of clarification: the DTrace experts do not, in fact, work for Oracle; all three of the original team have left, as has Brendan Gregg (author of both the DTraceToolkit and the recent book on DTrace). A minor point, perhaps, but a significant one for those of us who have parted ways with the company -- especially as DTrace has continued to be developed under different ownership.

But

Posted Oct 8, 2011 23:53 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Thanks for that information. It seems as though this would make Oracle's attempt to port DTrace to Linux rather tricky, unless there is now equivalent expertise among a new generation of hackers at Oracle.

But

Posted Oct 10, 2011 1:43 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Presumably the variables and functions to monitor are sufficiently different between Solaris and Linux that the supposed advantage of dtrace just doesn't exist.

But

Posted Oct 7, 2011 12:01 UTC (Fri) by fuhchee (guest, #40059) [Link] (3 responses)

Systemtap has not limited itself to dtrace capabilities as an end goal. It already exceeds it in some interesting ways, and we plan to keep that going.

But

Posted Oct 8, 2011 19:02 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

Adoption is very limited at this point and wont grow till it requires no kernel patches and everything is in the mainline kernel. That is a huge problem.

But

Posted Oct 8, 2011 19:30 UTC (Sat) by fuhchee (guest, #40059) [Link] (1 responses)

"till it requires no kernel patches"

I assume you're referring to utrace/uprobes. Yes, only probing general user-space requires these, and we can hardly wait until these are mainstream.

"and everything is in the mainline kernel"

If you're repeating the previous point, ok.
If you're suggesting that a tool must be distributed within the kernel tree in order to be useful, then considerable experience says otherwise.

But

Posted Oct 8, 2011 19:59 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Yes. Utrace/uprobes need to be merged. It doesn't matter much where the user space tool lives.

But

Posted Oct 10, 2011 4:20 UTC (Mon) by cmccabe (guest, #60281) [Link] (1 responses)

> Just what does dtrace do that SystemTap can't (yet) do?

There's a comparison of the 4 horses in this race at:
http://sourceware.org/systemtap/wiki/SystemtapDtraceCompa...

It's worth noting that perf isn't really comparable to the other 3 systems because it has a lot more peformance impact. It's really intended more for profiling than for running in production.

Also, LTT-ng and DTrace are not in mainline.

But

Posted Oct 25, 2011 21:36 UTC (Tue) by oak (guest, #2786) [Link]

Regarding LTTng, I think this is the most significant thing in the comparison:
"provides analysis tools to navigate in large multi-GB traces"

With LTTng you can profile "everything" happening in the system with pretty low overhead, i.e. when you still aren't sure what exactly is causing the issues. The others are intended for more targeted tracing where you often write your own script to trace things.

On other platforms than x86, one Systemtap issue is that it relies completely on kprobes instruction emulation to be correct. There were a lot of issues in that e.g. on ARM which have been only recently corrected.

But

Posted Oct 10, 2011 18:18 UTC (Mon) by khc (guest, #45209) [Link]

Work? I tried to evaluate it a while ago (FC15 beta, so it wasn't THAT long ago) but I hit kernel panic whenever I try to put load on it (a heavily multi-threaded program). The redhat guys I chatted with on IRC were really helpful and fixed some issues (but not all), but I didn't have time to pursuit further.

A coworker ported our code to Solaris and dtrace hasn't had a problem with it yet. The situation is not ideal as we actually ship on Linux, but we only use tracing internally now so it's not too big of a deal.