Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935221AbcJQU6g (ORCPT ); Mon, 17 Oct 2016 16:58:36 -0400 Received: from mail-vk0-f51.google.com ([209.85.213.51]:36574 "EHLO mail-vk0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934780AbcJQU61 (ORCPT ); Mon, 17 Oct 2016 16:58:27 -0400 MIME-Version: 1.0 In-Reply-To: <1476734984-13839-4-git-send-email-riel@redhat.com> References: <1476734984-13839-1-git-send-email-riel@redhat.com> <1476734984-13839-4-git-send-email-riel@redhat.com> From: Andy Lutomirski Date: Mon, 17 Oct 2016 13:58:04 -0700 Message-ID: Subject: Re: [PATCH RFC 3/3] x86/fpu: defer FPU state load until return to userspace To: Rik van Riel Cc: "linux-kernel@vger.kernel.org" , Ingo Molnar , Borislav Petkov , Linus Torvalds , Andrew Lutomirski , dave.hansen@intel.linux.com, Thomas Gleixner , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2278 Lines: 59 On Mon, Oct 17, 2016 at 1:09 PM, wrote: > From: Rik van Riel > > Defer loading of FPU state until return to userspace. This gives > the kernel the potential to skip loading FPU state for tasks that > stay in kernel mode, or for tasks that end up with repeated > invocations of kernel_fpu_begin. > > It also increases the chances that a task's FPU state will remain > valid in the FPU registers until it is scheduled back in, allowing > us to skip restoring that task's FPU state altogether. > > This also prepares the ground work for not having to restore > qemu userspace FPU state in KVM VCPU threads, when merely returning > to the host kernel because the guest went idle, or is running a > kernel thread. That functionality will come in a later patch. > > Signed-off-by: Rik van Riel > --- > arch/x86/entry/common.c | 9 +++++++++ > arch/x86/include/asm/fpu/api.h | 5 +++++ > arch/x86/include/asm/fpu/internal.h | 13 +++++-------- > arch/x86/include/asm/thread_info.h | 4 +++- > arch/x86/kernel/fpu/core.c | 28 ++++++++++++++++++++++++---- > arch/x86/kernel/process_32.c | 5 ++--- > arch/x86/kernel/process_64.c | 5 ++--- > 7 files changed, 50 insertions(+), 19 deletions(-) > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c > index bdd9cc59d20f..0c11ee22f90b 100644 > --- a/arch/x86/entry/common.c > +++ b/arch/x86/entry/common.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > > #define CREATE_TRACE_POINTS > #include > @@ -189,6 +190,14 @@ __visible inline void prepare_exit_to_usermode(struct pt_regs *regs) > if (unlikely(cached_flags & EXIT_TO_USERMODE_LOOP_FLAGS)) > exit_to_usermode_loop(regs, cached_flags); > > + /* Reload ti->flags; we may have rescheduled above. */ > + cached_flags = READ_ONCE(ti->flags); Stick this bit in the "if" above, please. > + > + if (unlikely(cached_flags & _TIF_LOAD_FPU)) { > + clear_thread_flag(TIF_LOAD_FPU); > + switch_fpu_return(); > + } > + But I still don't see how this can work correctly with PKRU. --Andy