From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754611AbbE2BGD (ORCPT ); Thu, 28 May 2015 21:06:03 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:33058 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752079AbbE2BFz (ORCPT ); Thu, 28 May 2015 21:05:55 -0400 MIME-Version: 1.0 In-Reply-To: <55674157.4070108@sr71.net> References: <20150527183609.964CC3BA@viggo.jf.intel.com> <20150527183610.56178C96@viggo.jf.intel.com> <20150528084140.GA31719@gmail.com> <556729FE.1020007@sr71.net> <20150528150114.GA10146@gmail.com> <55674157.4070108@sr71.net> From: Andy Lutomirski Date: Thu, 28 May 2015 18:05:33 -0700 Message-ID: Subject: Re: [PATCH 02/19] x86, fpu: Wrap get_xsave_addr() to make it safer To: Dave Hansen Cc: Ingo Molnar , "linux-kernel@vger.kernel.org" , X86 ML , Thomas Gleixner , Dave Hansen , Oleg Nesterov , Borislav Petkov , Rik van Riel , Suresh Siddha , Ingo Molnar , "H. Peter Anvin" , Fenghua Yu , Linus Torvalds , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 28, 2015 at 9:24 AM, Dave Hansen wrote: > On 05/28/2015 08:01 AM, Ingo Molnar wrote: >> But the real question is: can we support in-use MPX with asynchronous lazy >> restore, while it's still semantically correct? I don't think so, unless you add >> MPX specific synchronous restore to the context switch path, which isn't such a >> good idea IMHO. > > Right now, we assume that the first use of the FPU gets an #ND exception > to tell us that someone is using the FPU. MPX doesn't generate #ND, > thus the need to do it eagerly. > > On CPUs that support it we could, instead, do an xgetbv during the > context switch to ensure that all things having an xstate/xfeature but > that do not generate #ND exceptions are in their init state. If they > are not in their init state, we exit lazy mode. > > We could theoretically use the same kind of thing with the compacted > xsave format to ensure that we only allocate enough space for what we > *need* in the xsave buffer and not allocate for the worst-case. AVX512 > has 32x512-bit registers (2kbytes) and it would be a bit of a shame to > need to allocate ~3k of space. I understand the point of this type of optimization (except that I really don't like the idea of sending SIGBUS or whatever if we fail an allocation at context switch time), but why are we even considering trying to support MPX and lazy fpu at the same time? Judging from all the bug reports, it seems like it's a giant mess, and the code to support lazy restore is not exactly pretty. I would propose that we take the opposite approach and just ban eagerfpu=off when MPX is enabled. We could then take the next step and default eagerfpu=on for everyone and, if nothing breaks, then just delete lazy mode entirely. I suspect we'd have to go back to Pentium 3 or earlier to find a CPU on which lazy mode is actually a good idea. Fiddling with CR0 and handling exceptions is really slow, and I think we should trust CPUs with XSAVEOPT support to do their job and let the older CPUs take the small performance hit, if it even is a performance hit. --Andy -- Andy Lutomirski AMA Capital Management, LLC