From: Avi Kivity <avi@redhat.com>
To: Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/4] Really lazy fpu
Date: Sun, 13 Jun 2010 18:03:43 +0300 [thread overview]
Message-ID: <1276441427-31514-1-git-send-email-avi@redhat.com> (raw)
Currently fpu management is only lazy in one direction. When we switch into
a task, we may avoid loading the fpu state in the hope that the task will
never use it. If we guess right we save an fpu load/save cycle; if not,
a Device not Available exception will remind us to load the fpu.
However, in the other direction, fpu management is eager. When we switch out
of an fpu-using task, we always save its fpu state.
This is wasteful if the task(s) that run until we switch back in all don't use
the fpu, since we could have kept the task's fpu on the cpu all this time
and saved an fpu save/load cycle. This can be quite common with threaded
interrupts, but will also happen with normal kernel threads and even normal
user tasks.
This patch series converts task fpu management to be fully lazy. When
switching out of a task, we keep its fpu state on the cpu, only flushing it
if some other task needs the fpu.
Open issues/TODO:
- patch 2 enables interrupts during #NM. There's a comment that says
it shouldn't be done, presumably because of old-style #FERR handling.
Need to fix one way or the other (dropping #FERR support, eagerly saving
state when #FERR is detected, or dropping the entire optimization on i386)
- flush fpu state on cpu offlining (trivial)
- make sure the AMD FXSAVE workaround still works correctly
- reduce IPIs by flushing fpu state when we know a task is being migrated
(guidance from scheduler folk appreciated)
- preemptible kernel_fpu_begin() to improve latency on raid and crypto setups
(will post patches)
- lazy host-side kvm fpu management (will post patches)
- accelerate signal delivery by allocating signal handlers their own fpu
state, and letting them run with the normal task's fpu until they use
an fp instruction (will generously leave to interested parties)
Avi Kivity (4):
x86, fpu: merge __save_init_fpu() implementations
x86, fpu: run device not available trap with interrupts enabled
x86, fpu: Let the fpu remember which cpu it is active on
x86, fpu: don't save fpu state when switching from a task
arch/x86/include/asm/i387.h | 126 +++++++++++++++++++++++++++++++++-----
arch/x86/include/asm/processor.h | 4 +
arch/x86/kernel/i387.c | 3 +
arch/x86/kernel/process.c | 1 +
arch/x86/kernel/process_32.c | 12 +++-
arch/x86/kernel/process_64.c | 13 +++--
arch/x86/kernel/traps.c | 13 ++---
7 files changed, 139 insertions(+), 33 deletions(-)
next reply other threads:[~2010-06-13 15:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-13 15:03 Avi Kivity [this message]
2010-06-13 15:03 ` [PATCH 1/4] x86, fpu: merge __save_init_fpu() implementations Avi Kivity
2010-06-13 15:03 ` [PATCH 2/4] x86, fpu: run device not available trap with interrupts enabled Avi Kivity
2010-06-13 15:03 ` [PATCH 3/4] x86, fpu: Let the fpu remember which cpu it is active on Avi Kivity
2010-06-13 15:03 ` [PATCH 4/4] x86, fpu: don't save fpu state when switching from a task Avi Kivity
2010-06-13 20:45 ` [PATCH 0/4] Really lazy fpu Valdis.Kletnieks
2010-06-14 7:47 ` Avi Kivity
2010-06-16 7:24 ` Avi Kivity
2010-06-16 7:32 ` H. Peter Anvin
2010-06-16 8:02 ` Avi Kivity
2010-06-16 8:39 ` Ingo Molnar
2010-06-16 9:01 ` Samuel Thibault
2010-06-16 9:43 ` Avi Kivity
2010-06-16 9:10 ` Nick Piggin
2010-06-16 9:30 ` Avi Kivity
2010-06-16 9:28 ` Avi Kivity
-- strict thread matches above, loose matches on Subject: below --
2010-06-16 11:32 George Spelvin
2010-06-16 11:46 ` Avi Kivity
2010-06-17 9:38 ` George Spelvin
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=1276441427-31514-1-git-send-email-avi@redhat.com \
--to=avi@redhat.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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).