Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753122AbbBWW1y (ORCPT ); Mon, 23 Feb 2015 17:27:54 -0500 Received: from eddie.linux-mips.org ([148.251.95.138]:49257 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752505AbbBWW1x (ORCPT ); Mon, 23 Feb 2015 17:27:53 -0500 Date: Mon, 23 Feb 2015 22:27:51 +0000 (GMT) From: "Maciej W. Rozycki" To: Rik van Riel cc: Andy Lutomirski , Borislav Petkov , Ingo Molnar , Oleg Nesterov , X86 ML , "linux-kernel@vger.kernel.org" , Linus Torvalds Subject: Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs In-Reply-To: <54EB99E8.2060500@redhat.com> Message-ID: References: <20150221093150.GA27841@gmail.com> <20150221163840.GA32073@pd.tnic> <20150221172914.GB32073@pd.tnic> <54EB99E8.2060500@redhat.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2213 Lines: 46 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/