lkml.org 
[lkml]   [2003]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Linux-ia64] Re: web page on O(1) scheduler
    At 06:12 PM 5/28/2003 -0400, Bill Davidsen wrote:
    >On Wed, 21 May 2003, Olivier Galibert wrote:
    >
    > > On Wed, May 21, 2003 at 03:12:12PM +0200, Arjan van de Ven wrote:
    > > > if you had spent the time you spent on this colorful graphic on reading
    > > > SUS or Posix about what sched_yield() means, you would actually have
    > > > learned something. sched_yield() means "I'm the least important thing in
    > > > the system".
    > >
    > > Susv2:
    > >
    > > DESCRIPTION
    > >
    > > The sched_yield() function forces the running thread to relinquish
    > > the processor until it again becomes the head of its thread list. It
    > > takes no arguments.
    > >
    > >
    > > Aka "I skip the rest of my turn, try the others again once", not "I'm
    > > unimportant" nor "please rerun me immediatly".
    > >
    > > What is it with you people wanting to make sched_yield() unusable for
    > > anything that makes sense?
    >
    >Have to agree, I have a context switching benchmark which uses a spinlock
    >in shared memory for do-it-yourself gating, and it wants sched_yeild() to
    >be useful on uni. The SuS is pretty clear about this, the useful behaviour
    >is also the required behaviour, why are people resisting doing it that
    >way?

    It can be argued that the current implementation does exactly what SuS
    describes. The thread's list can be considered to be the sum of the active
    queue and the expired queue. Merely rotating the active queue and
    scheduling away excludes the yielding thread's equally important expired
    peers from participation in the game. Furthermore, if you are the only
    thread left in the active array, (you are at the head obviously), and all
    of your peers are currently expired, yielding would become meaningless...
    the thing you're trying to yield (the remainder of your slice) sticks to you.

    Having said that, it can also be argued that we are violating the SuS
    description in that yielding the remainder of your slice yields to all
    threads in all lists, not only it's list. What makes more sense to me than
    the current implementation is to rotate the entire peer queue when a thread
    expires... ie pull in the head of the expired queue into the tail of the
    active queue at the same time so you always have a player if one
    exists. (you'd have to select queues based on used cpu time to make that
    work right though)

    That would still suck rocks for mutex usage... as it must with any
    implementation of sched_yield() in the presence of peer threads who are not
    playing with the mutex. Actually, using sched_yield() makes no sense what
    so ever to me, other than what Arjan said. It refers to yielding your
    turn, but from userland "your turn" has no determinate meaning. There is
    exactly one case where it has a useable value, and that is when you're the
    _only_ runnable thread... at which time it means precisely zero. (blech)

    -Mike

    -
    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: 2005-03-22 13:35    [W:2.366 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site