> Actually, what we could do is put in better logic to
> determine whether or not the FPU is in use by a task (which is harder
> than you think because crt0 does zero them out, so you have to filter
> out that case), and then if the FPU isn't in use, you wouldn't need to
> restore the FPU right away.
Not "in use by a task", but "in use by this task" (or even "in use by this
task in user space" if we let the compiler worry about nested usage
of the FPU within the kernel). I assume that either this kernel-level FPU
usage happens with interrupts off, or that it already handles the
possibility of a context switch to and back from some other FPU-using
process. To determine whether you want to restore the FPU registers
immediately, before you start using the FPU you should check and
see if the current task was the last FPU user. If it was, then you
may as well restore the FPU registers when you finish, and leave the
387 valid (the current task should already still be the last user); if
it was not, invalidate the FPU and set the last user to some flavor of
"none", so that nothing bothers to save the garbage you'll never use again.
A stricter test (useful in the case of multiple processes using the FPU
lightly) would be to see if the current task was the last FPU user and
the 387 is still valid (i.e. it used the FPU this timeslice); if so,
you certainly want to restore the FPU immediately, and if not, you may
wish to put off the restore.
> (You'd still have to do the lazy save, to
> avoid losing the current FPU state.)
True, assuming the current FPU state belongs to a live process.
In summary: see if we need to restore immediately by seeing if our user-
level FPU usage was recent, and make sure we won't bother to save the
dirty FPU registers once we're done with them (I'd hope this is done
already...).
Keith