The reason I say this is because SCHED_OTHER processes first have to
do some tests for policy != SCHED_OTHER before they can calculate
their goodness values. The patch I have in mind will avoid that,
yielding a small performance benefit.
I don't actually care too much about this small benefit (it will be
lost in the noise), I just want to emphasize that there is no
performance cost.
> > - properly isolates RT processes from normal processes in the
> > scheduler
> > - reduces the scope for bugs in the scheduler code.
>
> These points are valid too. In the current scheduler code,
> a process meets 3 separate tests if(p->policy != SCHED_OTHER),
> it sure would be nice to separate the paths and make the
> asm a little bit more straightforward (and faster).
Yep. Right now (2.1.123) has a bug with the way SCHED_YIELD is
handled: an RT process can end up yielding to a lower priority
process. That's contrary to the POSIX.4 spec.
I can see how this bug came to be: all that special-casing for
policy != SCHED_OTHER has resulted in things being left out. Probably
the implications of the treatment of SCHED_YIELD wasn't fully
considered.
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/