From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755357AbbBUJcB (ORCPT ); Sat, 21 Feb 2015 04:32:01 -0500 Received: from mail-we0-f174.google.com ([74.125.82.174]:38278 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752154AbbBUJb5 (ORCPT ); Sat, 21 Feb 2015 04:31:57 -0500 Date: Sat, 21 Feb 2015 10:31:50 +0100 From: Ingo Molnar To: Andy Lutomirski Cc: Oleg Nesterov , Rik van Riel , x86@kernel.org, linux-kernel@vger.kernel.org, Borislav Petkov Subject: Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs Message-ID: <20150221093150.GA27841@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Lutomirski wrote: > We have eager and lazy fpu modes, introduced in: > > 304bceda6a18 x86, fpu: use non-lazy fpu restore for processors supporting xsave > > The result is rather messy. There are two code paths in > almost all of the FPU code, and only one of them (the > eager case) is tested frequently, since most kernel > developers have new enough hardware that we use eagerfpu. > > It seems that, on any remotely recent hardware, eagerfpu > is a win: glibc uses SSE2, so laziness is probably > overoptimistic, and, in any case, manipulating TS is far > slower that saving and restoring the full state. > > To try to shake out any latent issues on old hardware, > this changes the default to eager on all CPUs. If no > performance or functionality problems show up, a > subsequent patch could remove lazy mode entirely. So it would be nice to test this on at least one reasonably old (but not uncomfortably old - say 5 years old) system, to get a feel for what kind of performance impact it has there. But yes, this would enable a nice simplification in the end so I'm all for it as long as it doesn't cause unacceptable problems - and the FPU code needs simplification badly, because the current latency of bug discovery is too high IMO. Thanks, Ingo