> Date: Wed, 11 Mar 1998 15:44:57 -0500 (EST)
> From: "Benjamin C.R. LaHaise" <blah@kvack.org>
>
> Some improvements that need to be made to the patch before it's
> integrated are:
>
> a) when saving FPU state, it should be saved to task that it
> belongs to. (see the scheduler lazy-FPU saving tricks)
> b) only bother saving the FPU state if the last user of the FPU
> was a user process
>
> Actually, what is easier is to store the FPU regs to the local stack
> frame. We are going to do this with the Ultra VIS stuff soon, whats
> nice on VIS is you can use the high bandwidth stores to stuff the FPU
> registers into the save area. I don't know if MMX is like this.
That's what the patch does currently, and it works for the 'normal' case.
I believe saving the FPU state occurs as a high bandwidth store (Intel and
their design bugs). However, storing it on the stack is horribly broken
for the copy_from_user case where the kernel thread might go to sleep and
the saved state belongs to another process. My thinking is that if we're
going to have to save state anyways, it might as well be put where it
belongs so that next time we want to do an fpu-fast-copy we won't have to
save state. (Looking at the normal use of a system, the FPU is only
touched by crt0.)
...
> Look into the btfixup mechanism the 32-bit sparc port now uses in the
> vger CVS sources. You can have multiple memcpy/memset
> etc. implementations, pick the one which performs best at boot time,
> and make it zero cost.
Ahh, cute! (You sparc guys seem to come up with the most fascinating
code.) On intel's we can get away with self modifying code which is a
bit easier, though. I never thought I'd be endorsing the use of self
modifying code... oh well ;-)
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu