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