I was reading through sched.c and noticed two places where variable
assignments occur immediately prior to 'if(test) goto label:' statements.
If the test is TRUE, then the jump happens and in both cases the
variables are either not used, or immediately over-written..
So I've re-sequenced the two sets of statements to 'test then assign'
rather than 'assign regardless, then test'.
I presume that the C compiler is optimising this out, but not all
platforms may been seeing this... It's probably only going to save
a couple of cycles on any iteration through the scheduler, but
the more available for everyone else the better :)
--- kernel/sched.c.orig Fri Feb 9 19:37:03 2001
+++ kernel/sched.c Sun Mar 4 20:27:42 2001
@@ -507,11 +507,11 @@
if (!current->active_mm) BUG();
need_resched_back:
+ if (in_interrupt())
+ goto scheduling_in_interrupt;
prev = current;
this_cpu = prev->processor;
- if (in_interrupt())
- goto scheduling_in_interrupt;
release_kernel_lock(prev, this_cpu);
@@ -553,10 +553,10 @@
/*
* Default process to select..
*/
- next = idle_task(this_cpu);
- c = -1000;
if (prev->state == TASK_RUNNING)
goto still_running;
+ next = idle_task(this_cpu);
+ c = -1000;
still_running_back:
list_for_each(tmp, &runqueue_head) {
--END-OF-PATCH---
--
** Chris Higgins e: chris.higgins at horizon.ie **
** Technical Business Development tel: +353-1-6204916 **
** Horizon Technology Group fax: +353-1-6204949 **
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
