Fwd: 5-STABLE kernel build with icc broken

Peter Jeremy PeterJeremy at optushome.com.au
Wed Mar 30 00:01:25 PST 2005


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.

-- 
Peter Jeremy


More information about the freebsd-hackers mailing list