Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Feb 2014 21:26:37 +0100
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org>
Subject:   Re: What is the precision arg for callout_reset_sbt() and friends?
Message-ID:  <20140221202637.GC5118@onelab2.iet.unipi.it>
In-Reply-To: <1393003465.1145.111.camel@revolution.hippie.lan>
References:  <1393003465.1145.111.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 21, 2014 at 10:24:25AM -0700, Ian Lepore wrote:
> I can't figure out from the code or the manpage what should be passed as
> the precision argument to the sleep-related functions that take sbintime
> values.  It seems like most existing code passes 0, what effect does
> that have?  What should I pass if precision really matters?  What if it
> doesn't matter at all?

I was one of the people suggesting the addition of a 'precision'
argument, the intent being to use it as a hint to help merge events
and reduce the number of timer interrupts.

Since pre-existing APIs did not have this parameter we
used 0 when translating from the old to the new one.
If you write something new of course you can express your needs
as you suggest below.

In practice i think the following issues partly reduce the
usefulness of the parameter:
- there is no way to express a precision from userspace so
  anything using select/poll/kqueue will end up with
  the 'standard' argument;
- with large intervals, aggregation is not really a concern:
  events are likely to be scattered (so little chance of merging)
  and probably infrequent (so little gain from merging)
- with short periodic intervals (where merging might save
  something), applications would prefer 
  if the interval is reasonably accurate and has no drift.
  So I would expect to see a lot of precision=0 in clients
  of this type.
- the implementation, for a delay D and precision P, seems
  to schedule a timeout after D+P unless one exists already
  in the interval D..D+P. This increases the chance of merging
  but is annoying for applications.

I think we should do it differently i.e.:

  if nothing is scheduled in D..D+P then schedule a timeout
  after D (and not D+P). Then, in the data structure we should
  (hopefully it is already like this) keep both D and P so
  when we grab the next event from the timeout queue, we try
  to set the timer to a value that includes the largest number
  of intervals, using one of the D_i values (so that at
  least someone will get it close to the request).

This might require a slightly different data structure than
the timing wheel/heap or whatever is used now as a backend.

cheers
luigi

> Most of the time I want something like a 1ms timeout where it really
> isn't critical if it turns into 2 or even 5ms.  Other times when I say
> 1ms I really want something close to 1ms.
> 
> -- Ian
> 
> 
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140221202637.GC5118>