dtrace discuss - Apr 2007 - DTrace probes for exiting processes

Hello DTracers,

I was running a script similar to the following:

#!/usr/sbin/dtrace -s

proc:::exec-success
/curpsinfo->pr_projid == $1/
{
	self->ts = timestamp;
}

syscall::rexit*:entry
/self->ts/
{
	...
	self->ts = 0;
}

recording a bunch of information on process exit. It was working fine. I run
this script to track ON build which creates huge amount of short-lived projects.

Later I changed syscall::rexit*:entry to proc:::exit probe which fires at the
beginning of proc_exit(). Suddenly I saw a large number of dynamic variable
drops with non-empty dirty list.

Any idea why moving probes close to process changes things?

- akolb

I can''t say for sure, but there''s no guarantee that you exit
from the
initial thread in which case this script will incur dynamic variable
leakage. Try a global associative array indexed by pid.

Adam

On Wed, Apr 11, 2007 at 02:29:13PM -0700, Alexander Kolbasov
wrote:
> Hello DTracers,
> 
> I was running a script similar to the following:
> 
> #!/usr/sbin/dtrace -s
> 
> proc:::exec-success
> /curpsinfo->pr_projid == $1/
> {
> 	self->ts = timestamp;
> }
> 
> syscall::rexit*:entry
> /self->ts/
> {
> 	...
> 	self->ts = 0;
> }
> 
> recording a bunch of information on process exit. It was working fine. I
run
> this script to track ON build which creates huge amount of short-lived
projects.
> 
> Later I changed syscall::rexit*:entry to proc:::exit probe which fires at
the
> beginning of proc_exit(). Suddenly I saw a large number of dynamic variable
> drops with non-empty dirty list.
> 
> Any idea why moving probes close to process changes things?
> 
> - akolb
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

>>>>> "Adam" == Adam Leventhal <ahl at
eng.sun.com> writes:

    Adam> I can''t say for sure, but there''s no guarantee
that you exit from the
    Adam> initial thread in which case this script will incur dynamic
variable
    Adam> leakage. Try a global associative array indexed by pid.

I thought about it, but majority of processes are single threaded. Anyway, I
tried this - with the same result. It seems that rexit() just calls exit() which
calls proc_exit() right away. The only reason we would skip proc:::exit probe is
if exitlwps(0) fails which is strange since I don''t expect to see much
of
multi-threaded processes there. 

I''ll add some code to check for exitlwps() fails.

- akolb

    Adam> Adam

    Adam> On Wed, Apr 11, 2007 at 02:29:13PM -0700, Alexander Kolbasov wrote:
    >> Hello DTracers,
    >> 
    >> I was running a script similar to the following:
    >> 
    >> #!/usr/sbin/dtrace -s
    >> 
    >> proc:::exec-success
    >> /curpsinfo->pr_projid == $1/
    >> {
    self-> ts = timestamp;
    >> }
    >> 
    >> syscall::rexit*:entry
    >> /self->ts/
    >> {
    >> ...
    self-> ts = 0;
    >> }
    >> 
    >> recording a bunch of information on process exit. It was working
fine. I run
    >> this script to track ON build which creates huge amount of
short-lived projects.
    >> 
    >> Later I changed syscall::rexit*:entry to proc:::exit probe which
fires at the
    >> beginning of proc_exit(). Suddenly I saw a large number of dynamic
variable
    >> drops with non-empty dirty list.
    >> 
    >> Any idea why moving probes close to process exit changes things?
    >> 
    >> - akolb
    >> _______________________________________________
    >> dtrace-discuss mailing list
    >> dtrace-discuss at opensolaris.org

    Adam> -- 
    Adam> Adam Leventhal, Solaris Kernel Development      
http://blogs.sun.com/ahl