This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Why systemtap loses events and what can be done about it?
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: zzh at ncic dot ac dot cn
- Cc: systemtap at sources dot redhat dot com
- Date: Fri, 31 Aug 2007 07:28:02 -0400
- Subject: Re: Why systemtap loses events and what can be done about it?
- References: <20070831035838.GA891@redhat.com> <0BA153E53BAB4759BC9DD0573C95DA53@ncicdcos>
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