[lkml]   [2004]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: AES assembler optimizations
On Tue, 10 Aug 2004 19:51:29 +0000 (UTC) (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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.045 / U:25.412 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site