Re: DTrace for FreeBSD - fbt output

From: John Baldwin <jhb_at_freebsd.org>
Date: Wed, 14 Jun 2006 11:36:24 -0400
On Wednesday 14 June 2006 10:20, John Baldwin wrote:
> On Tuesday 13 June 2006 17:36, John Birrell wrote:
> > On Tue, Jun 13, 2006 at 02:15:43AM +0000, John Birrell wrote:
> > > With the development as it stands at the moment, take care using the FBT
> > > provider because you can easily cause the system to go kaboom. I'm still
> > > trying to track down the problems there. It's not in FBT itself -- just
> > > the fact that the DTrace probe context isn't allowed to call anything 
that
> > > FBT can instrument. If that happens you will either get a reboot or a
> > > double fault will leave you in kdb. I recommend only enabling a few FBT
> > > probes at a time just so you know which ones could cause a fault. There 
is
> > > no point telling me that you enabled fbt::: and the system went kaboom!
> > 
> > With the FBT provider as it now stands and using this script:
> > 
> > fbt:::entry
> > {
> >         _at_[probefunc] = count();
> > }
> > 
> > the output after a buildworld is listed below. Check out the number of
> > calls to critical_enter and critical_exit (which are listed at the 
bottom)!
> > And for comparison, check the hardclock() count which relects 1000 Hz.
> 
> Those functions are called a lot as every spinlock ends up calling them
> (including sched_lock, turnstile chain locks, sleepqueue locks, etc.)

Also, WITNESS has its own internal spinlock that is acquired and released
on every mutex, rwlock, or sx lock operation, and each of those 
acquire/release pairs would constitute a critical_enter/exit pair, so you 
really should run with WITNESS off to get a sense of how often critical_* is 
really called.

-- 
John Baldwin
Received on Wed Jun 14 2006 - 13:38:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:57 UTC