[lkml]   [2003]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: must-fix list for 2.6.0
        The below patch should fix that up, but we need to decide whether
    the (rather unclear) advantages of the sched_yield() change outweigh
    the breakage which it caused linuxthreads applications.

    Exactly right; we've gone back and forth on this a few times. What fixes
    one seems to break the other. Hubertus Franke (
    has been trying to reply with this succinct summary of
    advantages/disadvantages but is having some sort of DNS issues right now so
    I'll post it for him:

    This goes back to the semantics of sched_yield().

    OLD: when sched_yield() is called the task moves to expired,
    every other task in the active queue will run first before the
    yielding task will run again.

    NEW: move the yielding task to the end of its current priority level,
    but keeps it active not expired.

    Why is this good?
    (a) the task will not loose its timeslice length, because moving it to
    expired effectively does that.
    (b) it keeps the task responsive

    Why is this bad?
    (a) if it does busy looping through sched_yield it will eat cycles which
    might not have happened

    What else could be done?
    (a) drop the effective priority of the yielding task by a percentile,
    but don't reduce the time slice!

    Hubertus Franke
    (w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:35    [W:0.020 / U:3.508 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site