Use of floating point in the Linux kernel

Because...

many programs don't use floating point or don't use it on any given time slice; and

saving the FPU registers and other FPU state takes time; therefore

...an OS kernel may simply turn the FPU off. Presto, no state to save and restore, and therefore faster context-switching. (This is what mode meant, it just meant that the FPU was enabled.)

If a program attempts an FPU op, the program will trap into the kernel, the kernel will turn the FPU on, restore any saved state that may already exist, and then return to re-execute the FPU op.

At context switch time, it knows to actually go through the state save logic. (And then it may turn the FPU off again.)

By the way, I believe the book's explanation for the reason kernels (and not just Linux) avoid FPU ops is ... not perfectly accurate.1

The kernel can trap into itself and does so for many things. (Timers, page faults, device interrupts, others.) The real reason is that the kernel doesn't particularly need FPU ops and also needs to run on architectures without an FPU at all. Therefore, it simply avoids the complexity and runtime required to manage its own FPU context by not doing ops for which there are always other software solutions.

It's interesting to note how often the FPU state would have to be saved if the kernel wanted to use FP . . . every system call, every interrupt, every switch between kernel threads. Even if there was a need for occasional kernel FP,2 it would probably be faster to do it in software.

1. That is, dead wrong. 2. There are a few cases I know about where kernel software contains a floating point arithmetic implementation. Some architectures implement traditional FPU ops in hardware but leave some complex IEEE FP operations to software. (Think: denormal arithmetic.) When some odd IEEE corner case happens they trap to software which contains a pedantically correct emulation of the ops that can trap.

With some kernel designs the floating-point registers are not saved when a "kernel" or "system" task is task-switched out. (This is because the FP registers are large and take both time and space to save.) So if you attempt to use FP the values will go "poof" randomly.

In addition, some hardware floating-point schemes rely on the kernel to handle "oddball" situations (eg, zero division) via a trap, and the required trap mechanism may be at a higher "level" than the kernel task is currently running.

For these reasons (and a couple more) some hardware FP schemes will trap when you use an FP instruction for the first time in a task. If you're permitted to use FP then a floating-point flag is turned on in the task, if not, you're shot by the firing squad.

I'm hitting this result regarding floating point usage in kernelspace. What I'm wondering is, isn't this an "old" implementation (compatibility) because of the older architectures in witch a dedicated FPU is implemented and FPU instructions are outsourced to a physical 'co-processor' having their own pipelines?

I can imagine that such an architecture should handle 'outsourced' instructions differently because of pipeline delays and such, but as I recall the current architectures (Arm.v8) has their IEEE754 instructions as part of the instruction set, not as an external FPU-module. So it can't be turned on or off, nor have the issue of pipeline delays. Yes, probably some CORE register that should be saved/ restored but that seems negligible (compared to overhead of stack management).

In my opinion there's no argument of not using Floats in the kernel. As already said above, it's already used in kernel-space for RAID.