[bug] [kernel] Extra CPU optimizations not used for the case of `-march=native`

[cuantar]

The patches are added and the extra CPU optimizations are available in make menuconfig, but the default config is not using them for the case that -march=native is specified either by defining CFLAGS directly in make.conf, or by ego profile subarch native_64.

The ebuild simply looks up the subarch string and then attempts to set CONFIG_${SUBARCH} in the kernel config. The kernel distinguishes between Intel and AMD native optimizations and our profiles don't, so it could be that we can't use -march=native here like this.

For example, CONFIG_SKYLAKE is valid, but CONFIG_NATIVE does not exist; instead there are CONFIG_MNATIVE_{INTEL,AMD}. A warning in menuconfig advises that they are not interchangeable.

To really fix this, we'll need to figure out whether a given machine has an AMD or Intel CPU and set the correct config option.

[cuantar]

This is the method by which the ebuild obtains the march setting: python3 -c "import portage; print(portage.settings[\"CFLAGS\"])" | sed 's/ /\n/g' | grep "march"

For the generic_64-vN, N in {1..4}, optimization levels, portage outputs x86-64-vN as expected by the kernel build tools, so there's nothing needed here.

[cuantar]

Maybe can use something like grep vendor /proc/cpuinfo | uniq | cut -d ':' -f 2 in the ebuild, and test the result for the presence of AMD or Intel after lowercasing it: vendor=$(grep vendor /proc/cpuinfo | uniq | cut -d ':' -f 2); echo ${vendor,,}

[cuantar]

get_vendor() {
    vendor=$(grep vendor /proc/cpuinfo | uniq | cut -d ':' -f 2)
    [[ ${vendor^^} =~ (INTEL)|(AMD) ]] && echo ${BASH_REMATCH[0]}
}

That was fun!

Doesn't work on arm but there will be an error earlier than that, because the debian-sources doesn't support it. We'll have armbian-sources for that...

[cuantar]

A fix for this is in my tree.

[cuantar]