[lkml]   [2000]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectscheduler ignores need_resched flag in 2.2.x and 2.3.x?

It appears need_resched flag is changed from a global variable to
an instance variable inside task_struct since v2.2.x. I found out
that the flag could be ignored by the scheduler. This potentially
causes up to 200 ms delay in dispatching the highest priority process.


1. Among other things, the schedule() function picks the process with
highest value of goodness, and switches the context from the current
process to the new one.

2. *AFTER* the scheduler picks the process with the highest goodness
but *BEFORE* the context is switched, the interrupts are open.

3. If an interrupt happens during that time window, and if the interrupt
handler sets the need_resched flag, the need_resched flag will be set
inside the CURRENT process'es task_struct.

4. Once the interrupt handling is done, the scheduler will continue to
do the context switching. The process with the highest goodness
will become the CURRENT process, and, presumably, its need_resched
is clear.

5. Later on the kernel only checks the need_resched flag in the CURRENT
process to decide whether it needs to do any rescheduling. Since the
need_resched flag in the new CURRENT process task_struct is clear,
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.

If the highest priority process is made availabe in step 3, it could be
delayed from execution for up to 200ms, the maximum time slice a process
can run without a forced rescheduling.


I did a test to confirm the above scenario. It involves the parallel
port (to generate interrupts), a driver module, a user test program,
and a small patch of kernel.

This test demonstrates that a highest priority process can be
delayed from execution for up to 200 ms due to the above scenario.

If there are enough interestes, I will post the test itself
and the test results.

The test is done on v2.2.12. But the code is still the same in
v2.3.x. I assume the same bug exists in v2.3.x.


First of all, I think this is must-fix bug. (Any arguments here?)

There are a couple of ways to fix it. I personally favor the following

Inside the schedule() function, after the switch_to() and
calls, add the following code :

if (prev->need_resched) {
current->need_resched = 1;
prev->need_resched = 0;

This piece of code in a sense lets the new CURRENT process "inherits"
the value of need_resched from the previous CURRENT process.


<to be filled by you ...:-0 >


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.096 / U:1.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site