[PATCH] -mm: Small schedule() optimization

[Andreas Mohr]

Hello all,

I found that there's a possible small optimization right at the very
beginning of schedule():

        if (likely(!current->exit_state)) {
                if (unlikely(in_atomic())) {

can be reversed into

        if (unlikely(in_atomic())) {
                if (likely(!current->exit_state)) {

This is a Good Thing since it avoids having to evaluate both checks,
and both use current_thread_info() which has an inherent AGI stall risk on
x86 CPUs if it cannot be inter-mingled with other unrelated opcodes.

I'm a bit puzzled that this has not been done like that before.
Probably since the exit_state check got added as an after-thought...
Or did I miss some important reason here? (branch prediction??)

Patch against 2.6.16-rc5-mm3.

Thanks!

Signed-off-by: Andreas Mohr <andi@xxxxxxxx>


--- linux-2.6.16-rc5-mm3/kernel/sched.c.orig	2006-03-08 18:36:58.000000000 +0100
+++ linux-2.6.16-rc5-mm3/kernel/sched.c	2006-03-08 18:39:55.000000000 +0100
@@ -3022,8 +3022,8 @@
 	 * schedule() atomically, we ignore that path for now.
 	 * Otherwise, whine if we are scheduling when we should not be.
 	 */
-	if (likely(!current->exit_state)) {
-		if (unlikely(in_atomic())) {
+	if (unlikely(in_atomic())) {
+		if (likely(!current->exit_state)) {
 			printk(KERN_ERR "BUG: scheduling while atomic: "
 				"%s/0x%08x/%d\n",
 				current->comm, preempt_count(), current->pid);

-- 
No programming skills!? Why not help translate many Linux applications! 
https://launchpad.ubuntu.com/rosetta
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/