Messages in this thread | | | From | Borislav Deianov <> | Date | Sun, 10 Oct 1999 02:29:00 +0200 | Subject | Re: SCHED_YIELD again |
| |
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/
| |