This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: stpd issues
On Mon, 2005-08-22 at 14:23 -0400, Frank Ch. Eigler wrote:
> Yes, over an open-ended probe session. What's interesting is to
> examine the traffic near the moment of shutdown. This indirect
> recursion is already nipped in the bud at some point, since one can
> terminate even such sys_read-tracing probe sessions. The hangs that
> sometimes occur should be found and fixed.
Oh. I fixed that right away. (probe_exit() was called when the buffers
were full, due to looping IO, and it needs to wait for free buffers).
It will be in CVS real soon.
> > I'm going to check in a change to not print data generated by stpd. You
> > could still collect statistics on it.
>
> How about these alternatives, some of which may be equivalent to those
> you already listed:
>
> - have stpd not repeat a read() right away, so as to let a queue build
> up on the kernel side
>
> - don't flush/wake_up_interruptible from the kernel side so frequently,
> to let multiple probes accumulate output
Those won't work because the queued buffers are not aggregated and will
each need to be read. Aggregating the buffers will solve the problem
without having to do those steps. This is why relayfs doesnt have the
same problem.
--
It seems we have 3 issues here.
1. The test case did not print out the data from the exit probe and
appeared to hang. Fixed. will be in cvs soon.
2. How do we stop infinite loops on output?
3. What do we do about probing functions used by systemtap (mainly
stpd)?