On Sun, 19 Dec 1999 06:04:47 -0800 (PST) 
 Jeff Roberson <nomad@nop.aliensystems.com> wrote:

...having been the last person to really rework that code, I'll take a
stab at answering this :-)

 > I was reading the code for cpu_switch in locore.s when I noticed the
 > following;  NetBSD saves the current process's context before checking the
 > run queue.  If the processes are the same then none of this is neccisary.
 > cpu_switch does check this before unloading/loading the vmspace.   I
 > believe the context switches would be faster if someone changed this.
 > Here are the cases which are evident to me:

Actually, it saves the callee-saved registers (plus the Processor Status
register, because, hey, we're here, might as well)... most of the process
context is already saved by this time (in the trapframe, upon entry into
the kernel).

The reason for this is that the switch code wants to *use* some of these
registers (s0, s1, etc.) ... because doing so makes the code a LOT more
sane; it can rely on those registers being preserved across the various
function calls it makes.

I think, in general, the code would be a lot more complicated if we changed
this.

 > 1)  Switching from process X to process Y.  
 > No performance difference would happen here, because you have to do all of
 > the work anyway.
 > 
 > 2)  Switching from process X to process X.  
 > You save 20 or so instructions.
 > 
 > 3) Switching from idle loop to process Y.
 > You do the operations while a process is ready to run, instead of before a
 > process is ready to run, which delays it a bit. You could negate this by
 > waiting until you decide to idle to store the context so that you are
 > ready to load another, and you waste no time because the cpu would be idling anyway.
 > 
 > 4) Switching back to process X after idling.  
 > Again, you save an extra 20 instructions. 
 > 
 > What case is the most common?  If we are switching to the same process
 > more often than not this would give us a boost.  Otherwise if we are going
 > from idle to another process more often this might not be so important.
 > Is there something I overlooked that prohibits this?  Or is it perhaps
 > such a negligable performance difference that no one else cares? :-)

The reason it does this with the VM context is to protect a critical
section.  For the case where you went idle, I'm not sure saving 40
instructions is worth changing the code.  And, on a system where you're
switching to other processes more frequently (i.e. a system where the load
average is pretty much anything but 0 :-), I don't think adding complexity
to not use the callee-saved registers is worth it.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>