dtrace discuss - Jul 2009 - why system() takes so long? (using dtrace to synchronize kernel event with userland process)

Hi,

I am trying to develop easily reproducible testcase creating a 4-way 
hang in the NFS client.
One subtask I am solving is to synchronize two events:

1) asynchronous kernel event (the action is triggered from the NFS server)
2) start of a system call in userland process



One of the possibility to synchronize it, is to let the dtrace probe to 
send a signal to the user land process via a system() action.

As an example, I have tried sending signal to a pid 9999 whenever probe 
''nfs4_write:entry'' is hit:

dtrace -w -n ''genunix:kill:entry{trace(timestamp)}''  -n 
''nfs4_write:entry{ system("kill 99999");
trace(timestamp)}''



# CPU     ID                    FUNCTION:NAME
  1  60644                 nfs4_write:entry sh: kill: no such process
    5372337061331
  2  18234                       kill:entry     5373011617501

The problem is that the delay between the event (nfs probe) and the 
signal delivery is almost 1 second.
That is too much for my tests.


# echo 5373011617501-5372337061331 | bc
674556170     ### It is 674 miliseconds


 Can be the delivery of the signal done faster (less than 100 ms) by 
some tuning?


Thanks,
Pavel

On Thu, Jul 30, 2009 at 3:48 PM, Pavel
Filipensky<Pavel.Filipensky at sun.com> wrote:
>
[ ... ]
> One of the possibility to synchronize it, is to let the dtrace probe to
send
> a signal to the user land process via a system() action.
>
[ ... ]
>
> The problem is that the delay between the event (nfs probe) and the signal
> delivery is almost 1 second.
> That is too much for my tests.
>
>
> # echo 5373011617501-5372337061331 | bc
> 674556170 ? ? ### It is 674 miliseconds
>
>
> Can be the delivery of the signal done faster (less than 100 ms) by some
> tuning?
The system() doesn''t happen when the probe fires but rather when the
data are consumed.  You can set the "switchrate" option to make the
data consumption happen more frequently.

Chad

On 07/30/09 22:13, Chad Mynhier wrote:
> On Thu, Jul 30, 2009 at 3:48 PM, Pavel
> Filipensky<Pavel.Filipensky at sun.com> wrote:
>   
> [ ... ]
>   
>> One of the possibility to synchronize it, is to let the dtrace probe to
send
>> a signal to the user land process via a system() action.
>>
>>     
> [ ... ]
>   
>> The problem is that the delay between the event (nfs probe) and the
signal
>> delivery is almost 1 second.
>> That is too much for my tests.
>>
>>
>> # echo 5373011617501-5372337061331 | bc
>> 674556170     ### It is 674 miliseconds
>>
>>
>> Can be the delivery of the signal done faster (less than 100 ms) by
some
>> tuning?
>>     
>
> The system() doesn''t happen when the probe fires but rather when
the
> data are consumed.  You can set the "switchrate" option to make
the
> data consumption happen more frequently.
>
> Chad
>   
Thanks Chad,

10hz switchrate gives me 28 ms instead of 674 ms:

dtrace -x switchrate=10hz -w -n
''genunix:kill:entry{trace(timestamp)}''
-n ''nfs4_write:entry{system("kill
99999");trace(timestamp)}''


--Pavel

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20090730/66941800/attachment.html>