DTrace for FreeBSD - fbt output
Sam Lawrance
boris at brooknet.com.au
Wed Jun 14 11:52:48 UTC 2006
On 14/06/2006, at 7:54 PM, John Birrell wrote:
> On Wed, Jun 14, 2006 at 10:39:14AM +0100, Robert Watson wrote:
>> I don't suppose it's possible to get stack traces or fractional stack
>> traces (last 2-3 frames)? There are a number of comon consumers of
>> critical sections, but the number does seem inordinately high,
>> especially
>> with respect to the number of calls of the common consumers.
>> Critical
>> sections are acquired during access to per-cpu caches in UMA, and for
>> per-cpu stats in malloc(9), as well as in context switches and in
>> interrupts.
>
> DTrace has stack access actions. I still need to work on porting them,
> but walking up the stack is very much something that DTrace needs to
> do.
>
>> BTW, it looks like the below is running with invariants turned
>> on? It may
>> be more interesting to run the below without invariants, since
>> invariants
>> significantly changes the behavior of the memory allocation paths
>> due to
>> memory trashing and additional bookkeeping.
>
> Yes, I have both invariants and witness turned on because they
> present the
> difficult case with respect to function recursion. If I innocently
> call
> functions from the DTrace probe context which turn out to call other
> non-dtrace-legal functions which can be, themselves, instrumented
> by FBT,
> a probe can crash the system. Witness often ends in tears at the
> moment. 8-(
I suppose that's the reason why actions like raise() and stop() are
invoked by setting t_dtrace_sig and t_dtrace_stop - because it allows
the resulting probes to be correctly instrumented.
More information about the freebsd-current
mailing list