From Gentoo Wiki
Jump to:navigation Jump to:search
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 12:01, 14 June 2024 (UTC)
:: Your reply ~~~~


Talk status
This discussion is done as of May 9, 2017.

As of now using -march=znver1 doesn't seem like the best choice: — The preceding unsigned comment was added by Lilithium (talkcontribs) 10:40, April 13, 2017‎

I will look into it. Thank you. --Maffblaster (talk) 19:08, 13 April 2017 (UTC)
After collaborating with another Gentoo developer (Tobias Klausmann (klausman)Tobias Klausmann (klausman) ), it looks like haswell was causing him segfaults. I changed it to the previously supported -march value. --Maffblaster (talk) 23:58, 9 May 2017 (UTC)
According to this forum discussion -march= should be either haswell, broadwell or skylake.
Using -march=bdver4 is not a good option as pointed out in this Phoronix article, simply because Bulldozer's instruction set extension FMA4/XOP is no longer available on the Zen architecture.
Code built for bdver1 through bdver4 might or might not work on Zen, depending on the actual instructions included during compilation. This is automatic and no one can say for sure what the compiler descides to use and not to use.
My recommendation is to use a lower subset of instructions to build GCC 6 (I used -march=skylake without issues, Ryzen 7 1800X) and then use -march=znver1 with GCC 6 set as the system GCC version (I removed GCC 5.4 completely). The caveat is that some packages need the ~amd64 ACCEPT_KEYWORDS flag set, because not all stable amd64 ebuilds include a GCC6 patch (yet).
Anyway, I just put that information into Safe CFLAGS, which now shows contradictory information to this article. One should be changed to equalize the information and remove the contradiction.
Luttztfz (talk) 23:05, 15 May 2017 (UTC)
Luttztfz , Thanks for putting this discussion point together. I have been discussion with other Gentoo developers, but haven't received back much information from them (yet). I have been using -march=native on my system with GCC and have experienced no issues whatsoever. I would actually be okay with transcluding the information from the Safe CFLAGS article to this article. I'll check into that. Thanks again for your efforts! Feel free to edit more around the wiki; my workload is high right now and it's hard for me to keep up. :) --Maffblaster (talk) 00:37, 16 May 2017 (UTC)
Might also be worth adding a note that Ryzen users really should be using at least gcc 6.3? Or maybe if using -march=bdver{1..4} users should then add further switches that disable FMA4/XOP. Is this possible? --Zucca (talk) 09:27, 16 May 2017 (UTC)
Yes, -mno-fma4 and -mno-xop will disable the use of these specific instruction set extensions. According to GCC x86 options one more difference between -march=bdver4 and -march=znver1 is the LWP extension. Thus -mno-lwp may also be a good idea.
I hope that these -mno- options will cancel the standard options of -march=.
The result would be: -march=bdver4 -mno-fma4 -mno-xop -mno-lwp for Zen on GCC 5.4. As I currently use GCC 6, I cannot test this right away, but I plan to do so in a couple of days. Luttztfz (talk) 20:17, 16 May 2017 (UTC)
I also found this PDF that states (on PDF page 12) that Zen lacks not only the FMA4 and XOP, but also the TBM instruction extension. In the Wikipedia article XOP instruction set (section History, last paragraph) it states exactly the same, that Zen lacks Piledrivers FMA4, TBM, XOP and LWP.
I changed the recommended CFLAGS in Safe CFLAGS and this article accordingly. Luttztfz (talk) 17:15, 17 May 2017 (UTC)
Naib ,

Yup, this can be shown via GCC echo | gcc -### -E - -march=native | grep -i lwp Using built-in specs.

COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/7.1.0/gcc Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.1.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.1.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.1.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.1.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include/g++-v7 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.1.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl= --with-pkgversion='Gentoo 7.1.0-r1 p1.1' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --disable-default-pie --enable-default-ssp Thread model: posix gcc version 7.1.0 (Gentoo 7.1.0-r1 p1.1) COLLECT_GCC_OPTIONS='-E' '-march=native'

/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1 -E -quiet - "-march=znver1" -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero -mno-pku -mno-rdpid --param "l1-cache-size=32" --param "l1-cache-line-size=64" --param "l2-cache-size=512" "-mtune=znver1"


LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-E' '-march=native'

--Naib (talk) 18:29, 17 May 2017 (UTC)

CPUFreq schedutil

Talk status
This discussion is done as of 2022-07-08.

Looks like from at least kernel 5.18.3 it's not possible to set 'ondemand' by default. Seems recommendation should be 'schedutil'. If somebody else can confirm this.. --Jms (talk) 16:53, 11 June 2022 (UTC)

Yes. I also use schedutil and that works best for the AMD P-State or the ACPI driver, in my opinion. --Maffblaster (talk) 06:00, 9 July 2022 (UTC)

AMD Processor P-State driver

Talk status
This discussion is done as of 2022-08-07.

seems to be a new (at least from 5.18) option in kernelː AMD Processor P-State driver (X86_AMD_PSTATE) --Jms (talk) 16:58, 11 June 2022 (UTC)

I looked at my .config files and found it in 5.17 too, but not in earlier verions. Luttztfz (talk) 05:54, 9 July 2022 (UTC)

The AMD P-State driver is now mentioned with this change: Special:Diff/1072124/1076468. Hope it helps! --Maffblaster (talk) 06:16, 9 July 2022 (UTC)


Talk status
This discussion is done as of 2022-08-02.

Variable from motherboard to motherboard. I didn't edit the page for that but in my case:

SuperIO per motherboard
Brand / Motherboard Chip Kernel module Notes
MSI MPG X570S EDGE MAX WIFI (MS-7D53) Nuvoton NCT6687D-R Not supported as of 5.18.x Support via out-of-tree =>
ASrock x370 Taichi Nuvoton NCT6779D-R NCT6775 (CONFIG_SENSORS_NCT6775) N/A

As of Linux 5.18, several options for Asus Mobo seems available, maybe the section has to be revised.

--Admnd (talk) 11:18, 04 July 2022 (UTC)

Please update the article (add a new sensors section if necessary) if you find information that is missing or out of date. No need to discuss this kind of a change here as it is useful information to anyone wanting sensors support for their motherboard. Thank you! --Maffblaster (talk) 21:53, 2 August 2022 (UTC)

Old GCC versions

Talk status
This discussion is done as of 2022-11-25.

GCC 8.x and 9.x are now hardmasked and all older GCC releases have been removed from the main portage tree a long time ago as of 2022-11-08. I would remove those outdated GCC sections and add something for GCC 11 & 12 (or even 13 which starts to support Zen 4) or would it make sense to keep it for a reason or another? (e.g. historical purposes). --Admnd (talk) 23:20, 8 November 2022 (UTC)

I personally cannot think of any reason, because a "historical" Gentoo doesn't exist anyhow. The only thing that IMHO might be of interest would a table showing the earliest GCC versions that introduced znver1, znver2, znver3... Luttztfz (talk) 17:56, 11 November 2022 (UTC)

I would agree. At minimum, support for when each compiler optimization flag was added to GCC is useful for our community reference. I'd also be OK with merging this information into a table or something. Thanks! --Maffblaster (talk) 00:04, 26 November 2022 (UTC)