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

[Eugene Loh]

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?

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 */
>