Messages in this thread | | | From | Borislav Deianov <> | Date | Sun, 10 Oct 1999 12:22:10 +0200 | Subject | Re: SCHED_YIELD again |
| |
On Sun, Oct 10, 1999 at 06:04:44AM +0100, Artur Skawina wrote: > Borislav Deianov wrote: > > > > 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.
I guess this is not 100% correct. With my patch the other process _may_ get to run, depending on where it is in the runqueue.
I'd very much like to see this change in behaviour (the special case for prev gets in my way for some other stuff I'm doing). The new behaviour isn't "worse" than the old one, and nothing can depend on the old behaviour because of dynamic priorities. And it simplifies the code too.
> Consider what happens with 2+ equal priority SCHED_FIFO processes...
Only one gets to run until it blocks or calls sched_yield (see the man page for sched_setscheduler). What is the problem?
> fixing the scheduler w/o (1) introducing new bugs, and (2) making > it slower isn't as simple as it seems at first sight. also there
Sure. That's why I'm aiming for a minimal patch. I'd be happy with yours too, though, minus the special case for prev.
> The only issue left is iirc the (external) SCHED_YIELD assumptions]
Can you elaborate on this?
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/
| |