Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 27 Jan 2003 14:52:36 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: bug in select() (was Re: {sys_,/dev/}epoll waiting timeout) |
| |
On Mon, 27 Jan 2003, Bill Rugolsky Jr. wrote:
> Quite independent of this discussion, my boss came across this today > while looking at some strace output: > > gettimeofday({1043689947, 402580}, NULL) = 0 > select(4, [0], [], [], {1, 999658}) = 0 (Timeout) > gettimeofday({1043689949, 401857}, NULL) = 0 > gettimeofday({1043689949, 401939}, NULL) = 0 > select(4, [0], [], [], {0, 299}) = 0 (Timeout) > gettimeofday({1043689949, 403577}, NULL) = 0 > > Note that 1043689949.401857 - 1043689947.402580 = 1.999277. > > The Single Unix Specification (v2 and v3), says of select(): > > Implementations may also place limitations on the granularity of > timeout intervals. If the requested timeout interval requires a finer > granularity than the implementation supports, the actual timeout > interval shall be rounded up to the next supported value. > > That seems to indicate that a fix is required.
The problem is that the schedule_timeout() is not precise. So if you pass N to such function, your sleep interval can be ]N-1, N+1[ This w/out considering other latencies but looking only at how timers are updated ( you can call schedule_timeout() immediately before a timer tick or immediately after ). So if we want to be sure to sleep at least the rounded up number of jiffies, we might end up sleeping one/two jiffies more ( and this w/out accounting other latencies ). And this will lead to the formula ( used by poll() ) :
Tj = (Tms * HZ + 999) / 1000 + 1
( if Tms > 0 )
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |