Re: AES assembler optimizations

From: David S. Miller (davem_at_redhat.com)
Date: 08/10/04

  • Next message: Thierry Vignaud: "Re: [Kernel] Re: New dev model" 
    Date:	Tue, 10 Aug 2004 13:36:09 -0700
To: hpa@zytor.com (H. Peter Anvin)

    On Tue, 10 Aug 2004 19:51:29 +0000 (UTC)
    hpa@zytor.com (H. Peter Anvin) wrote:

    > It's not really that hard, you just have to have enough work to
    > amortize it over. The two metrics are: how much work do you get per
    > call, and how much work do you get before the next schedule().

    Someone might want to investigate using sparc64's FPU saving
    scheme on x86, if possible. It might make the cut-off point
    smaller.

    On sparc64, we:

    1) Always save the full FPU state at context switch time if it
       is active.

    2) On entry to a FPU-using kernel routine, we save the FPU if
       it is active.

    3) On exit from a FPU-using kernel routine, we do nothing
       except mark the FPU as inactive.

    4) FPU-disabled traps by the user restore the state saved
       by #1 or #2

    Not that this means FPU state can be recursively saved.
    For example, if a FPU memcpy take an interrupt, and the interrupt
    handler invokes a FPU memcpy, it works just fine.

    This works extremely well for cases such as:

       The user made the FPU active, but it is not going to
       use the FPU for quite some time. The kernel can use
       the FPU multiple times, and only need to save state once.

    It's worked extremely well in practice. We store the stack
    of FPU states at the end of the thread_struct area. This
    provides better cache behavior than storing it on the local
    kernel stack each time the kernel wants to use the FPU (Solaris
    on UltraSPARC chooses this method BTW).
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Thierry Vignaud: "Re: [Kernel] Re: New dev model"

    Relevant Pages

    • Re: Fwd: 5-STABLE kernel build with icc broken
      ... >> b) save FPU state on a context switch (or if the kernel wants the FPU) ...
      (freebsd-hackers)
    • Re: [patch] x64, fpu: fix possible FPU leakage in error conditions
      ... this is wrong(as our main intention is to clear the fpu state of the ... Post commit 92d140e21f1ce8cf99320afbbcad73879128e6dc, live FPU ... In the error condition for restore_fpu_checking(especially during ... SIGSEGV, if we fail to restore the state. ...
      (Linux-Kernel)
    • 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 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)
    • Re: AES assembler optimizations
      ... > 1) Always save the full FPU state at context switch time if it ... > 2) On entry to a FPU-using kernel routine, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)