On Wed, Mar 30, 2005, Peter Jeremy wrote:
> On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote:
> >Later in that thread they discuss skipping the restore state to make
> >things faster. The minimum buffer size they say this will be good for
> >is between 2-4k. Does this make sense, or am I showing my ignorance?
> Yes. There are a variety of options for saving/restoring FPU state:
> a) save FPU state on kernel entry
> b) save FPU state on a context switch (or if the kernel wants the FPU)
> c) only save FPU state if a different process (or the kernel) wants the FPU
> 1) restore FPU on kernel exit
> 2) restore FPU state if a process wants the FPU.
> a and 1 are the most obvious - that's the way the integer registers are
> I thought FreeBSD used to be c2 but it seems it has been changed to b2
> since I looked last.
> Based on the mail above, it looks like Dfly was changed from 1 to 2
> (I'm not sure if it's 'a' or 'c' on save).
> On the i386 (and probably most other CPUs), you can place the FPU into
> am "unavailable" state. This means that any attempt to use it will
> trigger a trap. The kernel will then restore FPU state and return.
> On a normal system call, if the FPU hasn't been used, the kernel will
> see that it's still in an "unavailable" state and can avoid saving the
> state. (On an i386, "unavailable" state is achieved by either setting
> CR0_TS or CR0_EM). This means you avoid having to always restore FPU
> state at the expense of an additional trap if the process actually
> uses the FPU.
This is basically what FreeBSD does on i386 and amd64. (As a
disclaimer, I haven't read the code very carefully, so I might be
missing some of the details.) Upon taking a trap for a process
that has never used the FPU before, we save the FPU state for the
last process to use the FPU, then load a fresh FPU state. On
subsequent context switches, the FPU state for processes that have
already used the FPU gets loaded before entering user mode, I
think. I haven't studied the code in enough detail to know what
happens for SMP, where a process could be scheduled on a different
processor before its FPU state is saved on the first processor.