lkml.org 
[lkml]   [2007]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: sched_yield proposals/rationale
    On Thu, Apr 12, 2007 at 03:31:31PM +0200, Andi Kleen wrote:
    > The only way I could think of to make sched_yield work the way they
    > expect would be to define some way of gang scheduling and give
    > sched_yield semantics that it preferably yields to other members
    > of the gang.
    > But it would be still hard to get these semantics (how to define
    > the gangs) into your uncontrollable broken applications and also
    > it has the risk of either unfairness or not full utilization of the
    > machine. Getting it to scale well on MP systems would be also likely
    > a challenge.

    Gang scheduling isn't a squishy concept whose name can be arbitrarily
    repurposed. Perhaps "group scheduling" or similar would be appropriate
    if the standard gang scheduling semantics are not what you have in mind.

    Standard gang scheduling would not be appropriate for applications that
    don't know what they're doing. All threads of a gang falling asleep
    when one sleeps (or more properly, the gang is considered either
    runnable or unrunnable as a unit) is not to be taken lightly.

    I'd call this something like a "directed yield with a group as a target,"
    but I wouldn't actually try to do this. I'd try to provide ways for a
    directed yield to donate remaining timeslice and dynamic priority if
    possible to a particular task associated with a resource, for instance,
    a futex or SysV semaphore owner. The priority inversion one desperately
    wants to avoid is the resource owner running out of timeslice or
    otherwise losing priority to where it falls behind busywaiters such as
    callers of sched_yield for the purposes of multitier locking.


    -- wli
    -
    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: 2007-04-12 23:39    [W:3.243 / U:0.356 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site