User: Password:
|
|
Subscribe / Log in / New account

High- (but not too high-) resolution timeouts

High- (but not too high-) resolution timeouts

Posted Sep 4, 2008 5:08 UTC (Thu) by njs (guest, #40338)
Parent article: High- (but not too high-) resolution timeouts

AFAICT there is no way to set a lower bound on accuracy (i.e., "no really, I *meant* that timespec"), which might be useful for realtime work.

Squinting at the code, I think the constants in the accuracy heuristic are actually ok for the soft-realtime case that I happen to care about. It seems safer to use timerfd for RT poll timeouts, though -- it seems to keep full accuracy (though perhaps that's a bug!).


(Log in to post comments)

High- (but not too high-) resolution timeouts

Posted Sep 4, 2008 13:15 UTC (Thu) by arjan (subscriber, #36785) [Link]

it's a hard complex problem; the only real solution is to have a pppoll syscall that takes explicit slack as argument, for those people who really need that 10 second sleep with 1 nanosecond accuracy.

I can't say that I'm happy about the "estimate how big the slack is" function, but I've not been able to come up with something significantly nicer that still works well (where "works well" includes just doing the right thing for power saving). I was hoping others on lkml would have better ideas but so far it seems it's a hard problem, where the best I've seen so far is "just use 0.1% of the total delay".

High- (but not too high-) resolution timeouts

Posted Sep 4, 2008 18:34 UTC (Thu) by dcoutts (guest, #5387) [Link]

How about people who need the really high accuracy use the timerfd() and insert that timer into their poll/epoll/select set and then give no timeout when they wait on that event set. That way, the highly accurate timers can be used while letting all the ordinary stuff use the existing mechanism that saves power by waking everyone up at the same time etc.

High- (but not too high-) resolution timeouts

Posted Sep 4, 2008 21:09 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

Good idea! Why not post this to linux-kernel?

High- (but not too high-) resolution timeouts

Posted Sep 5, 2008 5:02 UTC (Fri) by njs (guest, #40338) [Link]

It might be sufficient to just disable the heuristic when the thread making the syscall has real-time priority. Don't know if that's the Perfect Answer, but I think it would be an incremental improvement at least.

I don't much like the idea of making this an undocumented difference between different timing syscalls (like someone else suggested), so that if you use ppoll you get one thing and timerfd another etc. -- I don't see why timerfd should be useful only to apps who need precision and don't care about power! Really the behavior should be uniform across ppoll/poll/pselect/select, epoll, timerfd, nanosleep, posix timers, interval timers. (Not sure if all of those use hrtimers yet; I know nanosleep and posix timers do in -rt.)

For timerfd in particular, one could add a timerfd_setslack call without breaking compatibility. It might be possible for some of those other APIs as well.

High- (but not too high-) resolution timeouts

Posted Sep 5, 2008 5:24 UTC (Fri) by arjan (subscriber, #36785) [Link]

the realtime thing is there already in my current codebase

right now what I do is (in summary)

if realtime => slack is 0

if nice, slack is 0.5% with a max of 100 msec
if not nice, slack is 0.1% with a max of 100 msec
if not rt and slack is less than the per thread setting, use the per thread setting


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds