On Wed, Feb 20, 2002 at 01:08:30AM +0100, Kevin D. Kissell wrote:
> > > > Hmm, I see. The lazy fpu context switch code is not SMP safe.
> > > > I see fishy things like "last_task_used_math" etc...
> > >
> > > What, you mean "last_task_used_math" isn't allocated in a
> > > processor-specific page of kseg3??? ;-)
> >
> > You must be talking about another OS, right? :-) I don't think
> > Linux has processor-specific page, although this sounds like
> > a good idea to explore.
>
> It's gotta be done. I mean, the last I heard (which was a long
> time ago) mips64 Linux was keeping the CPU node number in
> a watchpoint register (or something equally unwholesome)
It seems that people are getting smarter by putting cpu id to
context register. In fact isn't this part of new MIPS
standard?
>
> But getting back to the original topic, there's another fun bug
> waiting for us in MIPS/Linux SMP floating point that can't
> be fixed as easly with VM slight-of-hand. Consider processes
> "A" and "B", where A uses FP and B does not: A gets scheduled
> on CPU 1, runs for a while, gets preempted, and B gets CPU 1.
> CPU 2 gets freed, so A gets scheduled on CPU 2. Unfortunately,
> A's FP state is still in the FP register set of CPU 1. The lazy FPU
> context switch either needs to be turned off (bleah!) or be fixed
> for SMP to handle the case where the "owner" of the FPR's
> on one CPU gets scheduled on another.
>
> The brute force would be somehow to send an interrupt to the CPU
> with the FP state that will cause it to cough it up into the thread context
> area. One alternative would be to give strict CPU affinity to the thread
> that has it's FP state on a particular CPU. That could complicate load
> balancing, but might not really be too bad. At most one thread per CPU
> will be non-migratable at a given point in time. In the above scenario,
> "A" could never migrate off of CPU 1, but "B" could, and would
> presumably be picked up by an idle CPU 2 as soon as it's time slice
> is up on CPU 1. That will be less efficient than doing an "FPU shootdown"
> in some cases, but it should also be more portable and easier
> to get right.
>
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.
> Does this come up in x86-land? The FPU state is much smaller
> there, so lazy context switching is presumably less important.
>
It appears x86 is not doing lazy fpu switching, at least not
as agressively as MIPS. I am actually curious how IRIX handles
this case, assuming IRIX is reasonable enough to have
lazy FPU switching...
Jun
|