[DTrace-devel] [PATCH 1/5] consume: fix epoll_wait() timeut

[Kris Van Hees]

On Mon, May 01, 2023 at 05:58:20PM -0400, Eugene Loh via DTrace-devel wrote:
> subject line: s/timeut/timeout/
> commit msg: s/swotchrate/switchrate/
> 
> But I'm confused.  I understand the problem, but not the solution.  We
> throttle between epolls using two mechanisms.  One is a spin wait:  the
> dtrace_work() loop in dtrace.  Another is the blocking timeout in
> epoll_wait().  I get that we should not use both.  But the proposed fix
> means that we are relying only on the spin wait, while default behavior
> would be to rely only the epoll blocking timeout.  The documentation seems
> to imply that the default is 1s.  But with this patch the default behavior
> would be a 1-sec epoll timeout while explicitly setting the switchrate would
> be a pure spin wait.  The two have slightly different behaviors.
> 
> Why should switchrate=1s behave differently from the default?

Well, in a sense, we do need two mechanisms that work together because there
are multiple things going on.  I agree that the solution in this patch is a
bit too harsh (and that is because I completely forgot that we no longer use
dtrace_sleep() and therefore indeed end up with a tight spin loop).

I'm looking at some alternatives...  The challenge is that we need to be able
to space status and buffer retrievals (for principal and aggregations) while
still also needing to wait for notifications from e.g. proc handlers.

Let me take a closer look at how to handle this better.

> On 5/1/23 15:47, Kris Van Hees via DTrace-devel wrote:
> 
> > If swotchrate was set to a value other than zero, we could end up with
> > a double delay between two buffer polls because first the switchrate
> > value was used to enforce a delay between two consecutive polls *and*
> > we would pass the switchrate value to epoll_wait() as timeout.
> > 
> > Setting the interval to 0 after switchrate has been used to space the
> > polls ensures that the epoll_wait() won't cause any further delay.
> > 
> > If switchrate is not used (it is 0), then we still need the interval
> > to be 1s to provide a timeout for epoll_wait().
> > 
> > Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
> > ---
> >   libdtrace/dt_consume.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/libdtrace/dt_consume.c b/libdtrace/dt_consume.c
> > index d628ff21..0f3c0691 100644
> > --- a/libdtrace/dt_consume.c
> > +++ b/libdtrace/dt_consume.c
> > @@ -3032,6 +3032,8 @@ dtrace_consume(dtrace_hdl_t *dtp, FILE *fp, dtrace_consume_probe_f *pf,
> >   			dtp->dt_lastswitch += interval;
> >   		} else
> >   			dtp->dt_lastswitch = now;
> > +
> > +		interval  = 0;
> >   	} else
> >   		interval = NANOSEC;			/* 1s */
> 
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel