4 ms·

Cool stuff! I just learned that the Kernel does not have floating point on by default (although as the article describes, can run in floating point mode). This

by wespiser_2018 6y ago

Cool stuff! I just learned that the Kernel does not have floating point on by default (although as the article describes, can run in floating point mode). This means TCP/IP algorithms, like TCP Cubic congestion control, are on their own to figure out floating point: https://www.cs.princeton.edu/courses/archive/fall16/cos561/papers/Cubic08.pdf https://www.cs.princeton.edu/courses/archive/fall16/cos561/p...

KMag 6y ago
That depends on the hardware and the kernel, of course. I believe Linux has always required wrapping in-kernel FPU operations in calls to kernel_fpu_begin()/kernel_fpu_end(). As I remember, when Itanium first came out, some floating point algorithms in the Linux kernel were changed to fixed-point, because the (at least early) Itanium FPU handled some corner cases (presumably, denormalized) by trapping to the kernel ("floating point assist fault") and requiring the kernel to emulate the faulting instruction in software. The function to enable in-kernel FPU disabled interrupts, which would have caused issues if the FPU needed assist. The other option (I think) for Itanium would have been to throw out IEEE-754 conformance for in-kernel floating point and have kernel_fpu_begin set the FPU mode bit that just truncated all denormals to zero. I'm not sure the arguments for not doing this, other than fixed point being faster on most architectures and available everywhere, so supporting Itanium was a good excuse to banish a few more uses of kernel_fpu_begin().
- MaxBarraclough 6y ago
  Given the existence of kernel_fpu_begin(), any idea why that TCP paper says this? > Since it requires a floating point operation, implementing it in the kernel requires some integer approximation This line seems to be ignoring both kernel_fpu_begin(), and software floating point, unless I'm just missing something.
  - KMag 6y ago
    Portably and efficiently implementing it in the kernel still requires a fixed point (integer operations) approximation. I'm sure the authors were using "necessary" in the sense of practicality, not in the sense of "impossible otherwise". If they used fp in the kernel, it wouldn't work on some hardware that is supported on Linux (requiring conditional compilation). If they emulated floating point, even single precision IEEE-754 multiplication would require 24bit x 24bit -> 48bit multiplies, and supporting denormals would require 48-bit bit scans and variable-width shifts. It all gets very slow in a hurry (oxymoron intended) on hardware with 32-bit integer hardware and no hw fp. They could choose to emulate some non-IEEE-754 fp format that's slightly more efficient... but that sounds needlessly complex for little to no benefit. So, their remaining option is to use fixed point operations. It's all noisy approximations with TCP in the real world anyway, so I doubt that there's a measurable difference in throughput when using the fixed-point approximation models vs. using the floating point approximation models. As an added bonus, they get consistent results across architectures. Though I think that all supported hardware that has hw fp uses that hardware in a mode that at least close to IEEE-754 compliance, so differences would be tiny. Some hardware supports both IBM format floating point and IEEE-754. As far as I know, the Linux VAX port was never completed. IBM and VAX are the main non-IEEE-754 floating point formats encountered outside of GPUs/TPUs. Edit: or maybe they meant "necessary" in the "Linus will ban me for life if I submit such a silly patch" sense.

KMag 6y ago

That depends on the hardware and the kernel, of course. I believe Linux has always required wrapping in-kernel FPU operations in calls to kernel_fpu_begin()/kernel_fpu_end(). As I remember, when Itanium first came out, some floating point algorithms in the Linux kernel were changed to fixed-point, because the (at least early) Itanium FPU handled some corner cases (presumably, denormalized) by trapping to the kernel ("floating point assist fault") and requiring the kernel to emulate the faulting instruction in software. The function to enable in-kernel FPU disabled interrupts, which would have caused issues if the FPU needed assist. The other option (I think) for Itanium would have been to throw out IEEE-754 conformance for in-kernel floating point and have kernel_fpu_begin set the FPU mode bit that just truncated all denormals to zero. I'm not sure the arguments for not doing this, other than fixed point being faster on most architectures and available everywhere, so supporting Itanium was a good excuse to banish a few more uses of kernel_fpu_begin().

MaxBarraclough 6y ago
Given the existence of kernel_fpu_begin(), any idea why that TCP paper says this? > Since it requires a floating point operation, implementing it in the kernel requires some integer approximation This line seems to be ignoring both kernel_fpu_begin(), and software floating point, unless I'm just missing something.
- KMag 6y ago
  Portably and efficiently implementing it in the kernel still requires a fixed point (integer operations) approximation. I'm sure the authors were using "necessary" in the sense of practicality, not in the sense of "impossible otherwise". If they used fp in the kernel, it wouldn't work on some hardware that is supported on Linux (requiring conditional compilation). If they emulated floating point, even single precision IEEE-754 multiplication would require 24bit x 24bit -> 48bit multiplies, and supporting denormals would require 48-bit bit scans and variable-width shifts. It all gets very slow in a hurry (oxymoron intended) on hardware with 32-bit integer hardware and no hw fp. They could choose to emulate some non-IEEE-754 fp format that's slightly more efficient... but that sounds needlessly complex for little to no benefit. So, their remaining option is to use fixed point operations. It's all noisy approximations with TCP in the real world anyway, so I doubt that there's a measurable difference in throughput when using the fixed-point approximation models vs. using the floating point approximation models. As an added bonus, they get consistent results across architectures. Though I think that all supported hardware that has hw fp uses that hardware in a mode that at least close to IEEE-754 compliance, so differences would be tiny. Some hardware supports both IBM format floating point and IEEE-754. As far as I know, the Linux VAX port was never completed. IBM and VAX are the main non-IEEE-754 floating point formats encountered outside of GPUs/TPUs. Edit: or maybe they meant "necessary" in the "Linus will ban me for life if I submit such a silly patch" sense.