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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
