Messages in this thread | | | Date | 23 Jun 2016 09:58:03 -0400 | From | "George Spelvin" <> | Subject | Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel |
| |
Cyril Hrubis wrote: > Thomas Gleixner wrote: >> Err. You know that the timer expired because sigtimedwait() returns >> EAGAIN. And the only thing you can reliably check for is that the timer did >> not expired to early. Anything else is guesswork and voodoo programming.
> But seriously is there a reason > why OS that is not under heavy load cannot expire timers with reasonable > overruns? I.e. if I ask for a second of sleep and expect it to be woken > up not much more than half of a second later?
> If we stick only to guarantees that are defined in POSIX playing music > with mplayer would not be possible since it sleeps in futex() and if it > wakes too late it will fail to fill buffers. In practice this worked > fine for me for years.
Two points: 1) sigtimedwait() is unusual in that it uses the jiffies timer. Most system call timeouts (including specifically the one in FUTEX_WAIT) use the high-resolution timer subsystem, which is a whole different animal with tighter guarantees, and 2) The worst-case error in tglx's proposal is 1/8 of the requested timeout: the wakeup is after 112.5% of the requested time, plus one tick. This is well within your requested accuracy. (For very short timeouts, the "plus one tick" can dominate the percentage error.)
| |