dkms modules not compiled with march=x86-64-v3 #270
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have installed linux-lts from v3 repo:
But when the zfs dkms modul is compiled it is not inheriting that march value but rather is compiled with just -march=x86-64:
root 13129 13123 99 16:48 pts/1 00:00:00 /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/cc1 -quiet -nostdinc -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D CC_USING_FENTRY -D MODULE -D CONFIG_MODULES -D KBUILD_BASENAME="config_zlib_inflate" -D KBUILD_MODNAME="config_zlib_inflate" -D __KBUILD_MODNAME=kmod_config_zlib_inflate -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -MMD /var/lib/dkms/zfs/2.3.0/build/build/config_zlib_inflate/.config_zlib_inflate.o.d /var/lib/dkms/zfs/2.3.0/build/build/config_zlib_inflate/config_zlib_inflate.c -quiet -dumpdir /var/lib/dkms/zfs/2.3.0/build/build/config_zlib_inflate/ -dumpbase config_zlib_inflate.c -dumpbase-ext .c -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -mharden-sls=all -mrecord-mcount -mfentry -march=x86-64 ...This is not the case for linux-tkg kernel or linux-cachyos-lts. Those kernels both inherit the march value to the zfs dkms module.
Why is that not happening for the ALHP kernel?
dkms modules not compiled with march=x86-64-v3’to dkms modules not compiled with march=x86-64-v3Haven't had the time to do full research on this, but it may be due to how we enable vN in the kernel. If CachyOS and tkg use patched Kconfigs, then dkms modules probably inherit these options. Since we use
KCFLAGS, they are probably not inherited.If that is the case it is bad. Modules which do compression or encryption for example, have a big benefit from
-march=x86-64-v3They are normally not out of tree :)
All what dkms does is out-of-tree by definition. Does that mean the ALHP kernels are not supporting dkms? Thats a pity.
But not all what is out of tree is performance critical. I would not go as far as saying "dkms is not supported", that implies that dkms would not work, which is not the case at all. The user is responsible for setting any options they want, yes. With our current way of kernel compiling that's not avoidable.
If anyone wants to add an automated way of patching via Kconfigs, I'm always open to PRs.
ok. But what that means is, that ALHP does not help to create a Linux environment full of
-march=x86-64-v3. I can install the ALHP packages with-march=x86-64-v3and I can edit /etc/makepkg.conf to make use of-march=x86-64-v3for AUR packages. But then all DKMS modules will still be using only-march=x86-64. From my point of view tht is a bug in the AHLP kernels. Users are better off using the cachyos or linux-tkg kernels.You can use whatever kernels you like, it's not like we have a warning somewhere, recommending against that.
You won't have that with any of the available options, since not all packages actually compile fine on all feature levels (especially with
-O3). If you really need to compile every DKMS module with these options, set the env correctly or use a different kernel.Since this requires kernel patches, this will not be fixed. If anyone does come up with a low/free maintenance fix for this, PRs are open.