Date: Tue, 25 Apr 95 16:42:34 -0700 From: Bakul Shah <bakul@netcom.com> To: terry@cs.weber.edu (Terry Lambert) Cc: mycroft@ai.mit.edu, hackers@FreeBSD.org Subject: Re: benchmark hell.. Message-ID: <199504252342.QAA25442@netcom2.netcom.com> In-Reply-To: Your message of "Tue, 25 Apr 95 16:22:40 MDT." <9504252222.AA02359@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504252342.QAA25442>