Jun Sun wrote:
>
> 2. *AFTER* the scheduler picks the process with the highest goodness value
> but *BEFORE* the context is switched, the interrupts are open.
> handler sets the need_resched flag, the need_resched flag will be set
> inside the CURRENT process'es task_struct.
> do the context switching. The process with the highest goodness value
> will become the CURRENT process, and, presumably, its need_resched flag
> the kernel will not do any rescheduling, unless due to other reaons
> that causes the need_resched in the new CURRENT process to be set.
> delayed from execution for up to 200ms, the maximum time slice a process
> can run without a forced rescheduling.
actually, it's more like 400ms (think "nice --20").
> v2.3.x. I assume the same bug exists in v2.3.x.
probably yes.
> First of all, I think this is must-fix bug. (Any arguments here?)
no. but there are more of these.
> There are a couple of ways to fix it. I personally favor the following
> Inside the schedule() function, after the switch_to() and
> __schedule_tail() calls, add the following code :
>
> if (prev->need_resched) {
> current->need_resched = 1;
> prev->need_resched = 0;
> }
seems ok, might be better than blocking interrupts.
[whether it would help to basically restart the schedule() at that
point is not obvious to me right now. If you can reproduce this
condition reliably, could you measure if doing that would make a
measurable difference for RT threads? ]
-
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 : Thu Mar 23 2000 - 21:00:34 EST