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

From: Maciej W. Rozycki
Date: Mon Feb 23 2015 - 17:27:58 EST

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

> 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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at