Fwd: 5-STABLE kernel build with icc broken

[David Schultz]

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?
> >
> >http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00264.html
> 
> 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
> handled.
> 
> 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.