lkml.org 
[lkml]   [1999]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: sched_yield() on "SCHED_FIFO"
    NIIBE Yutaka writes:
    > Kuniyasu SUZAKI writes:
    > > The supposed action of my program depended on the Round Robin
    > > scheduling on 1 CPU. The program produced two processes and they would
    > > be executed alternately, because it yielded each other on 1 CPU. The
    > > main problem is one process monopolied a CPU even if it executed
    > > sched_yield().
    >
    > Oops, I had not understood the code you provided. Now, I see your
    > point.
    >
    > I think that I've found the cause of the problem.
    >
    > --------------------------- kernel/sched.c
    > asmlinkage int sys_sched_yield(void)
    > {
    > spin_lock_irq(&runqueue_lock);
    > if (current->policy == SCHED_OTHER) <---------- This line.
    > current->policy |= SCHED_YIELD;
    > current->need_resched = 1;
    > move_last_runqueue(current);
    > spin_unlock_irq(&runqueue_lock);
    > return 0;
    > }
    > ---------------------------
    >
    > This line was introduced on November 1998 in the patch-2.1.127.
    > Without this conditional (set SCHED_YIELD flag regardless of policy),
    > I guess it works fine.

    I'm the author of that patch, and it's the correct behaviour. Read the
    spec. If a RT process "yields" to a SCHED_OTHER process, the RT
    process should keep running. It should *not* give CPU time to the
    SCHED_OTHER process.

    Regards,

    Richard....

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:0.024 / U:30.684 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site