New Linux Patch Establishes "CONFIG_X86_64_NATIVE" For -march=native Kernel Builds

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • craftkiller
    replied
    Originally posted by ahrs View Post

    It would be a cool feature if /proc/cpuinfo could list the micro-architecture name that GCC would report for -march=native
    This works using clang:
    Code:
    clang -v -fsyntax-only -march=native -x c /dev/null 2>&1 | grep -e '-target-cpu' | sed -e 's|.*-target-cpu \([[:alnum:]]*\) .*|\1|'

    Leave a comment:


  • erniv2
    replied
    Originally posted by ahrs View Post

    You know what features it has because nobody in their right mind builds a kernel with some foreign -march= setting without first checking that the architecture is what you think it is (It would be a cool feature if /proc/cpuinfo could list the micro-architecture name that GCC would report for -march=native)
    No you won´t know it simple example you run a vm and want to compile a kernel, but then some of the cpuid features get filtered by KVM as example the standard kernel will run the native one or v2 v3 v4 kernel will not boot in that vm, thats probably a simplified example but it could happen.

    Leave a comment:


  • Phoronos
    replied
    Originally posted by ahrs View Post
    You know what features it has because nobody in their right mind builds a kernel with some foreign -march= setting without first checking that the architecture is what you think it is (It would be a cool feature if /proc/cpuinfo could list the micro-architecture name that GCC would report for -march=native)
    Your idea is bad, too complex, too prone to errors and bugs... BAD BAD BAD

    Leave a comment:


  • ahrs
    replied
    Originally posted by erniv2 View Post
    He gave an awnser to that, he does not want that complexity cause in the end you can´t know what cpuid features your target cpu has if you cross compile so you use the standard option and if you compile on the same cpu and want to squezze performance you use native.
    You know what features it has because nobody in their right mind builds a kernel with some foreign -march= setting without first checking that the architecture is what you think it is (It would be a cool feature if /proc/cpuinfo could list the micro-architecture name that GCC would report for -march=native)

    Leave a comment:


  • 6SixTy
    replied
    Someone tell Linus that almost every other ISA out there has some version of the x86-64 version levels for as long as they have existed. Personally just very tired of seeing random architecture revisions in the Kconfig.

    Leave a comment:


  • edxposed
    replied
    Unless it is possible to automatically disable compile-time mitigations that are determined to be unaffected based on the native CPU, this seems pointless. People can already do the same thing with KCFLAGS=-march=native.

    Leave a comment:


  • Espionage724
    replied
    Sounds like something that should have existed years ago (figured an appeal for compiling a kernel for your system would also include compiling it tuned to your CPU)

    I either roll with the default out-the-box kernel, or occasionally entertain Liquorix or XanMod for theoretical gaming improvements (can't say I ever noticed anything real-world different vs default with general power saving stuff disabled up to Ubuntu 24.04.1). Haven't had a need to compile my own kernel in years.
    Last edited by Espionage724; 10 December 2024, 05:18 PM.

    Leave a comment:


  • erniv2
    replied
    He gave an awnser to that, he does not want that complexity cause in the end you can´t know what cpuid features your target cpu has if you cross compile so you use the standard option and if you compile on the same cpu and want to squezze performance you use native.

    Leave a comment:


  • intelfx
    replied
    Originally posted by ahrs View Post
    Why limit it just to -march=native instead of including a KConfig for all of the micro-architecture's like graysky's patches do?

    I often build kernels for another machine where I can't use -march=native because that machine is a different architecture but I still want to target for that micro-architecture specifically for whatever 0.1ms extra performance this may give me.
    I dunno, ask Torvalds.

    If he's that cranky about three microarchitecture levels, imagine what's going to happen should someone send him a patch for all possible -marches.

    Leave a comment:


  • ahrs
    replied
    Why limit it just to -march=native instead of including a KConfig for all of the micro-architecture's like graysky's patches do?


    I often build kernels for another machine where I can't use -march=native because that machine is a different architecture but I still want to target for that micro-architecture specifically for whatever 0.1ms extra performance this may give me.

    Leave a comment:

Working...
X