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/