Re: Fwd: 5-STABLE kernel build with icc broken

From: Peter Jeremy (PeterJeremy_at_optushome.com.au)
Date: 03/30/05

  • Next message: David Schultz: "Re: Fwd: 5-STABLE kernel build with icc broken" 
    Date: Wed, 30 Mar 2005 18:01:13 +1000
To: jason henson <jason@ec.rr.com>

    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 "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: David Schultz: "Re: Fwd: 5-STABLE kernel build with icc broken"

    Relevant Pages

    • Re: Floating point in interrupt handler
      ... FPU context is assumed to only change in user processes. ... FP you want to do in the kernel. ... but we should save/restore the FPU state before using them so userland ...
      (freebsd-hackers)
    • Re: Floating point in kernel mode, Win2003 64-bit
      ... I'm interested in this because I use SSE2 in kernel mode, ... Some other driver messes up FPU, ... Upper registers are supported in the kernel, ... handled by the kernel to save or restore FPU state. ...
      (microsoft.public.development.device.drivers)
    • Re: CONFIG_PREEMPT causes corruption of applications FPU stack
      ... atleast recentfpu changes don't play a role in this. ... I think I found the reason for your issue aswell. ... At the next context switch to process 'A' again, kernel tries to restore ... same patch I sent out 30 mins back should fix your issue ...
      (Linux-Kernel)
    • Re: RFC: unlazy fpu for frequent fpu users
      ... the FPU context lazily. ... you take an extra trap every context switch. ... you track the context carefully you can completely avoid the restore. ...
      (Linux-Kernel)
    • Re: Floating point in interrupt handler
      ... At the start of my loop function I save the FPU state ... At the end of the function I restore the FPU state with: ... kernel trap 22 with interrupts disabled ...
      (freebsd-hackers)