This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: stpd issues
Hi -
hunt wrote:
> [...] 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.
Great.
> [...]
> > 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.
But if those stpd reads produce more than one buffer at a time, then
the "recursive" trace record should be in the minority.
> Aggregating the buffers will solve the problem without having to do
> those steps. This is why relayfs doesnt have the same problem.
Letting more _stp_buffer list entries accumulate in _stp_write, and/or
copying more than one message per librelay read() loop iteration could
also accomplish this.
> [...]
> 2. How do we stop infinite loops on output?
> 3. What do we do about probing functions used by systemtap (mainly
> stpd)?
How are these two concerns separate? In what scenario have you
imagined anything "infinite" occurring, other than "recursive"
tracing?
- FChE