linux-kernel - Re: [RFC PATCH 06/11] x86,fpu: lazily skip fpu restore with eager fpu mode, too

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrWWLzdPrmGdw7+g68Sy2m9Fs6U5nO3dWAOHt8XAxXSb3g@mail.gmail.com>
Date:	Tue, 13 Jan 2015 09:11:17 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Rik van Riel <riel@...hat.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Matt Fleming <matt.fleming@...el.com>,
	Borislav Petkov <bp@...e.de>, Oleg Nesterov <oleg@...hat.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH 06/11] x86,fpu: lazily skip fpu restore with eager fpu
 mode, too

On Sun, Jan 11, 2015 at 1:46 PM,  <riel@...hat.com> wrote:
> From: Rik van Riel <riel@...hat.com>
>
> If the next task still has its FPU state present in the FPU registers,
> there is no need to restore it from memory.
>
> This is no big deal on bare metal, where XSAVEOPT / XRSTOR are heavily
> optimized, but those optimizations do not carry across VMENTER / VMEXIT.
>
> Skipping the call to fpu_restore_checking when the FPU state is already
> loaded in the CPU could save a little bit of overhead on bare metal too,
> so this is not just a KVM optimization.
>
> Signed-off-by: Rik van Riel <riel@...hat.com>
> ---
>  arch/x86/include/asm/fpu-internal.h | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/include/asm/fpu-internal.h b/arch/x86/include/asm/fpu-internal.h
> index 4db8781..a5a40c7 100644
> --- a/arch/x86/include/asm/fpu-internal.h
> +++ b/arch/x86/include/asm/fpu-internal.h
> @@ -435,13 +435,9 @@ static inline void switch_fpu_prepare(struct task_struct *old, struct task_struc
>                 old->thread.fpu.last_cpu = ~0;
>                 if (preload) {
>                         new->thread.fpu_counter++;
> -                       if (!use_eager_fpu() && fpu_lazy_restore(new, cpu))
> -                               /* XXX: is this safe against ptrace??? */
> -                               __thread_fpu_begin(new);
> -                       else {
> +                       set_thread_flag(TIF_LOAD_FPU);
> +                       if (!fpu_lazy_restore(new, cpu))
>                                 prefetch(new->thread.fpu.state);

Is this prefetch still worth keeping?  Wouldn't prefetching the fpu
effectively require grabbing more than one cacheline anyway?

--Andy

> -                               set_thread_flag(TIF_LOAD_FPU);
> -                       }
>                 } else
>                         /*
>                          * The new task does not want an FPU state restore,
> @@ -466,6 +462,10 @@ static inline void switch_fpu_finish(void)
>
>         __thread_fpu_begin(tsk);
>
> +       /* The FPU registers already have this task's FPU state. */
> +       if (fpu_lazy_restore(tsk, raw_smp_processor_id()))
> +               return;
> +
>         if (unlikely(restore_fpu_checking(tsk)))
>                 drop_init_fpu(tsk);
>  }
> --
> 1.9.3
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/