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: stpd issues


Hi -

hunt wrote:

> [...]
> >  In particular, the "... which causes stpd ..."  step is
> > indirect, time-wise separated from the probe event.
> 
> So instead of crashing due to using all the stack on recursion, we just
> generate infinite output. [...]

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.


> 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


- FChE


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