lkml.org 
[lkml]   [2006]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: select takes too much time
    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 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/

    \
     
     \ /
      Last update: 2006-04-13 17:33    [W:3.963 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site