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/