Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jun 2006 21:52:38 +1000
From:      Sam Lawrance <boris@brooknet.com.au>
To:        John Birrell <jb@what-creek.com>
Cc:        Robert Watson <rwatson@freebsd.org>, current@freebsd.org
Subject:   Re: DTrace for FreeBSD - fbt output
Message-ID:  <E347CB49-0220-4E98-B474-1CBB98263051@brooknet.com.au>
In-Reply-To: <20060614095449.GA82424@what-creek.com>
References:  <20060613021543.GA71283@what-creek.com> <20060613213617.GA78337@what-creek.com> <20060614103614.Y34121@fledge.watson.org> <20060614095449.GA82424@what-creek.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E347CB49-0220-4E98-B474-1CBB98263051>