Re: stpd issues

["Frank Ch. Eigler" <fche at redhat dot com>]

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