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>