i387: do not preload FPU state at task switch time
authorLinus Torvalds <torvalds@linux-foundation.org>
Thu, 16 Feb 2012 23:45:23 +0000 (15:45 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 27 Feb 2012 18:25:54 +0000 (10:25 -0800)
commitba6aaed5cc8f55b77644daf56e9ae3a75f042908
treedb167f40114d5905f83b52fe18b53b2cfbaf6481
parent29515b215b9bbbad0368a5039ba6e53ed3fa7f25
i387: do not preload FPU state at task switch time

commit b3b0870ef3ffed72b92415423da864f440f57ad6 upstream.

Yes, taking the trap to re-load the FPU/MMX state is expensive, but so
is spending several days looking for a bug in the state save/restore
code.  And the preload code has some rather subtle interactions with
both paravirtualization support and segment state restore, so it's not
nearly as simple as it should be.

Also, now that we no longer necessarily depend on a single bit (ie
TS_USEDFPU) for keeping track of the state of the FPU, we migth be able
to do better.  If we are really switching between two processes that
keep touching the FP state, save/restore is inevitable, but in the case
of having one process that does most of the FPU usage, we may actually
be able to do much better than the preloading.

In particular, we may be able to keep track of which CPU the process ran
on last, and also per CPU keep track of which process' FP state that CPU
has.  For modern CPU's that don't destroy the FPU contents on save time,
that would allow us to do a lazy restore by just re-enabling the
existing FPU state - with no restore cost at all!

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/x86/include/asm/i387.h
arch/x86/kernel/process_32.c
arch/x86/kernel/process_64.c
arch/x86/kernel/traps.c