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 09:05:25AM -0400, Buytaert_Steven@emc.com wrote:
    > > -----Original Message-----
    > > From: Andi Kleen
    > > [ ... about use of sched_yield ...]
    > > On the other hand when they fix their code to not rely on sched_yield
    > > but use [...]
    >
    > Agreed, but $ find . -name "*.[ch]" | xargs grep -E "yield[ ]*\(" | wc over
    > the 2.6.16 kernel yields 105 hits, note including comments... An interesting spot is e.g. fs/buffer.c free_more_memory()

    A lot of those are probably broken in some way agreed.

    > >
    > > > 2) When a task is eventually put in the expired list in sched_yield,
    > > > give it back the full time slices round (as done in scheduler_tick), not > > with the remaining slices as is done now?
    > >
    > > That would likely be unfair and exploitable.
    >
    > I don't understand; how more unfair would it be than passing via scheduler_tick? Grabbing a resource with a single time slice left would be more unfair towards other tasks IMHO when you get moved to the expired list with the resource in still in your possession.

    With a particular sleep pattern it could get more CPU time.

    > > > 3) Put the task in the expired list at a random position, not at the end
    > > > is done now?
    > >
    > > Sounds like an interesting approach, but to do it in O(1) you would
    > > need a new data structure with possibly much larger constant overhead.
    >
    > Agreed, but not dramatic. Suppose you need to insert at position X, you would do, on the linked list after proper setup:
    >
    > while (X--) { prev = current; current = current->next }
    >
    > You could have a small duffs device to reduce the X-- checking overhead.

    You would need to rename the scheduler to "sometimes O(1)" first @)

    Besides - but I guess you're aware of it - any randomized algorithms tend
    to drive benchmarkers and performance analysts crazy because their performance
    cannot be repeated. So it's usually better to avoid them unless there is
    really no alternative.

    -Andi
    -
    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 15:35    [W:0.044 / U:1.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site