Linux 内核中浮点的使用

问题描述：

我正在阅读Robert Love的《Linux内核开发》，偶然发现了以下一段话：

不能（轻易）使用浮点

当用户空间进程使用浮点指令时，内核会管理从整数到浮点模式的转换。内核在使用浮点指令时需要执行的操作因架构而异，但内核通常会捕获陷阱，然后启动从整数到浮点模式的转换。

与用户空间不同，内核无法无缝支持浮点数，因为它无法轻易自我捕获。在内核中使用浮点数需要手动保存和恢复浮点寄存器，以及其他可能的杂务。简短的回答是：不要这样做！除了极少数情况外，内核中没有浮点运算。

我从未听说过这些“整数”和“浮点”模式。它们到底是什么，为什么需要它们？这种区别是否存在于主流硬件架构（例如 x86）上，还是特定于某些更奇特的环境？从进程和内核的角度来看，从整数到浮点模式的转换究竟意味着什么？

解决方案 1：

因为...

• 许多程序不使用浮点数，或者在任何给定的时间片上都不使用浮点数；

• 保存 FPU 寄存器和其他 FPU 状态需要时间；因此

...OS 内核可能只是关闭 FPU。很快，就无需保存和恢复状态，因此上下文切换速度更快。（这就是模式的含义，它只是意味着启用了 FPU。）

如果程序尝试执行 FPU 操作，程序将陷入内核，内核将打开 FPU，恢复可能已经存在的任何已保存状态，然后返回重新执行 FPU 操作。

在上下文切换时，它知道实际上要执行状态保存逻辑。（然后它可能会再次关闭 FPU。）

顺便说一句，我认为这本书对内核（而不仅仅是 Linux）避免使用 FPU 操作的原因的解释……并不完全准确。1

内核可以自我陷进，并且会为很多事情这样做。（计时器、页面错误、设备中断等。）真正的原因是内核并不特别需要FPU 操作，也需要在完全没有 FPU 的架构上运行。因此，它只是通过不执行总是有其他软件解决方案的操作来避免管理自己的 FPU 上下文所需的复杂性和运行时间。

有趣的是，如果内核想要使用 FP，需要多久保存一次 FPU 状态……每次系统调用、每次中断、每次内核线程切换。即使偶尔需要内核 FP，2在软件中执行可能也会更快。

1. 也就是说，完全错误。2

. 我知道有几种情况，其中内核软件包含浮点算术实现。 一些架构在硬件中实现传统的 FPU 操作，但将一些复杂的 IEEE FP 操作留给软件。（想想：非规范算术。） 当发生一些奇怪的 IEEE 极端情况时，它们会陷入包含可以捕获的操作的正确模拟的软件中。

解决方案 2：

对于某些内核设计，当“内核”或“系统”任务切换出时，浮点寄存器不会被保存。（这是因为浮点寄存器很大，保存需要时间和空间。）因此，如果您尝试使用浮点，值将随机变为“噗”。

此外，一些硬件浮点方案依赖内核通过陷阱来处理“异常”情况（例如，零除），并且所需的陷阱机制可能比内核任务当前运行的“级别”更高。

由于这些原因（以及其他一些原因），当您在任务中第一次使用 FP 指令时，某些硬件 FP 方案会陷入困境。如果您被允许使用 FP，则任务中的浮点标志会被打开，否则，您将被枪决。

解决方案 3：

我得到了有关内核空间浮点使用情况的这个结果。我想知道的是，这是否是一种“旧”实现（兼容性），因为较旧的架构中实现了专用的 FPU，并且 FPU 指令外包给具有自己管道的物理“协处理器”？

我可以想象，由于流水线延迟等原因，这种架构应该以不同的方式处理“外包”指令，但我记得当前架构（Arm.v8）的 IEEE754 指令是指令集的一部分，而不是外部 FPU 模块。因此它无法打开或关闭，也不会出现流水线延迟的问题。是的，可能有一些 CORE 寄存器应该保存/恢复，但这似乎可以忽略不计（与堆栈管理的开销相比）。

我认为内核中没有不使用浮点数的理由。如上所述，它已在内核空间中用于 RAID。