Hi,
On Thu, Apr 13, 2006 at 10:01:04AM -0500, Ram Gupta wrote:
> I am using select with a timeout value of 90 ms. But for some reason
> occasionally it comes out of select after more than one second . I
> checked the man page but it does not help in concluding if this is ok
> or not. Is this expected or it is a bug. Most of this time is
> consumed in schedule_timeout . I am using 2.5.45 kernel but I
> believe the same would be the true for the latest kernel too. Any
> thoughts or suggestion are welcome.
AFAIK (I'm not an absolute expert on this, but it should be about correct):
Any user of select() competes with all other processes on the system
for the attention of the scheduler. If there are always runnable tasks
available with a higher priority than the select() user, then it's easily
imaginable that those tasks get woken up and/or will be kept running first.
The timeout value given to select() thus states the *minimum* time that
the process will continue after if the timeout has been fully taken (i.e.
no event occurred).
The man page of select() is a bit inaccurate in saying that "it will return
immediately". Well, it will *try to* return ASAP once it has decided to
return. BUT the scheduler will *always* have ultimate authority upon when
*exactly* this process will be allowed to continue.
Now if you have issues with select() taking too long, then I'd say tough
luck, that's life, other processes seem more important than your select()
user, but OTOH it could mean that our scheduler design is not assigning
enough importance to processes waiting on a select() and becoming runnable
again (however I strongly doubt that, since there has gone a LOT of work into
proper scheduler design in Linux).
Or, to put it differently, select() doesn't have realtime guarantees, i.e.
there's no way for you to boldly assume that once select() times out
your process will continue to run instantly within microseconds.
Finally, *any* scheduling timeout on a system should be taken for granted
as a *minimum* guarantee only. This is also why looped msleep()s in
Linux drivers should very often be coupled with a jiffies timeout condition
just in case the system is so extremely busy that each msleep(1) takes up
3 seconds, thus letting a 300 times 1ms loop end up as 900 seconds instead...
Whoa, way too many words for answering such a basic issue...
(but this problem being so basic it probably cannot be explained too often)
Oh, and another related word of advice: when doing thread programming,
always synchronize parallel threads by letting them *block* on each others
status instead of letting the peer thread busy-loop for the other thread to
finish its work. Good schedulers *will* punish busy-looping and honour
proper blocking on a condition, so your software will suffer a lot when
doing too much busy-looping or semi-busy-looping (too many useless wakeups).
Andreas Mohr
--
Please consider not buying any HDTV hardware! (extremely anti-consumer)
Bitte kaufen Sie besser keinerlei HDTV-Geräte! (extrem verbraucherfeindlich)
Infos:
http://www.hdboycott.com http://www.eff.org/IP/DRM/ http://bluraysucks.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
