[lkml]   [2002]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Question about sched_yield()
    On Tue, 2002-06-18 at 09:58, Chris Friesen wrote:

    > David Schwartz wrote:
    > > What would you expect?
    > If there is only the one task, then sure it's going to be 100% cpu on that
    > task.
    > However, if there is anything else other than the idle task that wants to
    > run, then it should run until it exhausts its timeslice.
    > One process looping on sched_yield() and another one doing calculations
    > should result in almost the entire system being devoted to calculations.

    Exactly. The reason the behavior is odd is not because the sched_yield
    task is getting any CPU, David. I realize sched_yield is not equivalent
    to blocking.

    The reason this behavior is suspect is because the task is receiving a
    similar amount of CPU to tasks that are _not_ yielding but in fact doing
    useful work for the entire duration of their timeslice.

    A task that continually uses its timeslice vs one that yields should
    easily receive a greater amount of CPU, but this is not the case.

    As someone who works in the scheduler, this points out that sched_yield
    is, well, broken. First guess would be it is queuing to the front of
    the runqueue (it once did this but I thought it was fixed) or otherwise
    exhausting the timeslice wrong.

    Someone pointed out this bug existed similarly in 2.5, although it was a
    bit different. 2.5 has a different (and better, imo) sched_yield
    implementation that tries to overcome certain shortcomings and also
    perform optimally and fairly.

    Robert Love

    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:26    [W:0.026 / U:8.256 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site