If I'm not mistaken, thread_reaper() is created during system boot by a
call to thread_create. It then lives forever in the system until it is
shut down.
Thus the entry probe will only ever be fired once during the kernel
initialisation, and by the time you run your dtrace script,
thread_reaper:entry has long gone.
Take a look at the code at
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/disp/thread.c#896
and you'll see a big "for (;;)" loop.
Try a probe on thread_reap_list:entry (which is called twice on each
iteration) and see if that gives you any output.
Whether or not the output is any good or usable is up to you ... and
note the :entry specifier too to avoid duplicating your output by
including the return probe.
However, from your description of the way the program works, I'm not
sure the thread_reaper code is the right place to be looking at anyway.
I would doubt that normally exiting threads end up on thread_deathrow
(which is what thread_reaper looks at). I could be wrong... :-)
Regards,
Brian
Thomas Blank wrote:
Hi all,
I want to trace the thread_reaper and want to find out, how often it runs and
how many threads it really reaps.
I use this one-liner in the first step:
[r...@itotcsol104 bin]# dtrace -n 'fbt:genunix:thread_reaper: { @num[probefunc]
= count(); }'
dtrace: description 'fbt:genunix:thread_reaper: ' matched 1 probe
^C
During the run there were created about 40,000 threads - the threads exit
immediately after their work. I monitored the number of threads with the
nthread macro of mdb.
The mentioned dtrace script ran during the whole test and ~10 minutes
afterwards, but I do not get any output from it.
What am I doing wrong? Can anybody help me out with this?
Thanks for your help! Thomas
--
Brian Ruthven
Solaris Revenue Product Engineering
Sun Microsystems UK
Sparc House, Guillemont Park, Camberley, GU17 9QG
_______________________________________________
opensolaris-discuss mailing list
[email protected]
