[Top] [All Lists]

Re: FPU emulator unsafe for SMP?

Subject: Re: FPU emulator unsafe for SMP?
From: Greg Lindahl <>
Date: Tue, 19 Feb 2002 22:28:35 -0500
In-reply-to: <>; from on Tue, Feb 19, 2002 at 05:12:38PM -0800
References: <> <> <> <> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <>
User-agent: Mutt/1.2.5i
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...


<Prev in Thread] Current Thread [Next in Thread>