Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs

["Maciej W. Rozycki" <macro@linux-mips.org>]

On Mon, 23 Feb 2015, Rik van Riel wrote:

> > I meant something else -- a slow FPU instruction can retire after a
> > task has been switched where the FP context has been left intact,
> > i.e. in the lazy FP context switching case, where only the MMU
> > context and GPRs have been replaced.
> 
> I don't think that's true, because changing the MMU context and GPRs
> also includes changing the instruction pointer, and changing over the
> execution to the new task.

 That does not matter.  The instructions in question only operate on x87 
internal registers: the data stack registers, specifically ST(0) and 
possibly also ST(1), and consequently the Tag Word register, and the 
Status Word register.  No CPU resource such as the MMU or GPRs need to be 
referred for an x87 instruction to complete.  Any unmasked IEEE 754 FPU 
exception recorded on the way is only signalled at the next x87 
instruction.

> After a context switch, the instructions from the old task are no
> longer in the pipeline.

 I'd say it's implementation-specific.  As I mentioned the i486 aborted 
any transcendental x87 instruction in progress upon taking an exception or 
interrupt.  That was a model like you refer to, but as I also mentioned it 
had its shortcomings.

 Any newer implementation I'd expect to, and Pentium class processors 
certainly did, continue executing these instructions in parallel in the 
FPU pipeline regardless of what the CPU does until completed.  If WAIT or 
a waiting x87 instruction was encountered while a previous x87 instruction 
was still in progress, the CPU pipeline would stall until the earlier x87 
instruction has completed.  The FPU has no way to determine the CPU 
context has been switched and neither it recognises execution privilege 
levels.

 I can't speak of SIMD instructions, I don't know offhand.  OTOH AFAIK 
they don't suffer from latencies so long as some x87 instructions that may 
be in the range of 400 clock cycles.

  Maciej