DTrace for FreeBSD - fbt output
John Baldwin
jhb at freebsd.org
Wed Jun 14 15:38:09 UTC 2006
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
> > {
> > @[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
More information about the freebsd-current
mailing list