Re: SCHED_YIELD again

Borislav Deianov (borislav@lix.polytechnique.fr)
Sun, 10 Oct 1999 02:29:00 +0200


On Sat, Oct 09, 1999 at 06:13:09PM -0600, Richard Gooch wrote:
> Agreed. But in your patch I saw some that appears to re-introduce a
> bug I fixed some time ago. You were unconditionally setting
> SCHED_YIELD in sched_yield(). I made it conditional in the first place
> because POSIX.4 semantics were not being obeyed.

Setting it unconditionally is necessary if we want yielding for RT
processes at all. We just have to handle it properly later.

Basically, all we do is move the yielded process to the end of the
runqueue. We also get rid of the special case (prev_goodness()) for
the previous process. That one wasn't really necessary, since the
previous process is still in the runqueue and will be considered later
in the loop.

So, if there is another process with the same/higher priority than the
yielded process, that one will be selected, since it's earlier in the
runqueue. If not, we pick the previous one again (this is the case you
are worried about).

There's a slight change in behaviour: if a process is preempted
(without sched_yield) and there's another process with exactly the
same priority, the other process gets to run. In the old code the
previous process runs again. This shouldn't be a problem.

Regards,
Borislav

-
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/