• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Enabling disabled SIMD operations for kernel...

kpect

Member

Thanks: 3
Messages: 51

#1
Hello,
As some of you may already know SIMD operations are disabled in /sys/conf/kern.mk for kernel:
Code:
#
# For AMD64, we explicitly prohibit the use of FPU, SSE and other SIMD
# operations inside the kernel itself.  These operations are exclusively
# reserved for user applications.
#
.if ${MACHINE_CPUARCH} == "amd64"
CFLAGS.clang+=  -mno-aes -mno-avx
CFLAGS+=        -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float \
                -fno-asynchronous-unwind-tables
INLINE_LIMIT?=  8000
.endif
Just out of curiosity I've removed some of those instructions like this:
Code:
.if ${MACHINE_CPUARCH} == "amd64"
CFLAGS+=        -mcmodel=kernel -mno-red-zone -msoft-float \
                -fno-asynchronous-unwind-tables
INLINE_LIMIT?=  8000
.endif
and so kernel has been built with aes,avx,mmx,sse enabled. The size of kernel became a bit smaller and looks like it boots faster now.
I use the kernel for some time already and haven't noticed any instabilities, crashes and so on. I even managed to rebuild/reinstall the world with new kernel. Plan to use it further.
May someone explain me why SIMD are disabled?
Regards.
 

Crivens

Moderator
Staff member
Moderator

Thanks: 416
Messages: 1,268

#3
Let me tell you what you are doing...

Normal user land code is started with FPU disabled. When the first floating point instruction is executed, the FPU is enabled for that process and this is remembered in the thread information the kernel keeps. Why is that needed? Scheduling between two no-fp threads does not need to save or restore float registers. These are also not saved/reloaded for sys calls or when an interrupt comes along. MMX registers are how big? Now, the kernel does not need to care because no kernel code can change them. Only the scheduler needs to handle them. When you allow for MMX/SSE/... in kernel, each interrupt or syscall needs to save and reload all these special registers, just in case some code touches them.

Edit: the problem is not the interrupt code messing with these regs, but the kernel does not preserve them because it does not need to by default. Using the extra registers will make interrupt handling A LOT more complex and gives nearly no benefits. It may gain you some clock ticks from the code and loose 10 times that at entry/exit code.
Tl.dr.
DON'T try that at home. Or elsewhere. At least not without expecting to shoot yourself in the foot. And head.
 
Last edited: