Re: Compiling Linux with "bdver2" gcc optimization option
On 13/08/19 at 19:35, Étienne Mollier wrote:
> Hi Franco,
>
> I'm not fluent enough in GCC 8 for x86_64 to answer to all the
> various warnings you indicated. Some may be harmless, and some
> may eat your data. I would do a few tests with a virtual
> machine supporting bdver2 instructions before going live anyway,
> and backups stored far away from the machine once testing, and
> possibly without contact with that kernel.
I didn't boot that kernel, I don't rely on it. Thanks if you can
investigate on what happens during compilation process.
>
> I also recall having had to move from ORC to DWARF unwinder to
> get the build working, but that was on old OS levels, not on
> newer ones, due to the libelf being too old.
>
> Some of these seem related to CPU vulnerabilities mitigations,
> and might be worth a bug report against the kernel, either
> Debian or upstream, assuming it also appears /without/ your
> -march=bdver2 flag:
>
>> mm/memory.o: warning: objtool: If this is a retpoline, please patch it in with alternatives and annotate it with ANNOTATE_NOSPEC_ALTERNATIVE.
I had asked to debian-kernel mailing list but nobody answered, maybe
could be something related to gcc 8 since all previous Debian kernel
versions worked with bdver2 optimization
>
> Note that someone from the Gentoo community has developed a set
> of patches to expand the possibilities of optimization for the
> kernel, depending on Linux and GCC versions. You may be
> interested in the following one for Buster:
>
> https://github.com/graysky2/kernel_gcc_patch/blob/master/enable_additional_cpu_optimizations_for_gcc_v8.1%2B_kernel_v4.13%2B.patch
>
> These mainly apply changes in various code sections to put the
> flags in place, and provide options through the .config file of
> the source code. I haven't tested it, but I don't believe this
> will solve your warnings, reading through the patch. Yet it
> does a bit more than just replacing the compiler flag: there is
> notably a component related to L1 cache shift which is modified
> too. That should bring an appreciable performance boost if it
> corrects cache line mismatch.
Thanks, but I don't want to patch the kernel, that change to the
Makefile was enough simple in order to get the optimization that I
looking for.
>
> Please be aware that CPU optimizations in kernel, targeting Zen
> and Skylake in this case, seemed to be hardly detectable, or
> even counter productive, with various computer usage patterns,
> according to measures done by Phoronix earlier this year:
>
> https://www.phoronix.com/scan.php?page=article&item=linux-50-march&num=1
>
> Of course this may not be the case for your own typical load,
> but I would recommend to do a few measures, to assess the actual
> performance gain on your machine with, and without, CPU specific
> compiler optimizations.
I never experimented benchmark with and without bdver2 option, I assumed
that if it exists an option for k8 in the kernel then changing it to
bdver2 it would be good (I hope).
--
Franco Martelli
Reply to: