From: "H. Peter Anvin" <hpa@zytor•com>
To: David Miller <davem@davemloft•net>
Cc: bhutchings@solarflare•com, tglx@linutronix•de, mingo@redhat•com,
netdev@vger•kernel.org, linux-net-drivers@solarflare•com,
x86@kernel•org, Linus Torvalds <torvalds@linux-foundation•org>
Subject: Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
Date: Tue, 21 Aug 2012 20:24:18 -0700 [thread overview]
Message-ID: <503450E2.2040504@zytor.com> (raw)
In-Reply-To: <20120821.193446.1534561579811962053.davem@davemloft.net>
On 08/21/2012 07:34 PM, David Miller wrote:
>
> I really hope we eventually get rid of this rediculous restriction the
> x86 code has.
>
> It really needs a proper stack of FPU state saves like sparc64 has.
>
> Half of the code and complexity in arch/x86/crypto/ would just
> disappear, because most of it has to do with handling this obtuse
> FPU usage restriction which shouldn't even be an issue in the first
> place.
>
> I continually see more and more code that has to check this
> irq_fpu_usable() thing, and have ugly fallback code, and therefore is
> a sign that this really needs to be fixed properly.
>
[Cc: Linus, since he has had very strong opinions on this in the past.]
I'm all ears... tell me how sparc64 deals with this, maybe we can
implement something similar. At the same time, do keep in mind that on
x86 this is not just a matter of the FPU state, but the entire "extended
state" which can be very large.
Given the cost of state save/enable, however, nothing is going to change
the need for kernel_fpu_begin/end, nor the fact that those things will
want to bracket large regions.
-hpa
next prev parent reply other threads:[~2012-08-22 3:24 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-22 1:17 [PATCH 0/3] x86_64, sfc: 128-bit memory-mapped I/O Ben Hutchings
2012-08-22 1:20 ` [PATCH 1/3] x86_64: Define 128-bit types for kernel code only Ben Hutchings
2012-08-22 1:23 ` [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations Ben Hutchings
2012-08-22 1:37 ` H. Peter Anvin
2012-08-22 2:04 ` Ben Hutchings
2012-08-22 2:34 ` David Miller
2012-08-22 3:24 ` H. Peter Anvin [this message]
2012-08-22 3:29 ` David Miller
2012-08-22 3:49 ` H. Peter Anvin
2012-08-22 3:52 ` Linus Torvalds
2012-08-22 3:59 ` H. Peter Anvin
2012-08-22 4:14 ` David Miller
2012-08-22 21:14 ` David Miller
2012-08-22 21:28 ` Linus Torvalds
2012-08-22 21:38 ` David Miller
2012-08-22 4:35 ` Linus Torvalds
2012-08-22 5:00 ` David Miller
2012-08-22 14:06 ` Linus Torvalds
2012-08-22 4:42 ` Linus Torvalds
2012-08-22 13:26 ` Ben Hutchings
2012-08-22 14:20 ` Linus Torvalds
2012-08-22 14:24 ` Ben Hutchings
2012-08-22 14:30 ` Benjamin LaHaise
2012-08-22 14:58 ` Ben Hutchings
2012-08-22 15:13 ` H. Peter Anvin
2012-08-22 15:27 ` David Laight
2012-08-22 15:49 ` H. Peter Anvin
2012-08-22 15:51 ` Ben Hutchings
2012-08-22 15:54 ` H. Peter Anvin
2012-08-22 16:44 ` Ben Hutchings
2012-08-22 16:49 ` H. Peter Anvin
2012-08-22 16:55 ` Linus Torvalds
2012-08-22 17:09 ` Ben Hutchings
2012-08-22 17:12 ` H. Peter Anvin
2012-08-22 17:27 ` Ben Hutchings
2012-08-22 17:54 ` Linus Torvalds
2012-08-22 18:11 ` Ben Hutchings
2012-08-22 18:18 ` H. Peter Anvin
2012-08-22 18:28 ` Linus Torvalds
2012-08-22 19:01 ` Ben Hutchings
2012-08-22 17:26 ` Linus Torvalds
2012-08-22 16:51 ` Linus Torvalds
2012-08-22 16:59 ` H. Peter Anvin
2012-08-22 15:51 ` H. Peter Anvin
2012-08-22 14:50 ` Linus Torvalds
2012-08-22 14:56 ` Linus Torvalds
2012-08-22 15:05 ` David Laight
2012-08-22 15:16 ` Linus Torvalds
2012-08-22 15:41 ` Ben Hutchings
2012-08-22 14:42 ` David Laight
2012-08-22 1:26 ` [PATCH 3/3] sfc: Use __raw_writeo() to perform TX descriptor push where possible Ben Hutchings
2012-08-22 1:38 ` [PATCH 0/3] x86_64, sfc: 128-bit memory-mapped I/O H. Peter Anvin
2012-08-22 1:43 ` Ben Hutchings
2012-08-22 1:59 ` H. Peter Anvin
2012-08-22 2:10 ` Ben Hutchings
2012-08-22 2:31 ` H. Peter Anvin
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=503450E2.2040504@zytor.com \
--to=hpa@zytor$(echo .)com \
--cc=bhutchings@solarflare$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=linux-net-drivers@solarflare$(echo .)com \
--cc=mingo@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=tglx@linutronix$(echo .)de \
--cc=torvalds@linux-foundation$(echo .)org \
--cc=x86@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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