From: Linus Torvalds <email@example.com>
Subject: Re: [BK-2.5] Move "used FPU status" into new non-atomic
Date: Mon, 10 Mar 2003 20:12:34 GMT
On Mon, 10 Mar 2003, Chris Friesen wrote:
> > And once you save that part, you're better off saving the registers too,
> > since it's all loaded and saved with the same fxsave/fxrestor instruction
> > (ie we'd actually have to do _more_ work to save only part of the FP
> > state).
> Does this open the door for using FP in the kernel?
Not any wider than it already is.
For a while now, x86-specific optimizations (and all such stuff is by
nature very much architecture-specific) have been able to do
and use the FP state in between. It generally sucks if the user-mode
process had touched FP state (we'll force it saved), but most of the time
that isn't true, and the only thing it does is to temporarily clear the
TS bit so that the FPU works again (and then sets it again in fpu_end,
although if this was a common thing we _could_ make that be a "work"
thing that is only done at return-to-user-mode).
Of course, clearing TS isn't exactly fast, so this really only works if
you have tons of stuff that you _really_ want to use the FPU for. And
since the FP cache is per-CPU, the whole region in question is
non-preemptible, so this can only be used for non-blocking stuff.
In other words: it's still very much a special case, and if the question
was "can I just use FP in the kernel" then the answer is still a
resounding NO, since other architectures may not support it AT ALL.
From: Linus Torvalds <firstname.lastname@example.org>
Subject: Re: How to use floating point in a module?
Date: Mon, 31 May 2004 04:30:51 GMT
On Mon, 31 May 2004, Måns Rullgård wrote:
> Floating point is forbidden in kernel code since the floating point
> registers (and other floating point context) is not saved/restored
> during system calls, for efficiency. I'm speculating here, but it
> might be possible to manually save the floating point context while
> doing some floating point operations. The problem arises if this code
> is interrupted midway. Using a preemptive 2.6 kernel would easily
> break here.
You can do it "safely" on x86 using
and make sure that _all_ the FP stuff is in between those two things, and
that you don't do _anything_ that might fault or sleep.
The kernel_fpu_xxx() macros make sure that preemption is turned off etc,
so the above should always be safe.
Even then, of course, using FP in the kernel assumes that you actually
_have_ an FPU, of course. The in-kernel FP emulation package is _not_
supposed to work with kernel FP instructions.
Oh, and since the kernel doesn't link with libc, you can't use anything
even remotely fancy. It all has to be stuff that gcc can do in-line,
without any function calls.
In other words: the rule is that you really shouldn't use FP in the
kernel. There are ways to do it, but they tend to be for some _real_
special cases, notably for doing MMX/XMM work. Ie the only "proper" FPU
user is actually the RAID checksumming MMX stuff.