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:
[root at 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
--
This message posted from opensolaris.org
Hi Thomas,> 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: > [root at 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?The thread_reaper thread is created early on in the boot process and runs in perpetuity, therefore you won''t see its entry or return probes fired. It gets kicked into life whenever there are a bunch of threads ready to be reaped. A very simple approach would be to look at when thread_free() is called from thread_reap_list() as in the example below. Your best bet is to check out the code and follow it through. Someone with more knowledge of this area may have a better approach. #!/usr/sbin/dtrace -qs thread_reap_list:entry { self->in = 1; } thread_free:entry /self->in/ { @["threads reaped"] = count(); } thread_reap_list:return /self->in/ { self->in = 0; } Jon.
Hi Jon, hi Brian, thank you both very much for your quick and detailed responses. Jon, the code you sent me is exactly what I was looking for! I added some probes to have some more information.> 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.This was my fault... Best regards, Thomas -- This message posted from opensolaris.org