In article <Pine.GSO.3.95.1000425130016.5842C-100000@thales> you wrote:
> [[ I sent a similar mail to Alan Cox some time ago but I didn't get a
> response and the fix isn't included in 2.2.16pre1 either. ]]
>
> I think I found a Bug in the linux scheduler: A running SCHED_RR
> process is not preempted when its time slice is exhausted but the process
> is still running. The following program demonstrates the problem:
> In theory the child should be preempted when the time slice is exhausted
> and the parent should be allowed to run. Unfortunately this doesn't work.
Yes, this and other problems with the scheduler have been known for
quite a while and are still present in 2.3.99:
SCHED_RR threads don't work
sched_yield doesn't work for RT threads
sched_yield doesn't always yield for SCHED_OTHER threads
wrong wake up order for RT threads
sched_rr_get_interval returns constant bogus value
counter for SCHED_FIFO threads is never reset
several wrong and misleading comments in the code
Alan, _please_ add the first item (at least) to the 2.4 jobs
list. It's a documented feature that just plain doesn't work and I
think it's a bloody shame, especially since a fix exists (by Artur
Skawina).
> - if (prev->state == TASK_RUNNING)
> + if ((prev->state == TASK_RUNNING) && !prev2)
> goto still_running;
The schedule() code is intentionally spaghettified to allow it to run
without taking any conditional jumps in the common case. I think the
above code would break that property.
> - if (can_schedule(p)) {
> + if (can_schedule(p) || (p == prev2)) {
This adds an extra test for each process in the runqueue. I don't
think it's possible to fix the SCHED_RR problem without any additional
cost in the common path but it can at least be constant.
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/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:10 EST