lkml.org 
[lkml]   [2012]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] hrtimers: Special-case zero length sleeps
    On Wed, 15 Feb 2012, Matthew Garrett wrote:

    > On Wed, Feb 15, 2012 at 03:40:24PM +0100, Thomas Gleixner wrote:
    > > > + * be scheduled. Special case that to avoid actually putting them
    > > > + * to sleep for the duration of the slack.
    > > > + */
    > > > + if (rqtp->tv_sec == 0 && rqtp->tv_nsec == 0)
    > > > + slack = 0;
    > >
    > > That's pretty pointless. You can simply return 0 here as
    > > do_nanosleep() will not call the scheduler on an already expired
    > > timer, which is always true for a relative timer with delta 0.
    >
    > I'm actually starting to wonder about the applications doing this. We
    > default to adding a small amount of slack even if the application has
    > done sleep(0), which will mean that the timer hasn't expired at this
    > point. Do we then go through the scheduler differently? Are these

    When the slack is large enough that the timer is actually not expired
    right away, which is usually the case, then we end up in schedule()
    and the task gets scheduled out until the timer fires. With your
    approach of making the slack 0 for sleep(0) calls the code does not
    call schedule() because the timer is definitely expired.

    > applications actually relying on an invalid assumption?

    Oh yes. sleep(0) has no guarantee about its behaviour at all. The only
    guarantee of sleep() is that it wont return before the requested time
    has elapsed, but there is no upper bound when it returns after the
    sleep time is over. So it's perfectly fine from the standards POV that
    sleep(0) actually sleeps and puts the tasks for some random time away.
    It's also correct when it returns right away w/o going through
    schedule(). The fact that sleep(0) ended up in schedule() even when
    the timer was already and the task state therefor was RUNNING on some
    unix implementations does not change that at all.

    Just for the extended fun of it: The pre hrtimer implementation in
    Linux put the task on sleep as well up to the next jiffies boundary,
    so anything which used sleep(0) on a pre hrtimer kernel was going to
    sleep. That's also the case today when high resolution timers are
    disabled (compile or runtime).

    So anything which relies on sleep(0) as a fast scheduling point is and
    has been broken forever.

    Thanks,

    tglx


    \
     
     \ /
      Last update: 2012-02-15 21:17    [W:0.022 / U:30.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site