On Tue, Feb 19, 2002 at 05:12:38PM -0800, Jun Sun wrote:
> As I looked into FPU/SMP issue, I realized this problem. I agree
> that locking fpu owner to the current cpu is the best solution.
> I bet this won't really hurt performance because any alternative would
> incur transferring FPU registers across cpus, which is not a small
There are other CPUs out there with large cpu contexts, like the Alpha
and Itanium. So we can look at what Linux does with them.
Alpha seems to always save the fpu state (the comments say that gcc
always generates code that uses it in every user process.)
The Itanium seems to be lazy only for nonSMP. If a process touches the
fpu registers and doesn't own their contents, it will save the fpu
contents to the appropriate process' state and load the correct fpu
state. For SMP it seems to always save the fpu state, if the process
I suspect that the optimization of not saving the fpu state for a
process that doesn't use the fpu is the most critical optimization.
And that you do already.
What you propose, locking the fpu owner to the current cpu, will not
result in a fair solution. Imagine a 2 cpu machine with 2 processes
using integer math and 1 using floating point... how much cpu time
will each process get? Imagine all the funky effects. Now add in a
MIPS design in which interrupts are not delivered uniformly to all the
cpus... I don't know if there are any or will ever be any, but...