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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site