From: Paolo Bonzini <pbonzini@redhat.com>
To: Rik van Riel <riel@redhat.com>, linux-kernel@vger.kernel.org
Cc: dave.hansen@linux.intel.com, x86@kernel.org, tglx@linutronix.de,
mingo@redhat.com, luto@kernel.org, pa@zytor.com, bp@suse.de
Subject: Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode
Date: Wed, 5 Oct 2016 16:03:49 +0200 [thread overview]
Message-ID: <cf59408b-7b30-4eae-874f-d4be9b3484be@redhat.com> (raw)
In-Reply-To: <1475675843.11869.8.camel@redhat.com>
On 05/10/2016 15:57, Rik van Riel wrote:
> On Wed, 2016-10-05 at 09:14 +0200, Paolo Bonzini wrote:
>>
>> On 05/10/2016 02:34, riel@redhat.com wrote:
>>>
>>> From: Andy Lutomirski <luto@kernel.org>
>>>
>>> Since commit 58122bf1d856 ("x86/fpu: Default eagerfpu=on on all
>>> CPUs") in Linux 4.6, eager FPU mode has been the default on all x86
>>> systems, and no one has reported any regressions.
>>>
>>> This patch removes the ability to enable lazy mode: use_eager_fpu()
>>> becomes "return true" and all of the FPU mode selection machinery
>>> is
>>> removed.
>>
>> I haven't quite followed up on my promise to benchmark lazy vs. eager
>> FPU, but I probably should do that now...
>>
>> I see two possible issues with this. First, AMD as far as I know does
>> not have XSAVEOPT. Second, when using virtualization, depending on
>> how you configure your cluster it's enough to have one pre-SandyBridge
>> Intel machine to force no XSAVE on all machines.
>
> The "OPT" part of XSAVEOPT does not work across the
> host/guest boundary, anyway.
Yes, but it works for bare metal (and in fact eager FPU was keyed on
XSAVEOPT before 58122bf1d856, not XSAVE).
I'm not talking about KVM here; I am just saying that the lazy FPU code
might be used more than we'd like to, because of AMD machines and of
cases where XSAVE is hidden altogether from guests. Of course it is
quite unlikely that it be reported as a regression, since things just
work. But as far as I know 58122bf1d856 went in without any substantial
(or not-so-substantial) benchmarking.
Paolo
next prev parent reply other threads:[~2016-10-05 14:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-05 0:34 [PATCH 0/9] x86/fpu: remove lazy FPU mode & various FPU cleanups riel
2016-10-05 0:34 ` [PATCH 1/9] x86/crypto: Remove X86_FEATURE_EAGER_FPU ifdef from the crc32c code riel
2016-10-05 0:40 ` Rik van Riel
2016-10-07 9:43 ` [tip:x86/fpu] x86/crypto, x86/fpu: Remove X86_FEATURE_EAGER_FPU #ifdef " tip-bot for Andy Lutomirski
2016-10-05 0:34 ` [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode riel
2016-10-05 7:14 ` Paolo Bonzini
2016-10-05 13:57 ` Rik van Riel
2016-10-05 14:03 ` Paolo Bonzini [this message]
2016-10-05 15:59 ` Andy Lutomirski
2016-10-05 16:09 ` Paolo Bonzini
2016-10-07 9:43 ` [tip:x86/fpu] x86/fpu: Hard-disable lazy FPU mode tip-bot for Andy Lutomirski
2016-10-05 0:34 ` [PATCH 3/9] x86/fpu: Remove the XFEATURE_MASK_EAGER/LAZY distinction riel
2016-10-07 9:44 ` [tip:x86/fpu] " tip-bot for Andy Lutomirski
2016-10-05 0:34 ` [PATCH 4/9] x86/fpu: Remove use_eager_fpu() riel
2016-10-07 9:44 ` [tip:x86/fpu] " tip-bot for Andy Lutomirski
2016-10-05 0:34 ` [PATCH 5/9] x86/fpu: remove fpu.counter riel
2016-10-05 2:07 ` Andy Lutomirski
2016-10-07 9:45 ` [tip:x86/fpu] x86/fpu: Remove struct fpu::counter tip-bot for Rik van Riel
2016-10-05 0:34 ` [PATCH 6/9] x86/fpu,kvm: remove kvm vcpu->fpu_counter riel
2016-10-07 9:45 ` [tip:x86/fpu] x86/fpu, kvm: Remove KVM vcpu->fpu_counter tip-bot for Rik van Riel
2016-10-05 0:34 ` [PATCH 7/9] x86/fpu: rename lazy restore functions to "register state valid" riel
2016-10-05 2:09 ` Andy Lutomirski
2016-10-07 9:46 ` [tip:x86/fpu] x86/fpu: Rename " tip-bot for Rik van Riel
2016-10-05 0:34 ` [PATCH 8/9] x86/fpu: remove __fpregs_(de)activate riel
2016-10-05 2:10 ` Andy Lutomirski
2016-10-07 9:46 ` [tip:x86/fpu] x86/fpu: Remove __fpregs_(de)activate() tip-bot for Rik van Riel
2016-10-05 0:34 ` [PATCH 9/9] x86/fpu: split old & new fpu code paths riel
2016-10-07 9:47 ` [tip:x86/fpu] x86/fpu: Split old & new FPU " tip-bot for Rik van Riel
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=cf59408b-7b30-4eae-874f-d4be9b3484be@redhat.com \
--to=pbonzini@redhat.com \
--cc=bp@suse.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pa@zytor.com \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--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
all inboxes | Powered by JetHome®