Messages in this thread Patch in this message |  | | | Date | Fri, 27 Nov 1998 11:48:50 +0100 (CET) | | From | Andrea Arcangeli <> | | Subject | [patch] idle_task was wasting a lot of CPU |
| |
I am going to send you some of my code from my tree.
The first pending patch is a fix for a bug I discovered last week. The patch avoid the idle task to continue to run if an useful process is being wakenup. It make a _big_ difference. Compiling the kernel a `xload' show that the CPU is used at 100% all the time (5/10% kernel and the other is gcc). Without this patch xload is far from doing a straight line in the high part of the graph.
I have not benchmarked the time differences in a kernel compilation and see the numbers, any volunteers btw?
Here the patch against 2.1.130:
Index: linux/kernel/sched.c diff -u linux/kernel/sched.c:1.1.1.2 linux/kernel/sched.c:1.1.1.1.2.13 --- linux/kernel/sched.c:1.1.1.2 Fri Nov 27 11:19:09 1998 +++ linux/kernel/sched.c Fri Nov 27 11:41:41 1998 @@ -130,8 +133,15 @@ } #endif #endif - if (p->policy != SCHED_OTHER || p->counter > current->counter + 3) - current->need_resched = 1; + /* + * If the current process is the idle one, we must reschedule ASAP. + * Checking for p->counter >= current->counter we have the idle task + * check implicit. + * -arca + */ + if (/* idle_task == current || */ p->counter >= current->counter || + p->policy != SCHED_OTHER) + current->need_resched = 1; } /*
Note I decreased the limit to stop the running process to run a schedule() to improve iteractive performance. I don' t know the impact in the scheduling() increase doing this change, but the system feel more responsive. If you want to go 100% safe apply the patch and uncomment the idle_task check that is implicit in my current code (because for the idle task ->counter is always 0) and return to check for counter+3...
Andrea Arcangeli
- 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/
|  |