linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	"Andy Lutomirski" <luto@kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	kvm@vger.kernel.org, "Jason A. Donenfeld" <Jason@zx2c4.com>,
	"Rik van Riel" <riel@surriel.com>
Subject: Re: [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace
Date: Wed, 12 Sep 2018 08:47:19 -0700	[thread overview]
Message-ID: <650FC457-7E4C-473A-9E5F-EAFC74F6444B@amacapital.net> (raw)
In-Reply-To: <20180912133353.20595-11-bigeasy@linutronix.de>


> On Sep 12, 2018, at 6:33 AM, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
> From: Rik van Riel <riel@surriel.com>
> 
> 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.
> 
> 

> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
> 
>    kernel_fpu_disable();
> 
> -    if (fpu->initialized) {
> +    __cpu_invalidate_fpregs_state();
> +
> +    if (!test_and_set_thread_flag(TIF_LOAD_FPU)) {

Since the already-TIF_LOAD_FPU path is supposed to be fast here, use test_thread_flag() instead. test_and_set operations do unconditional RMW operations and are always full barriers, so they’re slow.

Also, on top of this patch, there should be lots of cleanups available. In particular, all the fpu state accessors could probably be reworked to take TIF_LOAD_FPU into account, which would simplify the callers and maybe even the mess of variables tracking whether the state is in regs.

  reply	other threads:[~2018-09-12 15:47 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 13:33 [RFC PATCH] x86: load FPU registers on return to userland Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 01/10] x86/entry: remove _TIF_ALLWORK_MASK Sebastian Andrzej Siewior
2018-09-27 14:21   ` Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 02/10] kvm: x86: make kvm_{load|put}_guest_fpu() static Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 03/10] x86/fpu: add (__)make_fpregs_active helpers Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 04/10] x86/fpu: eager switch PKRU state Sebastian Andrzej Siewior
2018-09-12 14:18   ` Paolo Bonzini
2018-09-12 15:24     ` Andy Lutomirski
2018-09-12 15:30       ` Paolo Bonzini
2018-09-14 20:35     ` [RFC PATCH 04/10 v2 ] " Sebastian Andrzej Siewior
2018-09-17  8:37       ` Paolo Bonzini
2018-09-18 14:27         ` Sebastian Andrzej Siewior
2018-09-18 15:07           ` Paolo Bonzini
2018-09-18 15:11             ` Rik van Riel
2018-09-18 15:29               ` Paolo Bonzini
2018-09-18 16:04                 ` Sebastian Andrzej Siewior
2018-09-18 17:29                   ` Rik van Riel
2018-09-19  5:55                     ` Paolo Bonzini
2018-09-19 16:57                       ` Sebastian Andrzej Siewior
2018-09-19 17:00                         ` Paolo Bonzini
2018-09-19 17:19                           ` Sebastian Andrzej Siewior
2018-09-19 19:38                           ` Rik van Riel
2018-09-19 19:49                           ` Andy Lutomirski
2018-09-12 15:20   ` [RFC PATCH 04/10] " Andy Lutomirski
2018-09-12 15:30     ` Rik van Riel
2018-09-12 15:49       ` Andy Lutomirski
2018-09-19 16:58         ` Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 05/10] x86/pkeys: Drop the preempt-disable section Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 06/10] x86/fpu: Always store the registers in copy_fpstate_to_sigframe() Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 07/10] x86/entry: add TIF_LOAD_FPU Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 08/10] x86/fpu: prepare copy_fpstate_to_sigframe for TIF_LOAD_FPU Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 09/10] x86/fpu: copy non-resident FPU state at fork time Sebastian Andrzej Siewior
2018-09-12 13:33 ` [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace Sebastian Andrzej Siewior
2018-09-12 15:47   ` Andy Lutomirski [this message]
2018-09-19 17:05     ` Sebastian Andrzej Siewior
2018-09-21  3:45       ` Andy Lutomirski
2018-09-21  4:15         ` Andy Lutomirski
2018-09-26 11:12           ` Sebastian Andrzej Siewior
2018-09-26 14:34             ` Andy Lutomirski
2018-09-26 15:32               ` Sebastian Andrzej Siewior
2018-09-26 16:24                 ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=650FC457-7E4C-473A-9E5F-EAFC74F6444B@amacapital.net \
    --to=luto@amacapital.net \
    --cc=Jason@zx2c4.com \
    --cc=bigeasy@linutronix.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=riel@surriel.com \
    --cc=rkrcmar@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).