On Jan 11, 2008, at 6:26 PM, Eric Schrock wrote:
On Fri, Jan 11, 2008 at 06:23:14PM -0800, Roman Shaposhnik wrote:
I guess we are talking about two different kinds of generality
here.
What I have in mind is the generality that would allow DTrace to be
able to offload some of the heavylifting to the userspace. I DO
understand the ramifications of that and I know full well that
pushing
DTrace into userspace might be perceived as the deviation from the
original design. To some extent it might even reduce the generality
that you seem to be referring to.
The issue is not one of design, but of the constraints on the problem.
If we are talking about *u*stack, than I disagree with the way you're
setting up constraints. The *u*stack is by definition a userspace
related
operation. Not only that, but calling ustack() is declared void for a
reason.
Calling it changes the output of the DTrace but has no way of affecting
the rest of the DTrace script's internal logic.
DTrace actions must be executed in probe context.
Please don't redefine the problem. We are not talking about arbitrary
actions here.
Heavy lifting can be
done via post-processing in userland (symbol translation, system()
actions, etc), but the data gathering must be done in arbitrary
context.
What data gathering? Could you, please, be more specific? What data
there is that can't be leveraged from the userspace? And again, I'm
talking specifically about ustack() here.
How would you call arbitrary userspace code from, say, an interrupt
handler?
I'm not suggesting that at all. And in fact for Project D-Light we
devised
a mechanism for getting much more accurate stacktraces from userspace
compared to what DTrace is capable of. E.g.:
self uint32_t stkIdx;
collector$1:::ustack
{
printf("0 %d %d %u\n", tid, self->stkIdx++, arg0<<32|
(arg1&0xffffffff));
}
syscall::read:return
/pid == $1/
{
fname = (self->fd == 0 ) ? "<stdin>" : fnames[self->fd];
printf("1 %d %d %d %d \"%s\" %d %d\n",
cpu,
tid,
timestamp,
0,
fname,
arg1,
self->stkIdx);
raise(29);
}
The awkwardness here comes from the fact that we have to:
* make libcollector available in the address space of the process
* use a raise(29) in order to poke userspace instead of
something more
DTrace specific.
Otherwise it works very nice. We get all the benefits of userspace
code:
we can match dlopen/dlclose events and such and our Java stack are
better than jstack().
Thanks,
Roman.
