lkml.org 
[lkml]   [2007]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: sched_yield: delete sysctl_sched_compat_yield
    David Schwartz wrote:
    > I've asked versions of this question at least three times and never gotten
    > anything approaching a straight answer:
    >
    > 1) What is the current default 'sched_yield' behavior?
    >
    > 2) What is the current alternate 'sched_yield' behavior?

    I'm pretty sure I've seen responses from Ingo describing this multiple
    times in various threads. Google should have them.

    If I remember right, the default is to simply recalculate the task's
    position in the tree and reinsert it, and the alternate is to yield to
    everything currently runnable.

    > 3) Are either of them sensible? Simply acting as if the current thread's
    > timeslice was up should be sufficient.

    The new scheduler doesn't really have a concept of "timeslice". This is
    one of the core problems with determining what to do on sched_yield().

    > The implication I keep getting is that neither the default behavior nor the
    > alternate behavior are sensible. What is so hard about simply scheduling the
    > next thread?

    The problem is where do we insert the task that is yielding? CFS is
    based around a tree structure ordered by time.

    The old scheduler was priority-based, so you could essentially yield to
    everyone of the same niceness level.

    With the new scheduler, this would be possible, but would involve extra
    work tracking the position of the rightmost task at each priority level.
    This additional overhead is what Ingo is trying to avoid.

    > We don't need perfection, but it sounds like we have two alternatives of
    > which neither is sensible.

    sched_yield() isn't a great API. It just says to delay the task,
    without specifying how long or what the task is waiting *for*. Other
    constructs are much more useful because they give the scheduler more
    information with which to make a decision.

    Chris


    \
     
     \ /
      Last update: 2007-12-03 18:41    [W:5.663 / U:0.292 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site