From owner-freebsd-hackers  Tue Apr 25 16:43:26 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id QAA23943
          for hackers-outgoing; Tue, 25 Apr 1995 16:43:26 -0700
Received: from netcom2.netcom.com (bakul@netcom2.netcom.com [192.100.81.108])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA23935
          for <hackers@freebsd.org>; Tue, 25 Apr 1995 16:43:22 -0700
Received: from localhost by netcom2.netcom.com (8.6.12/Netcom)
	id QAA25442; Tue, 25 Apr 1995 16:42:34 -0700
Message-Id: <199504252342.QAA25442@netcom2.netcom.com>
To: terry@cs.weber.edu (Terry Lambert)
cc: mycroft@ai.mit.edu, hackers@FreeBSD.org
Subject: Re: benchmark hell.. 
In-reply-to: Your message of "Tue, 25 Apr 95 16:22:40 MDT."
             <9504252222.AA02359@cs.weber.edu> 
Date: Tue, 25 Apr 95 16:42:34 -0700
From: Bakul Shah <bakul@netcom.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

I didn't explain.  Sorry!  I assumed we would want to do
lazy FP context save/restore.  Once you do that, further
refinements don't buy you very much.  If you reread what I
wrote _in this context_, may be it will make more sense.

> o       The FPU has a "last used by" state variable
> o       When the first FPU using process is run, this variable is
>         set to its PID.
Okay.

> o       When a context switch occurs, the FPU state is left unchanged
>         if the process being switched to is a non FPU using process,
>         or if the process being switched to is the one that "last used"
>         the FPU.

In my scheme, on a context switch, you _always_ leave the
FPU state alone.  The only thing you do on switching *to*
some process P is that you set the FPU_present bit (or
equivalent) only if P was the last user.  This avoids an
extra FPU-not-present trap on the first FP operation by P.

For any other process the trap will be taken on the first FP
operation.  When the trap is taken, you *save* the context
in the PCB of the last_used_by process and *restore* from
the current proc.

If the PCBs also get swapped out, that is another place
where you need to save the FP context.  At this time
FPU is considered free so anyone can grab it.

When a new image is execed, it will need some default FP
state, which can be saved once at system startup time
and copied to every new image.

That is it!  If a proc. never uses the FPU, it will never
take an FP trap.  Extra traps are taken only when more than
one proc. is constantly using the FPU _at the same time_.

You can refine this further.  For example, you can
save/restore `eagerly', that is, on a context switch to a FP
intensive process, thereby saving a trap.  Or you can switch
between eager and lazy scheme depending on how many FP traps
were taken recently but this is usually not worth it.

Note that this is an instance of the general case where one
or more processes need a `virtual' resource which is
emulated by giving exclusive access to a shared resource.
If this resource has considerable context that must be saved
and restored and there is a way to signal that in the user
mode, lazy context saving can save quite a bit.

--bakul