All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Rik van Riel <riel@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Yu-cheng Yu <yu-cheng.yu@intel.com>
Subject: Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active
Date: Thu, 26 Jan 2017 16:16:42 +0100	[thread overview]
Message-ID: <20170126151642.GB12274@gmail.com> (raw)
In-Reply-To: <1485441852.15964.49.camel@redhat.com>


* Rik van Riel <riel@redhat.com> wrote:

> On Thu, 2017-01-26 at 12:26 +0100, Ingo Molnar wrote:
> > We want to simplify the FPU state machine by eliminating fpu-
> > >fpregs_active,
> > and we can do that because the two state flags (::fpregs_active and
> > ::fpstate_active) are set essentially together.
> > 
> > The old lazy FPU switching code used to make a distinction - but
> > there's
> > no lazy switching code anymore, we always switch in an 'eager'
> > fashion.
> 
> I've been working for a while now to fix that for
> KVM VCPU threads.
> 
> Currently when we switch to a VCPU thread, we first
> load that thread's userspace FPU context, and then
> soon after we save that, and load the guest side FPU
> context.
> 
> When a VCPU thread goes idle, we also go through
> two FPU context transitions.
> 
> In order to skip the unnecessary FPU context switches
> for VCPU threads, I have been relying on separate
> fpstate_active and fpregs_active states.
> 
> Do you have any ideas on how I could implement that
> kind of change without separate fpstate_active and
> fpregs_active states?

So the vCPU threads have host side FPU (user-space) state - whatever FPU state 
Qemu has?

One solution to that overhead, without complicating the FPU state machine in any 
way, would be to add a facility to drop/reacquire that FPU state.

That should automatically result in zero FPU state switching AFAICS: kernel 
threads don't do FPU state switching either.

The vCPU threads sometimes do return to user-space, when they get some deep 
exception that needs to be handled by Qemu, right? This aspect shouldn't be a big 
problem either, because the regular calling convention is to call (synchronous) 
system calls without holding FPU state, right?

I.e. the vCPU /dev/kvm ioctl() could drop/re-map the FPU state with very little 
overhead (i.e. no full save/restore required in that code path either), when it 
enters/exits vCPU mode.

Thanks,

	Ingo

  reply	other threads:[~2017-01-26 15:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-26 11:26 [PATCH 0/7] x86/fpu: Simplify the FPU state machine Ingo Molnar
2017-01-26 11:26 ` [PATCH 1/7] x86/fpu: Simplify the fpu->last_cpu logic and rename it to fpu->fpregs_cached Ingo Molnar
2017-01-26 14:23   ` Rik van Riel
2017-01-26 14:53     ` Ingo Molnar
2017-01-26 15:05       ` [PATCH] x86/fpu: Unify the naming of the FPU register cache validity flags Ingo Molnar
2017-01-26 15:31         ` Peter Zijlstra
2017-01-26 14:54   ` [PATCH 1/7] x86/fpu: Simplify the fpu->last_cpu logic and rename it to fpu->fpregs_cached Rik van Riel
2017-01-26 15:09     ` Ingo Molnar
2017-01-26 16:51     ` Andy Lutomirski
2017-01-26 11:26 ` [PATCH 2/7] x86/fpu: Simplify fpu->fpregs_active use Ingo Molnar
2017-01-26 16:30   ` Andy Lutomirski
2017-01-26 11:26 ` [PATCH 3/7] x86/fpu: Make the fpu state change in fpu__clear() scheduler-atomic Ingo Molnar
2017-01-26 11:26 ` [PATCH 4/7] x86/fpu: Split the state handling in fpu__drop() Ingo Molnar
2017-01-26 11:26 ` [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active Ingo Molnar
2017-01-26 14:44   ` Rik van Riel
2017-01-26 15:16     ` Ingo Molnar [this message]
2017-01-26 15:45       ` Rik van Riel
2017-01-26 15:53         ` Ingo Molnar
2017-01-26 17:00           ` Andy Lutomirski
2017-01-26 18:04             ` Rik van Riel
2017-01-26 11:26 ` [PATCH 6/7] x86/fpu: Decouple fpregs_activate()/fpregs_deactivate() from fpu->fpregs_active Ingo Molnar
2017-01-26 11:26 ` [PATCH 7/7] x86/fpu: Remove struct fpu::fpregs_active Ingo Molnar

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=20170126151642.GB12274@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yu-cheng.yu@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.