[dtrace-discuss] dtrace wired issue

Aubrey Li
Mon, 14 Jan 2008 13:28:19 -0000

On Jan 14, 2008 9:26 PM, Aubrey Li <aubreylee at gmail.com>
wrote:
>
> On Jan 14, 2008 9:22 PM, James C. McPherson <James.McPherson at
sun.com> wrote:
> > Aubrey Li wrote:
> > > On Jan 14, 2008 8:52 PM, Sean McGrath - Sun Microsystems Ireland
> > > <sean.mcgrath at sun.com> wrote:
> > >> Aubrey Li stated:
> > >> < Every first time to run dtrace command after the system
boot up,
> > >> < It takes a very long time to get response.
> > >> < But the second time is OK, as follows:
> > >> <
> > >> < # time dtrace -l > /dev/null
> > >> <
> > >> < real    4m8.011s
> > >> < user    0m0.116s
> > >> < sys     0m2.420s
> > >>
> > >>   This first time is probably when the kernel is loading the
dtrace modules.
> > >>   Though still seems slow, 4 minutes.
> > >>     What kind of system (cpu speed etc) is the machine ?
> > >
> > > # psrinfo -vp
> > > The physical processor has 2 virtual processors (0 1)
> > >   x86 (GenuineIntel 10674 family 6 model 23 step 4 clock 2400
MHz)
> > >         Intel(r) CPU                  @ 2.40GHz
> > >
> > > So, I failed to understand the modules loading needs 4 minutes.
> >
> >
> > If you run "dtrace -l" with no args, *every* single loadable
> > module on the system will be loaded, interrogated by dtrace
> > and then unloaded if possible.
> >
> > All those attach()es and detach()es need time, as does the
> > probe collation.
> >
> So may I ask, how long "dtrace -l" get response on your system?
> And how fast the cpu speed on your system?
>
> 4 minutes, it is absolutely acceptable for me.
>
err, sorry, I mean unacceptable, ;-)

-Aubrey