Disable SIMD (Extra Post)

[utterances-bot]

This is a general purpose comment thread for the “Disable SIMD” extra post.

[luojia65]

Unfortunately for us, the x86_64 architecture uses SSE registers for floating point operations.

Should this SSE be MMX? As is mentioned above,

SSE: ... Instead of re-using the floating point registers, it adds a completely new register set.

and

MMX: ... These registers are just aliases for the registers of the x87 floating point unit.

[phil-opp]

SSE is correct. In 64-bit mode, SSE instructions and registers are used for performing floating point operations by default. I don't know the exact reason why, but I assume that SSE allows more efficient code.

[pqnet]

SSE is used by default by clang (and apparently rustc) when targeting x86_64 because being able to execute some level of SSE instruction (i think SSE2) is a requirement for x86_64 compatibility. Floating point math without SSE has severe performance issues, mostly because of a bad design of the original x87 coprocessor instruction set (which was designed when optimizations of modern cpus did not exist yet). For example, converting a floating point number to an integer without SSE (discarding the decimal part) is a slow operation that flushes pipelines and causes a lot of other bad things.

[phil-opp]

@pqnet Thanks for the info!

We're using software implementations for floating point operations in our kernel, so I assume that it will be even slower than using the x87 coprocessor. However, the performance penalty of saving and restoring the SSE registers on each kernel entry is much higher AFAIK.

[pqnet]

@phil-opp I agree with you. I can't think of any part of the kernel which would require usage of floating point math anyway, and not using SSE registers in kernel code makes system calls faster, and that affects the performance of a system as a whole a lot (which is also the reason for high half kernel design, which allows kernel memory to be always mapped in).

[correabuscar]

Does this mean that I won't have to search for a way to disable floating point via SIMD in the real Linux kernel ? since it doesn't use any floating point math?

Because otherwise, this whole thread makes me ask the question: how do I disable SIMD in the Linux kernel then?

EDIT: There is:

CONFIG_CRYPTO_SIMD=y

# CONFIG_CRYPTO_AEGIS128_AESNI_SSE2 is not set
# CONFIG_CRYPTO_NHPOLY1305_SSE2 is not set
CONFIG_CRYPTO_SHA1_SSSE3=y
CONFIG_CRYPTO_SHA256_SSSE3=y
CONFIG_CRYPTO_SHA512_SSSE3=y
# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set

In /usr/src/linux-6.0.7-gentoo/Documentation/kernel-hacking/hacking.rst I find:

Some Basic Rules
================
...
No floating point or MMX
    The FPU context is not saved; even in user context the FPU state
    probably won't correspond with the current process: you would mess
    with some user process' FPU state. If you really want to do this,
    you would have to explicitly save/restore the full FPU state (and
    avoid context switches). It is generally a bad idea; use fixed point
    arithmetic first.

In /usr/src/linux-6.0.7-gentoo/Documentation/process/howto.rst I find:

HOWTO do Linux kernel development
=================================
...
Introduction
------------
...
The kernel is written using GNU C and the GNU toolchain.  While it
adheres to the ISO C89 standard, it uses a number of extensions that are
not featured in the standard.  The kernel is a freestanding C
environment, with no reliance on the standard C library, so some
portions of the C standard are not supported.  Arbitrary long long
divisions and floating point are not allowed.  

Erm, in /usr/src/linux-6.0.7-gentoo/Documentation/admin-guide/kernel-parameters.txt:

	nofxsr		[BUGS=X86-32] Disables x86 floating point extended
			register save and restore. The kernel will only save
			legacy floating-point registers on task switch.

	noxsave		[BUGS=X86] Disables x86 extended register state save
			and restore using xsave. The kernel will fallback to
			enabling legacy floating-point and sse state.

In /usr/src/linux-6.0.7-gentoo/Documentation/driver-api/uio-howto.rst:

Writing a driver in userspace
=============================

Once you have a working kernel module for your hardware, you can write
the userspace part of your driver. You don't need any special libraries,
your driver can be written in any reasonable language, you can use
floating point numbers and so on. In short, you can use all the tools
and libraries you'd normally use for writing a userspace application.

In /usr/src/linux-6.0.7-gentoo/Documentation/core-api/printk-formats.rst:

The kernel's printf does not support %n. Floating point formats (%e, %f,
%g, %a) are also not recognized, for obvious reasons. Use of any
unsupported specifier or length qualifier results in a WARN and early
return from vsnprintf().

In /usr/src/linux-6.0.7-gentoo/Documentation/core-api/printk-basics.rst:

===========================
Message logging with printk
===========================
...
  - the format string, while largely compatible with C99, doesn't follow the
    exact same specification. It has some extensions and a few limitations
    (no ``%n`` or floating point conversion specifiers).