From: Hans Rosenfeld <hans.rosenfeld@amd.com>
To: <linux-kernel@vger.kernel.org>
Cc: <x86@kernel.org>, <brgerst@gmail.com>, <robert.richter@amd.com>,
<andreas.herrmann3@amd.com>,
Hans Rosenfeld <hans.rosenfeld@amd.com>
Subject: [RFC 0/2] FPU/xsave rework in preparation for LWP
Date: Tue, 23 Nov 2010 21:41:51 +0100 [thread overview]
Message-ID: <1290544913-489129-1-git-send-email-hans.rosenfeld@amd.com> (raw)
In-Reply-To: <AANLkTinBsut0Csubh1N85jkydH7wCp3YniASE-vyf7MP@mail.gmail.com>
Hi,
please review and comment on these patches. They are based on tip/master
a17d38493c3dd2253828b107b5d405dd7cdcbf43. The first one is just a generic
cleanup of the xsave code that I already sent couple of weeks ago.
When my previous LWP patchset was reviewed I was told that it would be
much better to use only a single call to xsave and xrstor in the context
switch. This is basically what I try to achieve with the second patch:
base all "extended state" management on xsave/xrstor (with fallback to
fxsave/fxrstor or even fsave/frstor) and keep track of which extended
states a thread actually used. The actual LWP support is not included
here, I will work on this next.
As a side effect of this rework, there will be a single simple interface
that can be used by other parts of the kernel that need to save and
restore extended states (thinking of KVM here). This should also improve
the general readability and maintainability of this code, although I
would agree that this isn't visible yet :)
There is a lot of room for cleaning things up here, which I will do
along with the LWP support. The LWP changes will require that each
thread will always have a xstate area, but I don't expect this to be
much of a problem. While this would add an overhead of around 1kb for
each thread that wouldn't need a xstate area otherwise, I expect that
there are only very few such threads on any reasonably modern system. I
will have to check that when the LWP support is done. This would allow
for another big cleanup by removing all the complexity of supporting
threads that don't have an xstate area.
Hans Rosenfeld (2):
x86, xsave: cleanup xsave/xrstor support
x86, xsave: rework xsave support
arch/x86/include/asm/i387.h | 111 +++++++----------------
arch/x86/include/asm/thread_info.h | 2 +
arch/x86/include/asm/xsave.h | 88 ++++++++-----------
arch/x86/kernel/i387.c | 11 ++-
arch/x86/kernel/process_64.c | 24 +++---
arch/x86/kernel/traps.c | 31 +------
arch/x86/kernel/xsave.c | 174 +++++++++++++++++++-----------------
arch/x86/kvm/x86.c | 7 +-
8 files changed, 188 insertions(+), 260 deletions(-)
next prev parent reply other threads:[~2010-11-23 20:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1286212172-654419-1-git-send-email-hans.rosenfeld@amd.com>
2010-10-04 22:13 ` [RFC 0/3] Basic support " Thomas Gleixner
2010-10-05 14:51 ` Hans Rosenfeld
2010-10-05 15:34 ` Thomas Gleixner
2010-10-05 18:27 ` Hans Rosenfeld
2010-10-05 18:30 ` Hans Rosenfeld
2010-10-05 18:30 ` [RFC 1/3] Cleanup xsave/xrstor support Hans Rosenfeld
2010-10-05 18:30 ` [RFC 2/3] Allow saving of individual states in fpu_xsave() Hans Rosenfeld
2010-10-05 18:30 ` [RFC 3/3] Save/restore LWP state in context switches Hans Rosenfeld
2010-10-06 11:12 ` Brian Gerst
2010-10-07 14:58 ` Hans Rosenfeld
2010-11-23 20:41 ` Hans Rosenfeld [this message]
2010-11-23 20:41 ` [RFC 1/2] x86, xsave: cleanup xsave/xrstor support Hans Rosenfeld
2010-11-23 20:41 ` [RFC 2/2] x86, xsave: rework xsave support Hans Rosenfeld
2010-11-25 0:36 ` Brian Gerst
2010-10-05 19:05 ` [RFC 0/3] Basic support for LWP Ingo Molnar
2010-10-06 7:35 ` Robert Richter
[not found] ` <AANLkTi=T0QmcKeZcgcR+GKk-9OwQUB_x8XdHiNuU7tE_@mail.gmail.com>
2010-10-07 10:46 ` Stephane Eranian
2010-10-07 13:59 ` H. Peter Anvin
2010-10-07 14:11 ` Stephane Eranian
2010-10-07 14:20 ` Hans Rosenfeld
2010-10-07 14:20 ` H. Peter Anvin
2010-10-07 14:25 ` Stephane Eranian
2010-10-07 14:47 ` H. Peter Anvin
2010-10-07 15:12 ` Stephane Eranian
2010-10-05 18:43 ` Davidlohr Bueso
2010-10-06 10:26 ` Andi Kleen
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=1290544913-489129-1-git-send-email-hans.rosenfeld@amd.com \
--to=hans.rosenfeld@amd.com \
--cc=andreas.herrmann3@amd.com \
--cc=brgerst@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robert.richter@amd.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
all inboxes | Powered by JetHome®