This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why systemtap loses events and what can be done about it?


Hi -

<zzh@ncic.ac.cn> wrote:
> [... code trimmed ...]
> #a hash array to remember the end-point pair , the key is tid() and the
> value is "send_ip:send_port-receive_ip:receive_port"
> global str_sock 
> probe tcp.recvmsg
> {
>    if (   check_filter() ==0 ) next
>    str_sock[tid()] = get_sock_addr(sock)
> }
> 
> probe tcp.recvmsg.return
> {
>     if( check_filter()==0 ) next
>     report( "RECEIVE RETURN", size,  str_sock[tid()] )
> }

> My question is whether the global str_sock will be reentrant?

The global will be write-locked during the entry probe and read-locked
during the return probe.  In case of a great deal of contention across
the CPUs, some probe handlers may be skipped because of that.  There
is not much one can do for this.  Try not to share globals between too
many probes that may fire concurrently.  (This is one aspect where
dtrace gets it done better than we do.  We don't have pure per-thread
global variables that can be accessed without locking.)

In addition, you're using .return probes, which may on their own cause
a skip sometimes.  For raw low-level .function().return probes, one
can add a ".maxactive(1000)" probe point suffix to enlarge one
parameter that, if too small, can lead to skipping.  (You'd have to
map 'tcp.recvmsg' to 'kernel.function("tcp_recvmsg")' and access the
context variables directly with $this and $that.  We should try to
improve on this.)


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]