Linux 4.17 Kernel Patch Brings -march=native Support

[geearf]

From what I understand, this is just the graysky patch set going into upstream, so other distros can use it without sourcing the patch set from somewhere else.

It's unlikely to go upstream it's already been proposed and refused.

[GraysonPeddie]

Michael I think you accidentally a few words .

He's not a proof-reader by any stretch, eh?

[moltonel]

AFAICS it's just been (re)posted to lkml but no reply yet: https://lkml.org/lkml/2018/6/4/988 ?
I couldn't find the refusal emails to the original post in 2017. I wonder what was the reason, as it seems like an obvious improvement for anybody compiling their own kernel (your distro's binary package will never use it).

For the record, Gentoo users must enable USE=experimental to apply the patch, and then select the corresponding "processor familly" in the kernel config before rebuilding.

I've been using since around the spectre/meltdown time when I last revisited my kernel build. Works fine but I never benchmarked it.
Maybe if phoronix benches it and it proves noticable, upstream will be more enclined to merge it ?

[dimko]

AFAIK, the work here has been in place on Gentoo already; it's just that the Gentoo user made a patch available upstream to make it more generally available.
As for Linux 4.17 kernel, you should look for other items in the changelog, IMO.
Either way, nice to see some positive news this week, with respect to OpenSource.

Welp: based on the info shown, it's actually relevant and exciting to Gentoo users as well, after all

The options in kernel menu config --> Processor Type and Features --> Processor Family now have an expanded list of CPUs.

Perhaps, the thing is, I am Nvidia user, so its not like Mesa/AMD updates will be super useful to me(if any).
I am curious about this new scheduler. But I already made my own script for games to change scheduler on CPU every time I start game and change back once I am done with it.

[geearf]

AFAICS it's just been (re)posted to lkml but no reply yet: https://lkml.org/lkml/2018/6/4/988 ?
I couldn't find the refusal emails to the original post in 2017. I wonder what was the reason, as it seems like an obvious improvement for anybody compiling their own kernel (your distro's binary package will never use it).

Simply because it hardly gives any advantage to only a few users/
Here's the link: https://lkml.org/lkml/2012/12/5/421

[Royi]

Is there something similar in Ubuntu 1604 repositories?

[moltonel]

Simply because it hardly gives any advantage to only a few users

Linux is full of complex optimisations for narrow usecases. What would be overkill in most projects is business as usual in Linux.

This march=native patch is not particulary complex, it's a low-hanging fruit optimisation, and has active and interested users. Linux 4.17 has dozens of --march settings for specific x86_64 cpus, mostly targeting people who build their own kernel (as they are too specific to be distro configs). Most users of those flags would happily switch to a --march=native flag.

If version doesn't go thru, it'll be for technical reasons, not lack of interest/usefulness. Some version will eventually get merged, I think.

Here's the link: https://lkml.org/lkml/2012/12/5/421

Wrong patch, that one is just about adding --march values for some specific cpus. In contrast, --march=native is about letting the compiler autodetect all the cpu capabilities, which leads to better optimisation and reduces the complexity of building your own kernel.