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 > overhead. 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 modified it. 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... greg
