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