> On 7/13/05, Eric Boutilier <Eric.Boutilier at sun.com> wrote:
> >
> > In case not seen, much discussion about DTrace is happening on the
> > following thread on LKML:
>
>
> It would be interesting, to hear feed back from engineers, that worked on
> dtrace on the issues mentioned on the KKML, if anything similar was solved
> allong the way. But i guess it mostly goes to Linux developers life long
> fear of things that exist in kernel space. and we should move heaven and
> earth to make sure we don''t allocate a single byte of extra kernel
space,
> even if i have to re-engeer my app five times to save a byte, and still
left
> with a unstable unscalable solution.
Any feedback we could give them could be easily gleaned by reading the
USENIX paper -- which the vast majority of people on that thread clearly
have not done. And if the USENIX paper left any questions, they could
undoubtedly be answered from either the documentation or the source code.
So I don''t think they''re terribly interested in how DTrace has
solved the
problem, or even what problems DTrace has solved -- they seem to be much
more interested in generating the perception that a "DTrace clone" is
in
the works.
And of course, the irony is that in DTrace the mechanism for transferring
data out of the kernel is pretty basic -- just a copyout(). We did not
develop a "high-speed" mechanism for data transfer, because our view
was
(and is) that whenever your data flow is sufficiently large to merit
such optimization, you probably aren''t using DTrace as well as you
could:
you could be making better use of predicates, aggregations, speculative
tracing, ring buffering, etc. etc. The point is, you need to have the
infrastructure to allow data flow to be pruned and aggregated _at the
source_ -- if you need a mechanism for bulk transfer of tracing data, you
probably haven''t adequately solved the pruning and aggregation
problems...
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc