[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5034591E.3040908@zytor.com>
Date: Tue, 21 Aug 2012 20:59:26 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: David Miller <davem@...emloft.net>, bhutchings@...arflare.com,
tglx@...utronix.de, mingo@...hat.com, netdev@...r.kernel.org,
linux-net-drivers@...arflare.com, x86@...nel.org
Subject: Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
On 08/21/2012 08:52 PM, Linus Torvalds wrote:
>
> That said, we might *try* to make the kernel FPU use be cheaper. We
> could do something like:
>
> - if we need to restore FPU state for user mode, don't do it
> synchronously in kernel_fpu_end(), just set a work-flag, and do it
> just once before returning to user mode
>
> - that makes kernel_fpu_end() a no-op, and while we can't get rid of
> kernel_fpu_begin(), we could at least make it cheap to do many times
> consecutively (ie we'd have to check "who owns FPU state" and perhaps
> save it, but the save would have to be done only the first time).
>
The zeroeth order thing we should do is to make it nest; there are cases
where we do multiple kernel_fpu_begin/_end in sequence for no good reason.
kernel_fpu_end() would still have to re-enable preemption (and
preemption would have to check the work flag), but that should be cheap.
We could allow the FPU in the kernel to have preemption, if we allocated
space for two xstates per thread instead of one. That is, however, a
fair hunk of memory.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists